The range, and the question it is buying
For a first version of a real software product — something a stranger can sign into and use for its intended purpose — the honest range is $50,000 to $175,000 and eight to fourteen weeks. Narrow single-workflow tools come in under that, sometimes at $25,000. Anything with money movement, a second user type with different permissions, or a regulated data category goes above it and can reach $300,000 without anybody wasting a dollar.
That is a wide band because "MVP" is not a size. It is a purpose. The version is minimum and viable relative to a question you are trying to answer, and until the question is written down the scope has no boundary and the estimate has no meaning. Will a specific kind of buyer pay for this? Can this workflow actually be automated on our real data? Will our operations team abandon their spreadsheet for this? Each of those is answerable with a different, much smaller product than the one usually described in the first meeting.
Write the question in one sentence, and write the observation that would answer it. "Six of the ten pilot customers use it unprompted in week three" is an answer. "It works" is not. Everything the product does that is not required to produce that observation is something you are paying for and will probably throw away.
You are probably here because
- Two agencies quoted the same idea and the numbers are four times apart
- The feature list from the last meeting has thirty items and a June deadline
- You are being asked for a budget number and nobody has written the scope
- The last MVP shipped, worked, and then could not be built on
The cut list below explains most of the four-times gap. The section after it names the six cheap things that should survive every cut, and usually do not.
Four shapes, and what each costs
Most first versions fall into one of four shapes. Recognizing yours is worth more than any hourly rate comparison.
| Shape | What it is | Typical cost | Typical time |
|---|---|---|---|
| One workflow, one user type | A person signs in, does the one thing, sees the result | $25K–$60K | 4–7 weeks |
| A product with a real account model | Teams, invitations, two roles, data that belongs to an organization | $60K–$140K | 8–12 weeks |
| Product with an AI or data component | The above, plus extraction, retrieval or prediction that has to be right often enough | $90K–$200K | 10–16 weeks |
| Money, health or regulated data | Payments, PHI, financial records, or an auditor in the picture | $150K–$300K+ | 14–24 weeks |
The jump between rows one and two is bigger than it looks and it catches people. Adding a second user who can see some things and not others is not a feature, it is a permissions model, and a permissions model touches every screen and every query in the product. If your first version can honestly work with one user type, keep it there. It is the single largest saving available.
What it should not include
Here is the list of things routinely built into a first version that should be cut. Each one is defensible in isolation, which is why they all get in. Together they are typically half the budget and none of them answer the question.
An admin console. For the first few months you have fewer than fifty accounts and an engineer with database access. Build the admin surface when the person who needs it is not on the team, which is a real milestone and not this one.
Single sign-on and SAML. This gets asked for by enterprise prospects and is worth building the day one of them signs a contract contingent on it. Before that it is weeks of work for a checkbox on a form nobody has filled in yet.
A role hierarchy. Two roles at most, and preferably one. Every additional role multiplies the states each screen must handle and the tests that must cover them.
Multi-tenancy done properly. Real tenant isolation is a serious architectural commitment. If you have five pilot customers, separate accounts inside one straightforward data model will hold, and the migration later is a known and bounded job.
Native mobile apps. A responsive web app answers the question. Two app-store submissions, two review cycles and two codebases do not.
A design system. Use an existing component library and accept its opinions. A custom design system is a product in itself, and building one before you know what the product is means building it twice.
Internationalization. Unless you are launching in two languages on day one, extracting every string into a translation framework is a tax paid on work you may delete.
Analytics dashboards for yourselves. You want to know how the product is being used; you do not want to build the tool that tells you. Use an off-the-shelf product analytics service and spend the saved weeks on the product.
Self-serve billing. Unless the question you are answering is specifically "will people put in a card without talking to us," invoice your first customers manually. Subscription billing, proration, dunning and tax handling are a month of work you can buy later in an afternoon.
Microservices, Kubernetes and a message bus. A single deployable application on a managed platform will carry you to a scale you do not have yet. Distributed architecture buys scaling you do not need and costs debugging you cannot afford at this size.
The second persona. The most expensive line in most MVP scopes is the moment somebody says "and the manager will also want to..." Answer the question for one persona. Managers are the second version.
Cut list — how much of a first-version budget each item tends to consume
Approximate share of a first-version budget, from the scopes we are asked to price. Cutting all six is not always possible — cutting three usually is, and that is a third of the project.
The six things nobody should cut
The cheap half of this article. These cost days rather than weeks, and every one of them is regularly cut from a first version by someone trying to be disciplined. Each has a specific, expensive failure it prevents.
A way to delete a person's data. Someone will ask, and in several jurisdictions they have a right to. Doing it later, by hand, across a schema that was not designed for it, is a bad week. Doing it now is an afternoon.
Backups you have actually restored once. A backup nobody has restored is a belief, not a backup. Test it before launch, write down the steps, and note how long it took.
Logs that let you reconstruct what happened. When your first real customer says the number was wrong on Tuesday, you either can answer or you cannot, and the difference is a few lines written at the start.
A hard cap on anything metered. Model calls, third-party APIs, storage, egress. Put a ceiling in the code, not just an alert in a dashboard. Runaway metered spend on a first version is common, avoidable and embarrassing.
Authentication from a provider, never homemade. Use an identity service. Password handling, reset flows, session management and account takeover are solved problems that are expensive to get wrong and cheap to buy.
Deployability by somebody other than the author. One command, documented, that a different engineer can run. Without it the product has a single point of failure who is a person, and that is the state most abandoned MVPs are found in.
The cheapest insurance is a written decision log
Keep a short running file of the decisions made and why — the database chosen, the thing deliberately not built, the assumption about data volume, the customer request that was declined. It takes minutes a week. Six months later, when a different team is deciding whether to extend or rewrite, that file is the difference between an hour of reading and a month of archaeology. It is also the first thing we ask for when taking over someone else's codebase, and it almost never exists.
Why the same product gets quoted at $60K and $250K
Both numbers can be honest. Five things account for nearly all of the gap, and all five are questions you can ask.
How many user types and roles were assumed. Ask directly. This is the biggest single driver and it is often assumed silently in opposite directions by two bidders.
Whether design is included, and what kind. Using a component library with sensible defaults is days. Custom design work with rounds of review is weeks and is a different product experience. Both are legitimate. They are not the same purchase.
What was assumed about your data. If the product touches your existing records, the state of those records dominates the estimate. A bid with no stated data assumption has not looked.
Whether hardening is in scope. Error states, empty states, rate limiting, logging, backups, a security review. A first version with none of that is a demonstration; with all of it, it is a product. The gap between those two is roughly 25 to 40 percent of the build.
Who is doing the work. A senior engineer at $170 an hour who has built this shape of product before is frequently cheaper in total than a $90 hour learning it, and you cannot see that on a rate card. Ask what similar systems the specific people have built, not what the firm has done.
Where a well-run first version actually spends its hours
Shares sum to 100. Our typical distribution on a first version that reaches real users. If a quote puts more than half the hours in row one, the other rows are missing rather than free.
Send us the feature list and we will send back the cut list.
Email the scope, the question you are trying to answer and any quotes you have received to contact@precisionfederal.com. You get back a short written note marking what we would cut, what we would keep, and where we think the quotes differ from each other. One business day, no charge, no meeting.
contact@precisionfederal.comThe trap: the MVP that becomes production without anyone deciding
This is the expensive failure and it is not a technical one. A first version ships, it works, customers start using it, and nobody ever holds the meeting where somebody says "this is now the product, and here is what it needs to become one." Two years later the shortcuts that were correct at week six — no tenant isolation, one deploy environment, one role, no test suite — are load-bearing, and the cost of unwinding them is larger than the original build.
The fix is a scheduled decision, written into the plan at the start: at the end of the MVP, and again ninety days after launch, someone reviews the answer and picks one of three paths. Stop, because the answer was no. Continue as-is, because it is still an experiment. Or graduate it, which means funding a specific, named list of things that were deliberately skipped. Write that list during the build, while the reasons are fresh. It is the most valuable document the project produces and it takes an hour.
Time, and why eight to fourteen weeks is the honest answer
Shorter is possible and usually means one of three things: the scope is a single workflow, an existing codebase is being extended, or the count excludes the weeks before anyone wrote code. That third one is the common distortion. A build that "took six weeks" often had four weeks of scoping, design and data access in front of it that nobody counted.
The weeks that get compressed under pressure are the last two, and they are the ones that determine whether real people can use the thing: error states, the empty first-run experience, the deploy, the data, and watching someone use it who has never seen it. Compressing those does not save time. It moves the work into the launch, where it costs more and is visible to customers.
One scheduling note worth planning around: getting access to your own data and systems takes longer than anyone expects. Credentials, a security review, an environment, a sample export that is representative rather than convenient. Start that on day one, in parallel, or it becomes the critical path in week three.
What you should own when it ends
- The repository, in your organization, from the first commit rather than at handover
- Every account and credential in your name, not the vendor’s
- A one-page runbook: how to deploy, where things live, what to do when it breaks
- The written list of what was deliberately skipped, and why
- The decision log, however short
- A restore of the backup, performed once, with the steps written down
- The observation that answers your original question, stated plainly
- An estimate for the graduation list, so the next decision has a number attached
Where the money gets wasted
- Building for a scale that has not arrived, and paying the complexity every day until it does
- A second user type added in the first meeting because it seemed small
- Custom design before the product is known, so the design is redone with the product
- Self-serve billing for customers who are being invoiced by hand anyway
- No hard cap on metered spend, discovered on a monthly bill
- Skipping error and empty states, then handling every case in support instead
- Launching without a written question, so no result can count as an answer
- No decision point after launch, so the experiment quietly becomes the production system
Bottom line
Write the question first and the observation that answers it, then cut everything that does not serve it. Expect $50,000 to $175,000 and eight to fourteen weeks for a real first version, less for a single workflow, more for money or regulated data. Cut the admin console, the second role, the design system, the mobile apps and the billing. Keep the deletion path, the tested backup, the logs, the spend cap, bought authentication and a deploy anyone can run — six cheap things that decide whether the thing you built can be built on. And schedule the meeting where somebody decides whether this is still an experiment, because the most expensive MVPs are the ones that became production while nobody was looking.
Frequently asked questions
For a product a stranger can sign into and use, $50,000 to $175,000 and eight to fourteen weeks is the honest band. A single workflow with one user type can be done for $25,000 to $60,000. Payments, health data or an auditor push it to $150,000 and up. The spread is driven by scope decisions rather than by hourly rates, which is why the cut list matters more than the rate card.
Admin consoles, single sign-on, role hierarchies, real multi-tenancy, native mobile apps, a custom design system, internationalization, internal analytics dashboards, self-serve billing, distributed architecture, and the second persona. Each is defensible on its own, which is how they all get in. Together they commonly account for half the budget and none of them answer the question the first version exists to answer.
A way to delete a person's data, backups you have actually restored once, logs good enough to reconstruct an incident, a hard cap on any metered service, authentication bought from a provider rather than written yourself, and a deploy that someone other than the author can run. All six cost days, not weeks, and each prevents a failure that is expensive and slow to fix later.
Almost always because they assumed different scopes rather than different efficiency. Ask each: how many user types and roles did you assume, is design included and what kind, what did you assume about our existing data, is hardening in scope, and who specifically will do the work. Those five questions usually explain the whole gap, and they frequently reveal that the cheaper bid is a demonstration rather than a product.
You can build on it if the shortcuts were chosen deliberately and written down. The ones that are hard to unwind are tenant isolation, the permissions model and the data model; the ones that are easy to add later are admin surfaces, billing and integrations. Keep a list during the build of what was skipped and why, price that list at the end, and make continuing an explicit funded decision rather than a default.