Skip to content
Insights · Engineering

What an MVP build actually costs

Nobody can quote a credible number without scope. But an MVP is mostly labour, and labour costs are published — so here is the arithmetic from public wage data, with no vendor rate card involved.

Scroll
EngineeringSep 10, 20267 min readBy Salman Naqvi, Founder & CEO
What an MVP build actually costs

An MVP costs a small senior team for a fixed number of months, and both halves of that are public record. The US Bureau of Labor Statistics puts the 2025 median pay for software developers at **$135,980 a year**, and its Employer Costs for Employee Compensation release puts wages at 70.0% of total compensation for private-industry workers — so one developer's loaded cost is roughly **$194,000 a year**, about **$16,200 a month**. Four such people for four months is around **$259,000** of labour before anyone's margin, overhead or profit. That figure is the honest basis of every MVP quote you will ever receive.

Start with why nobody can give you a number over the phone. "MVP" describes a decision-making posture, not a size of software: it is the smallest thing that tests a specific commercial hypothesis. One founder's MVP is a booking flow over a spreadsheet; another's is a two-sided marketplace with payments, KYC and a mobile app. Those differ by an order of magnitude in labour and both are legitimately called an MVP. Any vendor quoting before scope is quoting a hope, and any article quoting a single market figure is quoting an average of unrelated projects.

**The arithmetic, stated so you can redo it with your own inputs.** The Bureau of Labor Statistics reports a 2025 median annual pay of $135,980 for software developers, against $104,300 for quality assurance analysts and testers, with roughly 1.7 million software developers employed in the US and projected growth of "10 percent from 2025 to 2035, much faster than the average for all occupations" (US Bureau of Labor Statistics, Software Developers, Quality Assurance Analysts, and Testers, Occupational Outlook Handbook, 2025 data). That median is wages and salary only. It is not what an employer spends.

For the rest, the same agency publishes it. In its Employer Costs for Employee Compensation release for June 2026, total compensation for private-industry workers averaged "$46.89 per hour worked," of which wages and salaries were $32.82 (70.0%) and benefits $14.07 (30.0%); for civilian workers overall the figures were $49.46 total, $33.85 in wages (68.4%) and $15.61 in benefits (31.6%) (US Bureau of Labor Statistics, Employer Costs for Employee Compensation, June 2026). Divide the median developer salary by 0.700 and you get about $194,000 a year in employer cost, or roughly $16,200 a month, per engineer. That number is a floor: it excludes recruiting, equipment, software, office, management time and any margin whatsoever.

One caveat on that arithmetic, because it is the part a careful reader should push on: 70.0% is the wage share across *all* private-industry workers, not software developers specifically, and benefit structures for high-wage professional roles plausibly differ from the average. Treat $194,000 as an order-of-magnitude floor rather than a precise figure. The conclusion it supports does not need precision — whether the loaded monthly cost of a senior engineer is $15,000 or $18,000, a four-person team for four months is a quarter of a million dollars of labour, and any quote far below that is buying you something other than four senior engineers for four months.

**Seniority and specialism move the wage line before they move anything else,** and there is published data on exactly how much. Stack Overflow's 2025 Developer Survey reports US median annual salaries of $189,500 for an AI/ML engineer, $189,000 for a cloud infrastructure engineer, $180,000 for a software or solutions architect, $175,000 for a back-end developer, $200,000 for an engineering manager and $225,000 for a senior executive (Stack Overflow, 2025 Developer Survey: Work). Adding a genuine AI capability to an MVP therefore raises the labour cost twice: once through the wage premium on the person who can build it, and again through the evaluation work that a non-deterministic feature requires and a CRUD feature does not.

**Geography is why published MVP prices vary by a factor of ten without anybody lying.** The same Stack Overflow data puts the median software or solutions architect at $180,000 in the United States, $109,054 in Germany and $46,496 in India, with engineering managers at $200,000, $118,335 and $52,308 respectively. Rerun the arithmetic above with the Indian median and a four-person, four-month team lands near $88,000 rather than $259,000. Neither number is a scam and neither is a bargain in the abstract: what you are trading is time-zone overlap, continuity of the same people, and how much product judgement arrives with the code. The useful move is to notice which labour market a quote implies, because a $30,000 quote for a four-month build by four US-employed engineers is arithmetically impossible, whatever the proposal says.

**Duration is the only variable a buyer fully controls,** and it is the one most likely to be handled by hoping. Labour cost is linear in months, so the difference between a four-month and a nine-month first release is not a schedule preference — it is more than doubling the bill. This is why the six-month ceiling that the US Office of Management and Budget sets for federal software investments, requiring agencies to "deliver useable functionality every 6 months," is a better budgeting instrument than a feature list. The Government Accountability Office found that of 22 agencies reporting on that requirement, 64% of software development projects were claimed to meet it, while GAO's own review of seven departments found roughly 50% actually achieved delivery at that interval (US Government Accountability Office, Information Technology Reform: Agencies Need to Increase Their Use of Incremental Development Practices, GAO-16-469, August 2016). If organisations under a reporting mandate overstate their increment discipline by fourteen points, an unaudited plan will do worse.

**What the labour figure leaves out** is short and needs to be in the budget anyway. Cloud and hosting from the first environment onward. Third-party services — payments, identity, email, mapping, SMS — each with a per-unit price that scales with usage rather than with the build. Design, if it is not one of the four people. Any paid data source. And after launch, the maintenance line: dependency upgrades, security patches, and the support load that arrives with the first real users. For AI features specifically the run-rate deserves its own model rather than a percentage, and the cost to build an AI agent sets out the token, refinement and evaluation lines that a build estimate typically hides.

**Team shape is easier to reason about than price,** and it is the thing to ask a vendor for. Our own published work gives concrete shapes rather than rates: an agency operating system with eight product modules, subscription billing, role-based access, chat, scheduling and an AI knowledge assistant took six specialists over eight months; an AI search platform across documents, data lakes and repositories took five specialists over seven months; a virtual seller assistant piloted with 200 sellers took five specialists over seven months. Multiply any of those shapes by the loaded monthly figure above and you have a labour floor you derived yourself, from BLS data, with no vendor's assertion in it.

To be explicit about a thing that would otherwise be read into this article: **none of these numbers are our rates.** We do not publish a rate card, and our pricing page deliberately publishes fixed deliverables rather than day rates, because a rate multiplied by an unscoped guess is the mechanism by which fixed-price projects become change orders. Every figure above comes from the Bureau of Labor Statistics, Stack Overflow or the Government Accountability Office, and you can open all four sources in a browser and check them.

**How to read a quote you have actually received.** Three questions get you most of the way. First, how many people and for how many months — because that, times a loaded wage you can look up, is the floor, and a price beneath it means either a different labour market or a different number of people than you were told. Second, what is the acceptance test for the first release, in one sentence, agreed before code is written; a vendor who cannot state it has not scoped the work and neither have you. Third, what happens in month seven — who maintains it, at what cost, and does the handover include the evaluation harness or just the repository.

The last one is where MVP budgets most often break. A build price is a single event; a product is a run rate. Founders who plan only the invoice discover the operating cost after the runway assumption is already fixed, which is a much worse moment than during procurement. Budget the first twelve months, not the delivery.

The corollary is that cutting scope is worth far more than negotiating rate. A 20% discount on a nine-month build saves less than shipping in five months at full price, and the shorter build reaches real users sooner — which is the actual purpose of the exercise. How to scope an MVP so it ships is the decision rule for doing that deliberately, and fixed-scope integration sprints are how we structure work when the goal is a named capability with a defined end rather than an open meter. For teams whose first release includes AI in the product itself, the same discipline that governs top SaaS development company applies at MVP scale: the model is the cheap part, and the verification around it is the budget.

Find this useful? Tell Google to show you more of it.

Let's put AI to work in your business.

A 30-minute call. You bring the workflow or the roadmap — we'll tell you what's feasible, what it costs, and what we'd build first.

Book a call