Product engineering cost: what an MVP, a v2 and a platform build actually run to

01The four things that move the number

Scope certainty is the largest. A brief where the flows are known and decided costs far less than one where they will be discovered during the build, because discovery is engineering time spent on conversation rather than code. Vendors who quote low against a vague brief are pricing the version they imagine, and the difference appears later as change requests.

Then seniority mix, quality bar and integration surface. A team of three seniors costs more per month and usually less per outcome than a team of eight juniors with one lead. And integrations with systems you do not control - a legacy ERP, a bank, an EHR - carry irreducible uncertainty that honest quotes reflect as a range rather than a number.

• Scope certainty - decided flows cost less than discovered ones.
• Seniority mix - fewer seniors often beats more juniors per outcome.
• Quality bar - an experiment and a regulated system are different builds.
• Integration surface - systems you do not control add real uncertainty.

02What each stage costs

The bands below assume senior blended or offshore delivery. Onshore-only teams in the US, UK or Western Europe typically run two to three times higher. The most important column is duration, because for most companies time to market matters more than the invoice.

03The MVP mistake that triples the cost

The most expensive error we see is building an MVP to production standards everywhere. An MVP is an experiment - its job is to tell you whether the idea works. Applying full rigour to every part of something you may delete triples the cost of learning it was wrong.

The discipline is choosing where rigour belongs. Authentication, payments and the data model are worth building properly, because they are painful to change and dangerous to get wrong. The specific feature flows you are testing are not, because most of them will change once real users touch them. A vendor who does not make that distinction is either inexperienced or padding.

04Fixed price versus time and materials

Fixed price transfers risk to the vendor, and they price that risk - typically a twenty to forty percent premium, plus a strong incentive to interpret every ambiguity narrowly. It works when scope is genuinely fixed and well specified, which is rarer than it sounds.

Time and materials is cheaper when scope will evolve, which is most product work, but it requires trust and visible progress. The middle ground that works well is a fixed-price discovery producing a detailed plan, then time and materials against that plan with an agreed budget ceiling and monthly review. You get a real estimate without paying the full risk premium.

05What to check before signing

Who owns the code and where does it live? It should be your repository under your accounts from the first commit. Any arrangement where the vendor holds the code in their infrastructure creates an exit cost you have not priced.

What happens after launch? A build with no maintenance plan is a system that decays. Dependencies age, security patches accumulate, and the first serious incident arrives with nobody assigned. Agree the operating arrangement before the build finishes, not during the incident.

• Your repos, your cloud accounts, from commit one.
• Documentation and tests as deliverables, not optional extras.
• An agreed operating plan for after launch.
• A named technical lead who is actually on your project.