Job Portal Development Cost: The Matching Engine Is a Regulated Component
A job portal looks like a database with two front doors. Employers post, candidates apply, the software keeps them apart until somebody clicks. Priced that way, it is a modest build, and that is the quote you will get from most of the agency blogs ranking for this search, somewhere between $9,000 and $200,000 with nothing behind either number.
The quote is wrong in a specific way: it prices the search product and ignores that the ranking is regulated. The moment your platform orders candidates for an employer, whether by match score, shortlist or a "top applicants" tab, you are plausibly operating what New York City law calls an automated employment decision tool and what the EU AI Act lists as a high-risk system.
That changes one thing about the build, and it is not a feature. New York City's Local Law 144 requires an independent bias audit of such a tool, repeated annually, with a summary published on the website and kept there for at least six months after the tool was last used, plus notice to candidates at least ten business days before use. A bias audit is arithmetic performed on your historical selection data. If the platform did not record who was scored, what they scored, which demographic categories they fall into and what happened to them, the audit cannot be produced at any price.
So the compliance cost is a logging decision made in month one, and it is nearly free then and impossible later. This is the single most expensive thing a job portal can get wrong, and no quote you receive will mention it.
Three questions set the price. Does the platform rank or merely filter? Is it a job board or a two-sided marketplace with candidate profiles? And which markets do you operate in? Our published rate band is $40 to $100 an hour by role, blending to $60 to $70 for a mixed team, and on this product the ranking and data layer belongs at the top of it.
The distinction that matters is between a tool that helps a human search and a tool that substantially assists or replaces a hiring decision.
A keyword search returning jobs to a candidate is not a hiring decision. A filter that excludes applicants without a required certification is closer to the line but is a criterion the employer set explicitly and can articulate. A model that scores applicants for fit and sorts them is over it, because the ordering influences which candidates a human ever looks at, and the ordering is yours rather than the employer's.
The practical consequence is architectural: keep scoring separable. Build the platform so that ranking is a distinct, versioned component with its own inputs, outputs and audit trail, not a sort order emerging from a clever search query. You need to be able to say which version of which model produced which ordering on which date, and a relevance score that lives inside an Elasticsearch query cannot tell you that.
Versioning matters as much as logging. A bias audit covers a period during which you probably changed the algorithm. Without versioned scoring, the audit is of nothing in particular.
This also protects you commercially. An employer eventually asks why a candidate ranked where they did, and a platform that can answer keeps the account.
The audit is an impact-ratio calculation: for each demographic category, the rate at which candidates were selected, compared against the most-selected category. Producing it needs four things recorded and joined.
Who was in the pool. Every candidate the tool scored, not just the ones who advanced. Platforms that log only successful applications have no denominator.
What the tool output. The score or ranking assigned, retained against the candidate and the requisition, with the model version.
What happened next. The actual selection outcome, which usually lives in the employer's applicant tracking system rather than yours. This is the hard one. If employers take candidates off-platform at shortlist, your outcome data stops exactly where the audit needs it, and getting it back means an integration and a contractual obligation on the employer to report dispositions.
Demographic category. Sex and race or ethnicity categories, which you must collect voluntarily, separately from the application, stored so that it cannot influence any decision, with a meaningful share of candidates actually responding. A 4% response rate produces an audit nobody can defend.
Every one of those is cheap to design in and expensive to retrofit. Candidate records get deleted under retention policies. Outcomes never captured cannot be recovered. Build the audit table before you build the model.
New York City Local Law 144 is in force and is the clearest statement of what compliance looks like. Annual independent bias audit, published summary retained at least six months past last use, and candidate notice at least ten business days ahead that also tells candidates they may request an alternative selection process or an accommodation. Enforcement sits with the Department of Consumer and Worker Protection, and each failure is treated as a separate violation. Published penalty figures vary across commentary, so treat the per-violation amount as something to confirm with counsel rather than a number to budget from.
The EU AI Act classifies employment and recruitment AI as high-risk under Annex III, covering targeted job advertising, filtering applications and evaluating candidates. The Annex III obligations were set to apply from 2 August 2026. A Digital Omnibus proposal published in November 2025 would move the employment-related deadline to 2 December 2027, and reporting on whether that deferral has been formally adopted is contradictory as of this writing. The classification itself is not in question either way, and separate transparency duties are not covered by the deferral.
The direction is one-way. Illinois, Colorado, California and Maryland have each moved on automated hiring decisions, and a platform selling into multiple US states is dealing with a patchwork rather than a standard.
Build to the strictest regime you plausibly touch. The data model that satisfies Local Law 144 satisfies most of the others, and the marginal cost of building it that way at the start is a few days.
There is a direct tension between the two compliance obligations on this product, and almost nobody designs for it.
The bias audit requires you to retain candidate records, including people who were rejected, with their scores, outcomes and demographic categories, for long enough to compute impact ratios across a meaningful period. Data protection law requires you to delete them. Under the GDPR a candidate can request erasure, and retention must be limited to what is necessary; India's DPDP Act takes a similar line on purpose limitation and erasure.
The resolution is aggregation, and it has to be designed in. Compute and store the audit aggregates, meaning counts and selection rates by category and model version, on a rolling basis, so the statistics survive after the underlying personal records are deleted. A platform that plans to run the audit by querying live candidate records will find the records gone and the audit impossible.
Consent for demographic data is separate from consent for the application. It is voluntary, it must not feed any decision, and candidates have to be told what it is for. Collect it in the same form as the application and you have both a legal problem and a response-rate problem, because candidates reasonably suspect it affects their chances.
Retention periods need an owner and a written policy. Recruitment data accumulates: applications from four years ago, profiles nobody has touched, CVs uploaded once. Deciding how long each category lives, and building the deletion job, is a day of work at the start and a regulatory finding later.
Applicants will ask what you hold on them. Subject access requests arrive, and answering them means being able to assemble everything about one person across applications, messages, parsed fields and scores. Design for that lookup rather than discovering it is a week of engineering each time.
Every plan allots a sprint to parsing and every project overruns it, because the problem is not extraction but normalisation.
Dates are the worst of it. "2019-present", "Jan 2019 to Mar 2021", "3 years", and a gap a candidate chose not to explain all have to become comparable. Computed experience length is a field employers filter on, so getting it wrong changes who gets seen.
Titles carry no standard meaning. A Senior Engineer at a forty-person company and at a forty-thousand-person company are different jobs with the same string, and candidates write whatever their employer called them. Any matching that treats titles as categories inherits that noise.
Skills need an ontology and someone to own it. Without one, "JS", "JavaScript", "ES6" and "Node" are four unrelated tokens. With one, somebody maintains it forever as the market invents new words.
Layout defeats parsers more than language does. Two-column CVs, tables, headers, graphics and PDFs exported from design tools are common in exactly the markets where candidates try hardest.
Budget for human correction in the product, not just in the pipeline. Let candidates review and fix what you parsed. It is the cheapest accuracy improvement available and it also sidesteps a category of complaint about automated misreading.
A job portal with no jobs is useless to candidates. With no candidates it is useless to employers. Every two-sided marketplace has this problem and every founder underestimates it, because it is the part a development budget cannot buy.
Scraping or aggregating postings to look populated is the standard opening move and it degrades fast. Aggregated listings go stale, applications route off-platform, and you have no outcome data, which, per the sections above, is the data you most need.
Narrow beats broad at the start. A board for one city, one industry or one role type can reach usable density with a few hundred postings. A general-purpose national board needs tens of thousands before it is worth visiting, and it is competing with incumbents who have them.
This changes what you should build first. Employer-side tooling that makes posting genuinely easy matters more than candidate-side polish in month one, because supply is the side you must solve first and the side that pays.
Fake and duplicate postings arrive early. Recruitment is a well-established vector for advance-fee fraud and credential harvesting, and candidates are a vulnerable audience. Employer verification and a reporting path are launch requirements rather than phase-two work, both ethically and because a board known for scam listings does not recover.
Job boards monetise in three ways, and each one implies different software.
Per-posting is the simplest and matches a classic board. An employer buys a listing for a period. Billing is straightforward, revenue is lumpy, and the product obligation ends at publication, which means you never need outcome data. It is also the model least entangled with the compliance questions above.
Subscription suits recruiters who hire continuously and gives you predictable revenue, but it raises the bar on the employer-side product, because somebody paying monthly expects applicant tracking, team seats and reporting. That is a second application, and it is where most of the budget goes if you choose this route.
Commission on placement pays best and is the hardest to build, because you only get paid when a hire happens, which means you must know a hire happened. That requires outcome reporting from employers and a dispute process for when they say the candidate came from elsewhere. The upside is that the same outcome data is exactly what a bias audit needs, so this model makes the compliance work cheaper rather than more expensive.
Candidate-side charging is possible and usually a mistake. Charging job seekers inverts the incentives, limits your supply of the thing employers come for, and in several jurisdictions charging candidates fees for job placement is restricted or prohibited outright. Check before you plan around it.
Pick the model before the build, not after the pilot. It determines whether you need an employer-side application at all, and that is the largest single swing in scope on this product.
Having said what is hard, most of the surface area is routine and you should not pay a premium for it.
Candidate and employer accounts, job posting and editing, search with filters, saved searches, application submission, messaging, dashboards, subscription or per-posting billing and an admin back office are all well-understood work near the floor of our rate band.
Email is the product more than the website is. Most job-board engagement happens in an inbox: the alert for a new matching role, the application confirmation, the nudge to an employer with unreviewed applicants. Deliverability, frequency control and one-click unsubscribe deserve real attention, and a daily digest that lands in spam is the same as no product.
Search relevance is worth senior time, and it is not the same as ranking candidates. Returning good jobs to a searching candidate carries none of the audit weight of scoring candidates for an employer, and it is where the product feels good or bad.
Mobile matters asymmetrically. Candidates are overwhelmingly on phones; employers are overwhelmingly on desktop reviewing applicants. Two different quality bars, and budget usually gets spread evenly when it should not be.
The data model first, including the audit tables, before any matching exists. It costs days at this point. It is the thing that cannot be added later.
Employer-side posting and candidate application second, because supply precedes demand and because this is the loop that has to work before anything else is worth building.
Search and alerts third. Good search plus reliable alerts is a complete, useful product with no regulated component in it at all, and many portals should stop here for a year.
Scored matching last, deliberately, and only once there is enough outcome data to evaluate it, which is also the data the audit needs. Shipping a match score on day one means shipping a regulated component trained on nothing, with no way to show it behaves.
We do not put a fixed total on a build like this before a discovery that establishes whether the platform ranks candidates, which markets it operates in and whether employers will report outcomes back. Those three answers change the work more than the feature list does. What we will say without a discovery is that the cheapest version of this product is the one that helps people search and declines to score them, and that for a large number of job portals it is also the right one.
Our published rate band is $40 to $100 an hour by role, blending to $60 to $70 for a mixed team. Most of a job portal (accounts, posting, search, applications, messaging, billing and admin) is routine work near the floor of that band. The costs that move the total are the data and ranking layer, where compliance obligations attach, and resume parsing, which overruns more often than any other component. Agency blogs quoting $9,000 to $200,000 are pricing feature lists, not these.
Often, yes. New York City's Local Law 144 covers automated employment decision tools used to substantially assist hiring or promotion decisions, requiring an annual independent bias audit, a published summary and advance candidate notice. The EU AI Act classifies employment and recruitment AI as high-risk under Annex III, covering targeted job ads, application filtering and candidate evaluation. Ranking candidates for an employer is the behaviour that triggers these; letting a candidate search jobs generally does not.
An impact-ratio calculation across demographic categories, which needs four joined records: every candidate the tool scored including those who did not advance, the score or ranking the tool produced with its model version, the actual selection outcome, and voluntarily collected sex and race or ethnicity data. The outcome data is the hard part, because it usually lives in the employer's applicant tracking system. None of this can be reconstructed later, so the logging has to exist before the model does.
Annex III of the AI Act classifies employment and recruitment systems as high-risk, and those obligations were set to apply from 2 August 2026. A Digital Omnibus proposal published in November 2025 would move the employment-related deadline to 2 December 2027, and reports conflict on whether that deferral has been formally adopted, so confirm the current position with counsel. The high-risk classification itself is unchanged either way, and separate transparency duties are not covered by the proposed deferral.
Because the difficulty is normalisation rather than extraction. Dates appear in a dozen formats that must become comparable years of experience, which employers then filter on. Job titles carry no standard meaning across companies. Skills need a maintained ontology or "JS" and "JavaScript" are unrelated tokens. And two-column layouts, tables and design-tool PDFs defeat parsers regularly. Let candidates review and correct parsed output; it is the cheapest accuracy gain available.
Niche, almost always. A job board is a two-sided marketplace, and the binding constraint is liquidity rather than software. A board for one city, industry or role type can reach usable density with a few hundred postings, while a general national board needs tens of thousands to be worth visiting and competes directly with incumbents who already have them. Solve the employer side first, since supply precedes demand and supply is the side that pays.
Yes, by not ranking candidates. A platform that lets candidates search and apply, gives employers good filtering on criteria they set themselves, and presents applicants in a neutral order such as most recent, carries none of the automated-decision-tool weight. For many job portals this is both the cheaper build and the better product. The obligations attach to scoring people, not to helping them find work.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
