HiringHello: Building a Free, Two-Sided Job Portal on Laravel

Recruitment marketplaces tend to fail in one specific way: they get expensive for exactly the people who can least afford them. Employers pay per job posting before they know whether that posting will attract anyone worth interviewing. Job seekers pay to have a resume surfaced, or they accept that theirs sits unread beneath a thousand others. What follows is a market where small companies under-post, candidates over-apply, and neither side trusts that the other is real.

We started HiringHello to test a different shape: make posting and applying free on both sides, and charge only for an optional visibility layer where the value is explicit and the buyer opts in. That decision set the engineering constraint rather than the other way round. A platform that charges nothing to post has to assume volume, has to hold the marginal cost of a listing near zero, and has to make recruiter search good enough that free listings still get filled. It also has to serve four user types on one codebase (job seekers, employers, in-house recruiters, and placement agencies) each of whom arrives with a different idea of what the product is for.

HiringHello runs on Laravel, deliberately as a server-rendered monolith rather than an API behind a single-page app. For a job portal, the pages that matter most (a job listing, a company profile, a category page) are precisely the pages that have to rank in Google. Server-rendered HTML from the first byte means every listing is indexable without a hydration step, and no crawl budget is spent executing JavaScript to discover a job that was published an hour ago. The blog and career-advice section lives in the same application for the same reason: organic search is the acquisition channel, not a side project.

The four user types share one authentication surface and diverge by role. A single role-aware account model carries job seekers, employers, recruiters, and placement agencies, with scoped dashboards built over common primitives: a job, an application, a profile, a resume. Modelling it once rather than as four parallel user tables keeps matching, search, and notifications single-implementation. When a placement agency posts on behalf of a client, it travels the same code path an in-house recruiter does, so a bug fixed for one is fixed for all four.

Company logos and uploaded resumes live in AWS S3 in the ap-south-1 region, close to the users, and are served through short-lived presigned URLs that expire in five minutes rather than from public bucket paths. A resume is personal data, and a URL that never expires is a URL that eventually leaks. Listing pages lazy-load company logos behind a local placeholder fallback, so a slow or failed object fetch degrades to a neutral icon instead of a broken image on the page where a candidate is deciding whether to trust the employer.

Promoted Candidates is the platform's one paid surface, and it is built as a ranking input rather than a separate results list. A promoted resume competes inside the same recruiter search as everyone else and is boosted within it. That keeps the results honest: paying lifts a candidate who already matched, it never inserts one who did not. Sessions and CSRF protection ride Laravel's encrypted cookie layer, and the application is served behind LiteSpeed.