The difference between a prototype, an MVP and a product
Before choosing how to build a SaaS, a founder needs to know what the first version has to prove, because the decisions that commit the product are not the same at each stage. The three terms are often used as synonyms, although they refer to different goals.
A prototype to test an idea
A prototype serves to show an idea to potential users, a partner or an investor, and to observe their reaction. It can simulate part of its features, store its data provisionally and handle no payments at all. The founder can throw it away once they have the answers they were looking for, so the technical choices made to build it weigh little on the rest of the project.
An MVP to check that there is a market
Once the idea has been tested comes the MVP, the smallest version of the product that real customers use and, ideally, pay for. Its scope stays narrow, yet people create an account on it and entrust it with their data and sometimes their credit card, which requires it to work reliably. This is the stage at which the first lasting decisions are made, on user accounts, data structure and payments, because these building blocks will stay in place long after launch.
A product built to sustain growth
If the MVP finds its market, the product grows, welcomes hundreds and then thousands of users, receives new features every month and often ends up maintained by several developers. The decisions made for the MVP then show their consequences. The founder starts asking what each user costs, how long a change takes, and who still understands how the whole thing holds together.
Accordingly, a fast and cheap solution suits a prototype launched in two months very well, and the same solution can become expensive for a product with ten thousand customers. The timeline and the available funds therefore weigh as much as the technology in the choice of an architecture.
How much a SaaS costs to build and to run
Each of these decisions has a price. Part of it is paid during development, another part every month for each user, and a last part later, when a choice has to be revisited.
What drives development costs
The first price is paid during development, and two SaaS products that look alike can differ in cost by a factor of five, because their cost depends on the scope of the first version, the number of roles and permissions to manage, the presence of subscriptions and payments, integrations with other tools such as a CRM or accounting software, and the care put into design. Time spent deciding what to build often reduces the rest of the bill, since a feature removed from the scope no longer costs anything. We detailed these mechanisms for websites in one of our articles, and most of them apply to a SaaS.
What a user costs once the product is live
The second price is paid every month. Each active user consumes hosting, database capacity, storage and sent emails, and sometimes calls to AI models if the product uses them. Payments have their own cost too, since providers such as Stripe take a fee on every transaction. Because many of these services bill by usage, getting started is almost free and the bill rises with success. This cost per user depends largely on the services chosen for the MVP. Estimating what it would become with a hundred, a thousand and then ten thousand users, before choosing those services, shows whether the subscription price will be able to cover it.
Technical building blocks that are hard to change later
The last price is paid when a building block has to be replaced, which can be called the exit cost. It varies widely from one block to another. Authentication is among the most expensive, because users' accounts and passwords remain tied to the system that created them, and switching sometimes means asking every customer to reset their access. Data structure and the subscription system carry the same risk. We ran into this problem while building our Better Auth plugin for Medusa, and it arises in the same way for a SaaS.
Subscription pricing and the point where the product becomes profitable
These three costs are weighed against what each customer brings in. The subscription price has to cover the cost of each user with a sufficient margin, and the customers who leave each month have to be replaced for the product to grow. The moment when revenue pays back development depends on these two figures, and this calculation often sets the reasonable budget for building the first version.
Building your SaaS yourself with AI or no-code
Since all these costs follow from the decisions made on scope, architecture and pricing in the very first versions of the product, the three ways of building a SaaS differ in who makes these decisions and in what that person knows of their consequences. Working alone, the founder makes all of them. With a CTO, the founder hands the technical side to a co-founder. With an outside provider, the founder hands it to someone external, who takes a larger or smaller part in thinking about the product.
What AI tools make possible today
This first path has become a serious option because the tools have changed the nature of the exercise. Lovable, Bolt, Cursor or Claude Code produce in a few days an application that would have taken weeks three years ago. The change also reaches the most demanding software companies. Quentin Adam, who runs the French cloud provider Clever Cloud, explains in an interview published in French that AI agents sometimes produce a better implementation than the one he would have written himself, and that the value of developers' work is shifting towards specifications, architecture and testing. These tools have also brought no-code closer to development, since you describe what you want in everyday language and still get code. Writing code is therefore no longer the main obstacle for a founder who is not a developer.
Handling technical choices alone while selling the product
Architecture remains the open question. AI can write the code for any architecture, whether a Postgres database, a Redis cache, file storage or a ready-made backend such as Supabase or Firebase. It builds what it is asked to build, and when it is asked for nothing specific, it picks a default solution. We showed this during our workshop on vibe coding at AI Day in Valenciennes with the example of Node.js, which AI often picks because it dominates its training data, even when it is not the language best suited to the project. A founder building alone therefore makes every decision, or accepts the ones proposed without always knowing their exit cost. That freedom is paid for in time, at the very moment the founder also has to find first customers, talk to investors and refine the offer, so every hour spent on architecture is an hour taken from selling.
What changes as the product grows
The consequences of these decisions rarely appear at launch. They show up when the cost per user rises faster than revenue, when a feature customers ask for does not fit into the chosen tool, or when nobody knows how to check whether the data access rules really protect each customer's information. Many solid products started this way, and their early choices follow them a long way. OpenAI still runs ChatGPT on a single primary PostgreSQL database, backed by nearly fifty read replicas. When writes became too heavy for this database, OpenAI moved part of the workload to other systems and prohibited adding new tables to the primary database. Knowing from the start which building blocks will carry a high exit cost makes it possible to approach such a moment on your own terms.
Bringing in a technical co-founder
When the founder no longer wants to carry these decisions alone, or does not feel able to anticipate their exit cost, they can entrust them to a technical partner. The CTO then takes over the technical side of the decisions, choosing the architecture, building the product and understanding its consequences, which leaves the founder time to focus on the business, and many startups have been built this way. The founder pays for this knowledge in equity rather than cash, with a stake that can reach half the company when the CTO joins at the very start of the project. This knowledge remains attached to one person, so the exit cost here takes the form of a departure. If the CTO leaves the company or the partnership goes badly, the understanding of the product leaves with them, and limiting this risk is the purpose of a shareholders' agreement that sets out departure terms and the gradual vesting of shares. Because everything rests on this person, choosing them takes time, often several months during which the product does not move forward.
Having your SaaS built by an agency or a studio
A founder who wants neither to give up equity nor to make the product depend on a single person can entrust these decisions to an outside provider, paid in cash this time, with a larger upfront budget and a little more preparation time. This investment avoids some of the difficulties described above, provided the technical choices take into account the project's timeline, funds and ambition.
Executing a specification or thinking about the product
Not all providers take the same share of these decisions, however. Some develop what a specification describes, rigorously, and leave every product decision to the founder. Others begin by discussing the market, the business model and what should be built first, then propose an architecture suited to those answers. Both approaches exist among agencies as well as studios. For a founder with a solid idea who does not yet know how to execute it, the second approach changes the nature of the collaboration.
Paying in cash or in equity
As for compensation, a provider is most often paid in cash, which leaves the founder with all of their equity. Some accept payment in shares, alone or combined with a reduced fixed fee, which preserves the project's cash and turns the provider into a partner, with the same dependency questions as a CTO. In both cases, the exit cost depends on what the founder gets back at the end of the engagement. When they leave with the code, the hosting access and the documentation, they can continue with another provider or bring the product in-house. More and more providers work this way.
Choosing according to your goal, timeline and funds
In short, the choice comes down to matching what the project has to prove with the person to whom the founder wants to entrust decisions. A founder who wants to test an idea in a few weeks with limited means is better off building alone, since a prototype's decisions commit little. One preparing an MVP for the first paying customers benefits from having lasting decisions validated by someone who knows their exit cost. One aiming for a durable product, with funds to finance it, can entrust a larger share of decisions to a provider or a co-founder.
Starting alone and changing approach later
This choice is not final, either. Many SaaS products change approach along the way, and this transition is part of the normal life of a product. Changing approach means changing who makes the decisions. A founder who validated the idea with a prototype built alone keeps most of what it produced, the first users, their data, what was learned about the market and often a good part of the design, and the prototype becomes the most precise possible description of what needs to be built. The architecture can be kept and consolidated, or rebuilt on foundations designed for growth, depending on the exit cost of the decisions made at the start.
At Nualt
We can step in at each of these moments in the life of a SaaS. A project may start before any line of code, with a discussion about the market, the business model and the scope of the first version. Another may arrive with a prototype that has found its first users and needs to become a product, and a third may need to put an MVP online within a set deadline. In every case, architecture decisions are made with the founder, based on the project's timeline and funds, and the code, the hosting and the documentation belong to the client, who can continue with us or without us.
Building a SaaS, your questions
The questions that come up when preparing the development of a SaaS.
Can you build a SaaS without knowing how to code?
Yes. AI and no-code tools now make it possible to build a prototype and then a first product without writing code yourself. The founder still has to make or approve the technical choices, which takes time and a basic understanding of what those choices commit them to.
How much does it cost to develop a SaaS?
The cost depends mainly on the scope of the first version and on the payments, roles and integrations it has to handle. A prototype built alone costs a few tool subscriptions, whereas an MVP developed by an outside provider represents a much larger investment. The monthly running cost, which grows with the number of users, comes on top of that.
What is the difference between a prototype and an MVP?
A prototype serves to test an idea and can be thrown away afterwards. An MVP is used by real customers, who entrust it with their data and sometimes their payments, so it has to work reliably on the little it does.
Is Supabase suitable for a SaaS in production?
Supabase suits many products in production. The questions to ask concern how the cost evolves with usage, and how far the application depends on Supabase services beyond the database, since that dependency makes any later move more expensive.
Can the product be built from a prototype made with AI?
Yes, and it is a common starting point. The prototype brings users, feedback and a precise description of the product. The architecture can be kept or rebuilt depending on the choices made at the start and on the product's ambitions.
