You Can't Look Up What Your MVP Costs. You Can Work Out How Many Weeks It Is.

Earlier this month we published a post that refused to give a price range for custom software, on the grounds that nobody can price a project they haven't scoped. That still holds. It also left a gap, because "I can't tell you the price" is an unsatisfying answer to someone holding two quotes that are £60,000 apart.

So here is the other half. An MVP cost has two terms in it: how many weeks of work, and what a week costs. You cannot get the second one honestly from a blog post — every published day rate is either a recruiter's survey or a supplier's marketing. But you can get the first one yourself, in an afternoon, before you talk to anybody. And the first one is where the £60,000 gap lives.

This post is a worksheet. It converts an MVP into developer-weeks, names the three decisions that move that number more than your choice of supplier does, and then adds the six MVP cost drivers that appear in no feature list because they aren't features — they are platform rules and statutes, and they are all quoted below from source.

It finishes with the discount you were probably counting on, and the reason you shouldn't.

Part one: what an MVP is, and the cost that follows from it

The term has drifted so far that it now mostly means "the cheap one". That is not what it was coined to mean, and the original definition has a direct consequence for your budget.

Eric Ries, in the 2009 post that put the phrase into circulation: "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." And, in the same post, the correction almost everyone skips: "MVP, despite the name, is not about creating minimal products."

Read that as an MVP cost instruction and it says something quite specific. An MVP is not a small version of your product. It is an instrument for answering one question you cannot answer by asking people. Which means:

• Anything in the build that isn't answering the question is pure cost, not a discounted feature.

• The question has to be written down before the estimate, or the estimate is fiction.

• "It needs to be ready for real customers" is a different product to "it needs to tell us whether real customers want this" — in our experience close to twice the build. Both are legitimate. Pick one on purpose.

Here is the test that takes ten minutes and saves more than anything else in this post. Write, in one sentence: if this is wrong, we stop. Then list only the things you need in order to find out. If you cannot finish the sentence, you are not scoping an MVP, you are scoping version one — which is fine, but price it as version one.

One question. One kind of user. One path through the product. Everything you add to those three is a decision to spend, and the worksheet below tells you roughly what each one costs in time.

Part two: the MVP cost worksheet

The unit here is a developer-week: one competent person, one week, actually on your project. Not calendar time — calendar time is longer, because of you as much as them.

These bands come from our own delivery, not from published data. We are giving them to you so you have something to hold a quote against, not because they are authoritative. A supplier who disagrees with a band is not necessarily wrong; they should be able to say why in one sentence, and the sentence is the useful part.

The base — any MVP, no matter what it does

If a quote for an MVP is under that base and includes everything in it, one of three things is true: the scope is smaller than you think it is, the people are more junior than you think they are, or the price is a loss-leader and the money is in the change requests. All three are worth knowing; none is automatically a reason not to proceed.

The three decisions that move the number

Not features. Binaries. Each one turns on a whole category of work, and each one is entirely yours to decide.

That third row is the one founders resist and the one that most reliably pushes a first build past its budget — two platforms can add as much again as the entire base build. If the question you are trying to answer does not require an icon on a home screen, a web app answers it for a fraction of the cost, and you can decide about apps once you know the answer.

The four lines that are in no quote you'll receive

Whether you do these is not up to you or your supplier — app stores, statutes and standards decide that. The only genuine choice is the accessibility target, and part three explains why WCAG 2.2 AA is the sensible one even though WCAG 2.1 AA is what the law currently points at. Every line below is sourced in part three.

The right-hand column is the whole argument for the left-hand one. None of this work gets cheaper by being deferred; one row blocks a store release outright, and one quietly stops you taking money.

Putting it together

Each shape below includes the compliance lines, because you don't get to leave them out.

Then, and only then, the money: multiply by the weekly rate of whoever is going to build it. That multiplication is your MVP cost. That is a number you can only get from them — but part four gives you a floor to sanity-check it against.

Part three: the six MVP cost drivers that aren't features

Every item below is a rule somebody else wrote. You cannot design around them, and your supplier will build them whether or not they appear on the estimate you approved. The reason to know them before you sign is that three of them are avoidable by scoping decisions — and the decisions have to be made early to count.

1. Taking a payment means building two flows, not one

UK law does not let you charge a card and move on. The Payment Services Regulations 2017 require strong customer authentication, and the trigger is the transaction, not your preference:

"A payment service provider must apply strong customer authentication where a payment service user … (b) initiates an electronic payment transaction" — and, for remote transactions, authentication "that includes elements which dynamically link the transaction to a specific amount and a specific payee."

The technical rules make the shape explicit: authentication "shall be based on two or more elements which are categorised as knowledge, possession and inherence and shall result in the generation of an authentication code."

There are exemptions, and they matter commercially — low-value remote transactions, transactions the provider's own risk analysis scores as low risk, beneficiaries the payer has marked as trusted, and subsequent charges in a recurring series after the first one is authenticated. But read who decides: the exemption is applied by the payment service provider, not by you. Which is precisely why this is two flows and not one. Your product has to work when the customer is sent off for authentication and when they aren't, and it has to handle the case where authentication fails halfway.

A payment form is two days. A payment flow is one and a half to three weeks. That gap is where "but Stripe handles all that" quotes go wrong — and it is the same gap we wrote about on the hospitality side when a booking deposit meets a card issuer.

2. If users can create an account, both app stores require they can delete it, and Google requires it twice

Apple's App Store Review Guidelines, 5.1.1(v):

"If your app doesn't include significant account-based features, let people use it without a login. If your app supports account creation, you must also offer account deletion within the app."

Google Play's User Data policy goes further, and this is the requirement that costs real time:

"If your app allows users to create an account from within your app, then it must also allow users to request for their account to be deleted."

"Users must have a readily discoverable option to initiate app account deletion from within your app and outside of your app (for example, by visiting your website)."

"When you delete an app account based on a user's request, you must also delete the user data associated with that app account."

"Temporary account deactivation, disabling, or 'freezing' the app account does not qualify as account deletion."

Count what that is. An in-app flow. A web endpoint that authenticates a person who may have already deleted the app. A deletion job that actually removes data across every table and every third-party service you've sent it to. And a decision about what you are legally required to keep anyway — because tax records and fraud logs don't disappear because someone tapped a button.

That is not a checkbox. It is most of a week, and it is the single best reason to ask whether your MVP needs accounts at all. Guest checkout, a magic link, a booking reference — any of these answers your question without switching on this obligation.

3. Selling anything digital inside an iOS app changes your economics

Apple, guideline 3.1.1:

"If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc."

Note what this does and does not cover. Selling a physical good, a table booking, a hotel room or a real-world service is not "unlocking features within the app". Selling a subscription to your software is.

This area is genuinely unsettled and we are not going to pretend otherwise. Apple's current guidelines permit buttons and external purchase links in US-storefront apps without an entitlement — Apple attributes the change to a court decision, describing the guidelines as "updated for compliance with a United States court decision regarding buttons, external links, and other calls to action in apps" — while elsewhere, "In all other storefronts, except for the United States storefront, where this prohibition does not apply, apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase." The EU position has been rewritten more than once under the Digital Markets Act. Anything more specific than that will be out of date by the time you read it, so check the live guidelines on the day you decide.

The scoping consequence is stable even though the rules aren't: if your MVP's revenue model is a digital subscription and you plan to test it in a native app, model the platform commission before you build, and consider testing it on the web first.

4. The store listing is a compliance artefact

Google Play's User Data policy:

"All developers must complete a clear and accurate Data safety section for every app detailing collection, use, and sharing of user data."

And, from the Play Console guidance, the part that catches "we're only doing a private beta":

"All developers that have an app published on Google Play must complete the Data safety form, including apps on closed, open, or production testing tracks."

"You alone are responsible for making complete and accurate declarations in your app's store listing on Google Play."

To complete that form accurately you need to know every piece of data your app collects, why, where it goes, and how it is protected. If nobody wrote that down during the build, somebody reconstructs it from the codebase during the submission — which is the most expensive week in which to discover that an analytics SDK is collecting more than you thought.

5. Accessibility has a deadline that has already passed

This is the one UK founders most often haven't heard about. The European Accessibility Act, Directive (EU) 2019/882, applies:

"to the following services provided to consumers after 28 June 2025: … (f) e-commerce services."

And "e-commerce services" is defined broadly:

"'e-commerce services' means a service provided at a distance, through websites and mobile device-based services, by electronic means and at the individual request of a consumer, with a view to concluding a consumer contract."

Note what the trigger in that text is: the type of service provided to consumers, not the location of the company providing it. So do not assume that being outside the EU settles the question. A Directive binds member states rather than businesses directly, and whether a UK company selling to EU consumers is caught depends on each member state's transposing law — several of which do reach suppliers targeting their consumers. The practical exposure is therefore country-by-country, and it is a question to put to an adviser for the markets you actually sell into rather than one to resolve from the Directive alone. One further caveat: the Directive contains a microenterprise exemption for service providers, with microenterprise defined as "an enterprise which employs fewer than 10 persons and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million" — if you are that small, read the operative exemption provision with an adviser before relying on it, because the definition and the exemption are two different things.

Which standard? EN 301 549 is the reference. As of September 2026 the legally operative version is v3.2.1, which points at WCAG 2.1 Level AA. A new version, v4.1.1, was published this month and moves to WCAG 2.2 — but per the European Commission's own accessibility resource centre, "organisations should be aware that the new version is not yet the legal reference standard for demonstrating compliance with the European Accessibility Act (EAA) or the EU Web Accessibility Directive (WAD)", and only "once the standard is formally cited" will conformity with it confer the presumption.

Practical instruction, which doesn't depend on resolving any of that: build to WCAG 2.2 AA from the first screen. It is backwards-compatible with the 2.1 AA the law currently points at, it is where the standard has already moved, and it is half a week at the start against two to four weeks of retrofit later. Accessibility is cheap when it is a habit and expensive when it is a project.

6. Data protection is a pre-launch obligation, not a post-launch one

UK GDPR Article 25(2):

"The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility."

The ICO is unambiguous about the timing, and this is the sentence to put in front of anyone who wants to "sort the privacy stuff after the beta":

"You must determine your lawful basis before you start using the personal information and you must document it."

And on the notice: "you must provide them with privacy information at the time you obtain their data."

Read together with Article 25, that has a pleasant side effect for an MVP cost. The cheapest way to comply is to collect less. Every field you don't ask for is a field you don't have to justify, secure, retain, produce on request or delete. Data minimisation is a compliance principle that happens to also be a scoping discipline — which is not a coincidence.

Part four: the floor

You cannot look up an honest day rate, but you can calculate what a developer costs an employer, from published figures. This gives you a floor: a number below which somebody's economics have to be different from yours.

Start with what the government itself treats as the market rate. The Home Office's going rate for occupation code 2134, "Programmers and software development professionals", is £54,700 a year — a figure the Migration Advisory Committee describes as derived from the median of full-time annual earnings in the ONS Annual Survey of Hours and Earnings. Then add what an employer pays on top:

That £274 buys you a developer sitting at a desk. It does not buy the desk, the laptop, the recruitment fee, the sick days, the person who manages them, the designer, the tester, anybody talking to you, or the fact that nobody is chargeable every hour of every week. The median contractor day rate of £525 we cited earlier this month is not a markup on that £274; it is what the same work costs once somebody else is carrying all of it, and an agency rate is a different unit again.

Two adjustments worth knowing. A small employer claiming Employment Allowance can relieve up to £10,500 of employer NI a year, which for a one-developer company wipes that £7,455 out entirely — bringing the floor to roughly £1,207 a week. (Note the condition that catches one-person companies: "If your company has only one director, they must not be the only employee liable for secondary Class 1 National Insurance.") And the £54,700 going rate is one number covering a very wide occupation: the same Migration Advisory Committee report notes job-advert data putting the median for software developers at £44,900 against £62,600 for software engineers and £80,100 for solutions architects. One occupation code, a spread of more than £35,000. That is the real reason no single day rate tells you anything.

Use the floor for what it is good for: not to argue a quote down, but to notice when a quote is so far below it that the work is being done by somebody other than the person you met.

Part five: the discount that probably isn't there

Somewhere in the budgeting for a first build, somebody says: we'll get some of this back as R&D tax credits. It is worth knowing, before that assumption reaches a spreadsheet, that a normal commercial software build usually does not qualify — and that HMRC's own guidance says so in language that is unusually direct.

The statutory test, from the Secretary of State's Guidelines on the Meaning of Research and Development for Tax Purposes:

"R&D (research and development) for tax purposes takes place when a project seeks to achieve an advance in science or technology."

And an advance means an advance in the field, not in your company:

"An advance in science or technology means an advance in overall knowledge or capability in a field of science or technology (not a company's own state of knowledge or capability alone)."

Then paragraph 22, which is the sentence that ends most conversations:

"However, the routine analysis, copying or adaptation of an existing process, material, device, product or service will not advance overall knowledge or capability, even though it may be completely new to the company or the company's trade."

HMRC's compliance guidance for software claims is blunter still:

"Creation of new functionality and computer environments alone will not qualify for relief if it represents routine replication of existing methods in a new context."

And the specific argument most founders reach for — nothing on the market did what we needed — is addressed in HMRC's manual on applying the guidelines to software, in a sentence worth quoting to its end because the second half is a concession: "It is not enough to state that a product is not available to solve the (commercial) problem faced as being the reason why a solution wasn't readily deducible, but this could be the trigger that starts the software development project, or sub projects within a larger project, which in turn may trigger the commencement of qualifying R&D."

In other words: the gap in the market is what sends you looking, and it is not itself the thing that qualifies. What qualifies, if anything does, is whatever turns out to be genuinely uncertain once you start.

Note also where the advance has to be. The guidance requires "a qualifying project seeking a scientific or technological advance in computer science or software engineering" — not an advance in hospitality, logistics, or your own industry. A booking system that is new and valuable in a hotel is not, on that basis alone, an advance in software engineering.

In fairness, the door is not closed. The same manual allows that "Combining standard technologies, such as integrating platforms, can be R&D if a competent professional in the field can't readily deduce how the separate components should be combined to have the intended function", and genuinely hard integration work does sometimes qualify. But "hard for us" is not the test; "not readily deducible by a competent professional in the field" is.

If a build does qualify, here is the actual size of the prize. Under the merged scheme, for accounting periods beginning on or after 1 April 2024, "the rate of R&D expenditure credit under the merged RDEC scheme is 20%" — and "this expenditure credit is liable to Corporation Tax as it is classed as trading income", so the net benefit works out at roughly 15% to 16.2% of qualifying spend depending on your corporation tax position. A loss-making SME that passes the Enhanced R&D Intensive Support test — where "relevant R&D expenditure is at least 30% of its total expenditure" — gets a 186% deduction and a payable credit "worth up to 14.5% of the surrenderable loss", which works out at roughly 27%. (Those percentages are our arithmetic, not quoted figures; no HMRC page states a net-benefit percentage.)

And two administrative traps that cost first-time claimants the whole claim:

• The claim notification. A first-time claimant must notify HMRC in advance, in a window that "ends 6 months after the end of the 'period of account'". Miss it and "your R&D tax relief claim will be invalid" — even though the claim itself could otherwise be made up to two years after the period end. Founders who think about tax at year-end have usually already lost it.

• The additional information form. "You must complete and submit an additional information form to HMRC to support new claims", and "if you do not submit this form, any R&D or expenditure credit claim will not be accepted." It requires, per project, the field of science or technology, the baseline level of knowledge, the advance sought, the uncertainties faced and how they were overcome. That is a technical narrative written by someone competent in the field — not a form-filling exercise, and not free.

The honest planning position: budget your MVP as though there is no relief. If the work turns out to contain genuine technological uncertainty, treat the relief as an upside discovered afterwards, with an adviser, having kept contemporaneous notes on what was actually uncertain and why. Do not let it into the business case.

Part six: a worked example

A guest house in Kent, fourteen rooms, currently taking every booking through the OTAs and paying for it. The question they want answered: will enough guests book direct, at our own rates, to justify building this properly? If the answer is no, they stop.

Watch what the three decisions do.

Accounts? No. A booking reference and an emailed link to manage the booking answers the question just as well as a guest account does. That removes 2–4 weeks and both deletion routes, the data-rights plumbing and the retention decision along with them.

Money? Yes — a card deposit at the point of booking, because whether guests will hand over a deposit direct is part of the question. So authentication step-up, both branches, failures, refunds.

Native app? No. Nobody downloads an app to book one night in a guest house.

Now the arithmetic the reader can do and we cannot: 13–16 weeks × their supplier's weekly rate. At the employed floor from part four — £1,368 a week — that is roughly £17,800 to £21,900 of raw engineering cost, which is not a price. It is the cost of the labour with no overhead, no management, no design, no profit and no warranty in it. A quote meaningfully below that number is describing different work or different people, and either might be fine as long as you know which.

The thing to notice is not the total. It is that one decision — no guest accounts — took 2–4 weeks and two compliance obligations out of the build, and it was made in a conversation, not in code. That is what scoping an MVP actually is, and it is the same decision the OTAs have already made for you in the other direction.

The short version

An MVP is an instrument for answering one question, not a cheap version of your product. Anything in it that isn't answering the question is cost, not a bargain.

You can't look up the MVP cost. You can work out the weeks. A base of 6.5–13 developer-weeks for anything at all; plus 2–4 for accounts, 1.5–3 for money moving inside it, and 3–6 per platform for a native app. Those three are decisions, not features, and they move the number more than your choice of supplier does.

Four more lines appear in no quote because nobody sells them as features: accessibility, data protection, store compliance artefacts, and the payment authentication branches. Three are half a week to a week each when built in; the fourth sits inside the payments band. One of them blocks a store release outright and one quietly stops you taking money, and all four cost multiples of that once deferred.

The floor for an employed developer, from published figures, is about £1,368 a week — £54,700 salary plus 15% employer NI above £5,000 and the 3% minimum pension, over 46.4 working weeks. Use it to spot a quote that can't be what it says it is, not to negotiate.

And plan as though there is no R&D tax relief, because the guidelines exclude "routine analysis, copying or adaptation … even though it may be completely new to the company or the company's trade", and most MVPs are exactly that.

Want the weeks for your own idea? Send us the one sentence — if this is wrong, we stop — and the three decisions, and we will send back a block-by-block week count with the assumptions written next to each line, whether or not you build it with us. We do this for our own products too: Stayvieo and FoodCiti were both scoped this way, and both had features cut out of version one that we were sure at the time were essential. Tell us what you're trying to find out, or see what we've built.

Related reading: Nobody can price your software from a blog post · You paid for it. In most countries, that doesn't mean you own it. · Custom software vs off the shelf · What happens when a booking deposit meets a card issuer