The Stratgik MVP Effort Model 2026: developer-days per feature

What this is, and why we're publishing it

Almost every "how much does an app cost" guide on the internet gives you a range and no arithmetic. You get "$40,000–$150,000" with no way to check it against your own feature list, and no way to tell whether the quote sitting in your inbox is fair or fantasy.

This page is the opposite. It is the actual effort model behind the Stratgik App Cost Estimator — every number, every multiplier, the exact arithmetic. Nothing is withheld. You can reproduce any estimate the tool produces with a calculator, and more usefully, you can use it to interrogate somebody else's quote.

Two honest caveats up front. First, this is an effort model, not a price list: it outputs developer-days, and what a developer-day costs you varies enormously by where and how you buy it. Second, these are our working figures from delivery experience, not a survey of the industry. They are opinionated. We publish them because a model you can argue with is more useful than a range you cannot.

The unit: developer-days, not hours or dollars

Everything below is expressed in developer-days — one competent mid-to-senior engineer, one working day, including the meetings, code review and rework that real projects contain. It is deliberately not "ideal engineering hours", because ideal hours are the single most common source of blown estimates.

To convert developer-days into elapsed calendar time, divide by your team size and then by five. Our model assumes two developers working in parallel, because past two on an MVP-sized codebase, coordination overhead starts eating the gain. So 47 developer-days is roughly 24 working days of wall-clock time, or about five weeks — not 47 days, and not two weeks either.

Foundation: what you pay before you build anything

This is the floor. It exists whether your product has one feature or twenty, and it is the line item most often missing from cheap quotes. A quote that starts at "two weeks for a full MVP" has either excluded the foundation or is planning to skip it — and skipping it is what produces a codebase nobody can deploy six months later.

Feature costs

Each feature below is additive on top of the foundation. These are full-stack figures: schema, backend logic, API, interface, and the error and edge-case handling that separates a demo from a product.

The three multipliers

Feature days give you a base. Three multipliers then scale it. They compound — multiply, don't add.

Platform

Design

Scope quality

The formula

Developer-days = (15 + sum of feature days) × platform × design × scope

The estimator then reports a range of ±25% around that figure, because any honest estimate made before the work starts is a range. If a vendor gives you a single number to two significant figures for a project that hasn't been specified yet, that number is a sales artefact, not an estimate.

Worked examples

Note what the model does not include, because these are the lines that turn a good build into a bad year: discovery and specification before the build, post-launch iteration, marketing, and the ongoing maintenance that runs 15–25% of build effort per year, forever.

How to use this to check a quote

Take the quote in front of you and do four things.

1. Reconstruct their day count. Divide the total by their stated or implied day rate. Now you have their effort estimate, which is the number that actually matters.
2. Compare it to the model. Build your feature list here and apply the multipliers. If their figure is more than about 40% above the model's range, ask what they know that this model doesn't — sometimes the honest answer is a real constraint you hadn't understood, and that's a good conversation to have. If it's far below, ask what has been excluded: it is almost always the foundation, QA, or the admin panel.
3. Check the foundation is in there. Fifteen days of unglamorous setup. If you cannot find it in the breakdown, it is not priced.
4. Ask for the range, not the number. A vendor who cannot give you a low and a high has not estimated; they have guessed and padded.

If you would rather have someone do this with you, that is exactly what the free 30-minute technical session is for — bring the quote, we will walk through it line by line, and we will tell you if it's fair even when it isn't ours.

What comes next: the Stratgik MVP Cost Index

This page is the model. The next step is the evidence.

Every anonymous run of the App Cost Estimator is now recorded — feature selections, platform, design and scope choices, and the resulting effort range. No names, no email addresses, no identifying data. Once the sample is large enough to be meaningful rather than merely suggestive, we will publish the Stratgik MVP Cost Index: what founders are actually trying to build, which features they most often over-scope, and how the real distribution of MVP effort compares to the ranges everyone quotes.

We will publish it whether or not the numbers flatter us, and we will say plainly how many runs it is based on. Until then, this model is what we have, and you can hold us to it.

Frequently asked questions

What is a developer-day and why not just quote hours?

A developer-day is one competent mid-to-senior engineer for one working day, including code review, meetings, and the rework that every real project contains. We avoid quoting "ideal engineering hours" because that unit systematically underestimates: it prices the typing and ignores everything around it, which is why hour-based estimates so reliably overrun by 40–100%.

Why does payments cost 12 developer-days when Stripe Checkout takes an afternoon?

Because the afternoon gets you a payment link, not a payments system. The remaining eleven days are webhook handling, failed and retried payments, subscription proration, refunds and partial refunds, tax and invoice handling, and a reconciliation view your accountant can actually use. Teams that budget the afternoon discover the rest in month three, usually after a customer has been double-charged.

Why does an admin dashboard cost as much as payments?

Because it is a second application. It needs its own authentication and permission model, search and filtering across your data, bulk actions, an audit trail of who changed what, and safe handling of destructive operations. Founders picture one table of users; what they need within a month is a tool their support team can operate without engineering help.

How do I convert developer-days into a budget?

Multiply by whatever a developer-day costs you. That varies enormously — a supervised offshore team, a Western agency and an in-house hire can differ by a factor of six for the same effort. This is deliberate: the model tells you how much work there is, and your procurement decision tells you what that work costs. Run your own configuration through the estimator to see both together.

Is the ±25% range realistic, or is it hedging?

It is realistic and, if anything, tight. Software estimation research has consistently found uncertainty far wider than this at the start of a project, narrowing only as specification and design complete. A ±25% band is defensible for a well-understood feature set with a written specification; for a vague brief, treat the top of the range as the planning figure rather than the middle.

Why publish your internal model at all?

Because the information asymmetry between founders and vendors is the single most expensive thing in early-stage software, and we do not profit from it. Stratgik makes money when founders build the right thing, not when they build the most expensive thing. A founder who can interrogate a quote — ours included — is a better client, and the ones who walk away were never going to be happy anyway.

Does this model apply to no-code builds?

Only loosely. No-code changes the shape of the work: the foundation shrinks dramatically, simple CRUD features collapse to a fraction of these figures, and anything involving custom logic, performance, or unusual data relationships can cost more than writing it conventionally. Use this model for custom builds, and read our no-code vs custom code comparison to work out which route your product belongs on.

What is deliberately excluded from these numbers?

Discovery and written specification before the build, product and project management overhead, post-launch iteration, marketing and customer acquisition, and ongoing maintenance — which runs 15–25% of the original build effort every year for as long as the product lives. Budget for post-launch iteration at 40–60% of the build; it is the phase that decides whether the product works, and the one founders systematically underfund.

Check your own build against the model

Put your feature list into the App Cost Estimator and you will get the effort figure and range this model produces, in about two minutes and without giving up an email address. If you are weighing building against buying something off the shelf first, start with the build vs buy calculator instead.

Then, if you want a second opinion from someone with no incentive to inflate the number, book a free 30-minute technical session. Bring your feature list or your quotes. We will tell you what should be cut, what it should cost, and whether you should be building at all — which is sometimes the most valuable thing we say. Ongoing senior oversight starts at $49 a month; see pricing for what each tier covers, or how we run MVP development for the delivery model behind these numbers.