SaaS MVP Development: What It Actually Costs to Ship the First Version

Most advice about minimum viable products tells you to build one feature and ship it. For a great deal of software that is correct. For SaaS it is misleading in a way that costs founders their first budget.

A subscription product cannot ship one feature, because before a customer can use the feature they have to create an account, be charged, and be prevented from seeing another customer's data. None of that is the product. All of it ships first.

This is the version I give founders before they commit to a number, including the parts that make the number larger than they hoped.

What a SaaS MVP actually is

The smallest thing a stranger can sign up for, pay for, and get value from without you personally doing anything behind the scenes. That last clause is the whole test. If someone has to be manually provisioned, or invoiced by hand, or given a spreadsheet afterwards, you have a pilot rather than a product, and pilots teach you far less than they cost.

The difference from a general MVP is structural rather than a matter of degree. A marketplace can validate with a landing page and a human matching people over email. A SaaS product that does that has not tested the thing that makes it a SaaS product.

This is not padding by the developer. Every row underneath is load-bearing, and skipping any of it produces a product that cannot take money or cannot be trusted with data.

The decision that is genuinely expensive to reverse

Nearly everything in a first version can be changed later at reasonable cost. Features get rewritten, designs get replaced, even the framework can be migrated if it comes to that.

One decision is different, and it usually gets made in the first week by whoever sets up the database, often without being discussed: how customers are separated from each other.

Most first versions should use shared tables, because the alternatives cost real money before you have customers. The point is not that shared tables are wrong. The point is that it should be a decision somebody made on purpose, with the risk named, rather than a default nobody noticed.

If you sell to regulated buyers, hospitals, banks, law firms or government, ask before the build starts, because their procurement will ask you later and the honest answer determines whether you can sell to them at all.

What belongs in the first version

The useful scoping question is not "what should we build" but "what can we not launch without". Those produce very different lists.

• Sign up, sign in, password reset. Unglamorous and non-negotiable.
• One plan, one working checkout. Including what happens when a card fails, which is the part that gets skipped and then costs you customers quietly.
• The workflow the product exists for. One. The one you would describe to a stranger in a sentence.
• Separation between customers. Chosen deliberately, per the section above.
• An admin view for you. Who signed up, who is stuck, who is about to leave. Without it you are running the business blind and asking your developer to query the database every time you have a question.

What can wait, almost always: teams and multiple seats, role permissions beyond admin and user, integrations nobody has requested twice, notification preferences, in-app onboarding tours, a second pricing tier, reporting, dark mode, and a mobile app.

The test I use for anything on the second list: has a real person, who is not you and not an investor, asked for this twice? If not, it is a guess, and guesses belong after launch when they are cheap.

Cost and timeline, with the variance explained

A first version built by a small senior team in Canada generally lands between $25,000 and $75,000, reaching real users in 60 to 90 days after two to six weeks of scoping.

The range is wide because of one thing more than any other, and it is not feature count. It is how many systems it has to touch. A product that stands alone sits near the bottom. A product that has to stay in step with a CRM, an accounting system and a payment processor that each have their own idea of what a customer is will sit near the top, because most of the work becomes reconciling disagreements between systems you do not control.

Two honest markers. Below roughly $15,000 you are usually buying a prototype that cannot take a payment, which is fine if that is what you wanted and expensive if it is not. Above roughly $100,000 before launch, scope has stopped being minimum, and the usual cause is that a decision was deferred rather than made.

The largest schedule risk is also not engineering. It is decision latency on your side. Every week a question about billing rules or permissions sits unanswered is a week the build waits behind it, and those weeks are invisible until you add them up at the end.

Choosing a stack, briefly

This matters far less than the internet suggests. Any mainstream choice will carry a first version comfortably, and the failure modes that kill early SaaS products are almost never the framework.

Two things worth insisting on. Pick something your future hires will have used, because an exotic stack narrows your hiring pool at exactly the moment you need to widen it. And do not build your own authentication or your own billing logic. Both look simple, both are full of edge cases that are somebody else's solved problem, and both are where a first version quietly loses a month.

The mistakes that actually recur

• Building for the buyer you want rather than the one you have. Enterprise features in a first version, for a customer who has not signed anything.
• Treating onboarding as a later problem. If nobody reaches the core workflow unaided, you learn nothing from the launch except that your signup form works.
• No analytics at all. Shipping without knowing where people stop means the entire exercise produces opinions rather than data.
• Launching to an audience of nobody. The build finishes and then the founder starts thinking about where users come from, which is the most common way a competent MVP produces zero information.
• Waiting until it is good. The first version is not meant to be good. It is meant to be real enough that the feedback is about the product rather than about a mockup.

How to tell whether it worked

Revenue at this stage is too small to read, and a first month of sales tells you more about your network than about your product.

Three signals that are worth more. Do people come back in week two without an email prompting them. Can a stranger complete the core workflow without help. And when people leave, do they leave for the same reason. That last one is the most valuable finding an MVP can produce: one clear repeated reason beats a modest revenue figure, because it tells you what to build next.

Ship to roughly ten users who will answer the phone rather than to a launch. The MVP's job is to produce information. An audience too large to talk to individually produces less of it, not more.

After the first version

The MVP is a question, not a foundation. Expect to throw away a meaningful part of it, and treat that as the process working rather than as waste.

What should survive is the architecture underneath, which is why the tenancy decision earlier is worth an explicit hour. What should be allowed to change is nearly everything a customer can see. Teams that invert this, protecting their features and rewriting their foundations, spend their second year paying for their first.

If you are choosing someone to build it

Ask what they would cut from your scope, and be wary of anyone who agrees to all of it. A partner who cannot name the thing you should not build yet is selling hours rather than judgment.

Ask who owns the code and the infrastructure accounts. The answer should be you, in your repository and your billing, with nothing you cannot leave.

Ask what happens when the first version is wrong, because it will be partly wrong. What you want to hear is a plan for finding out quickly and cheaply, not a promise that it will not happen.

That scoping work, done properly and paid for before anyone commits to a build number, is the MVP Roadmap. If what you are describing is less a product and more a system your business needs to run on, that is custom software development instead, and the sequencing is different.