There is no list price for an MVP, and anyone quoting one from a sentence is guessing. Cost is driven by six things: how many user roles exist, how many external systems you must integrate with, how strict the compliance requirements are, whether the data exists yet, how many people can approve decisions, and the deadline.
One user role is one set of screens, one permission model and one story to test. Three roles — say a customer, an operator and an admin — is not three times the work, but it is close to double, because every rule has to be right from three angles. If you want the fastest cheapest MVP, ship for one role and add the others once real usage tells you what they need.
This is the single biggest driver, and the most underestimated. A build that stands alone is predictable. A build that must reconcile with an ERP, a payment provider and a legacy database somebody's cousin wrote in 2011 is a different project — most of the risk is in systems you do not control, whose documentation is wrong and whose owners are busy.
Cost scales with the consequences of failure. An internal tool that mislabels something and gets corrected by a person is cheap. Anything touching money, health, or a legal record needs audit trails, review steps, tests around the edges and someone accountable. That is not gold-plating; it is what the domain actually requires.
AI features are only as good as the material they run on. If you already have the documents, the historical decisions or the labelled examples, we can build against them in week one. If the honest answer is that the data is in people's heads or in a shared drive nobody has opened since 2023, the first stretch of work is collecting it, and that is a real cost line rather than a rounding error.
A build with one decision-maker moves at the speed of the work. A build with a committee moves at the speed of the calendar, and calendars are expensive. This one is entirely in your control, and it is usually worth more than any discount you could negotiate: name one person who can approve scope changes.
A date that exists for a real reason — a trade show, a funding round, a contract — is useful and we will build to it. A date that exists because a deadline felt motivating costs money and buys nothing. If the date is real, say so early: it changes what we would cut, and cutting early is cheaper than cutting late.
Clients often open with the stack, and it is close to the least important variable. Framework, cloud and model provider are decisions we make in an afternoon and could change later without touching what the product does. Spending the first call on them is spending it on the one thing that will not move the number.
A fixed part for the build, so you know the exposure before starting, and a variable part tied to one metric you choose. If the metric does not move, the variable part is not charged. It is unusual, and it exists for a simple reason: it is the only arrangement we know where the studio's incentive after delivery still points the same way as yours.
Not an honest one. The same one-line description can be a three-week build or a six-month programme depending on integrations and compliance, and a number given before knowing which is a number designed to be renegotiated later.
One thirty-minute call, then the scope and the number in writing within a couple of days. You keep both whether you hire us or not — including if you take them to another studio.
Thirty minutes, a written scope, and a figure you can take anywhere.