Insights
A SaaS MVP proves one promise to a real user. Keep everything that promise depends on, including roles, permissions and recovery, and leave the rest out. A SaaS MVP has to prove one promise: that a named user can get a named job done, on their real work, well enough to come back and, in B2B, to pay.
A SaaS MVP has to prove one promise: that a named user can get a named job done, on their real work, well enough to come back and, in B2B, to pay. Everything that promise depends on belongs in the first release, however unglamorous: the roles and permissions, the full life of the core record, the exception real work runs into and the way to recover from a mistake. Everything else can wait, including the settings pages, dashboards and integrations that make a product look finished.
The mistake to avoid runs the other way. "Minimum" gets read as "fewer screens", so teams keep breadth and cut the parts that make the core promise hold.
Minimum means least effort for the learning, not fewest screens
Eric Ries, who popularised the term, defined the minimum viable product in August 2009 as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." In the same post he warned that an MVP, "despite the name, is not about creating minimal products."
The definition is about a question and its answer. "Minimum" applies to the effort, and "viable" to whether the answer is trustworthy. A release that is small but fails the first time a second user logs in, or the first time an import has a bad row, teaches you nothing about the promise. It only tells you the release was incomplete.
So the scoping question is not "how few features can we ship?" It is "what is the least we can build that lets a real user test the promise, on real work, without us standing beside them?"
Name the promise, the assumption and who must be convinced
Write three sentences before anyone writes a feature list.
The promise. One user, one job, one outcome: "A finance team can route each supplier invoice to the right approver and know it is approved before the payment run." If you need two sentences, you probably have two products.
The assumption the release will test. An early release tests one of four assumptions, and each needs different evidence:
| Assumption | The question | What can answer it |
|---|---|---|
| Desirability | Do they want this way of doing the job? | Interviews and a clickable prototype can show intent |
| Workflow fit | Can each role complete the job inside their real working day? | Testing with every role, then real use |
| Willingness to pay | Will they pay, or commit budget, for it? | Only a commitment: a contract, a paid pilot, a purchase order |
| Technical feasibility | Can it be built to work with their data and systems? | A coded prototype or a technical spike |
The split is close to the four big risks Marty Cagan set out in 2017 (value, usability, feasibility and business viability), adapted for a founder scoping a first release.
Who must be convinced. First customers, investors and your own team each accept different proof. A first customer needs the job done. An investor reading your traction needs evidence that customers use the product and would miss it. Your team needs to know whether to keep going, change direction or stop. Pick the audience for this release, and scope the evidence for that audience.
Writing the assumption down is more than tidiness. In a randomised controlled trial of 116 Italian startups published in Management Science in 2020, Arnaldo Camuffo and colleagues found that founders taught to state hypotheses and test them rigorously performed better and were more likely to pivot to a different idea than a control group who had the same general training but were left to follow their intuition. The study tested a way of deciding, not MVP scope as such, but it supports the habit this article depends on: decide in advance what result would change your plan.
Sort every feature into core, supporting and later
At Tcules, we interviewed Karthik Pasupathy for our My Experiments with UX series, and he described a three-way split that makes a good sorting rule. For his journaling tool DayNotes, the core function was text entries with headings, content, date and time stamps and location; the supporting functions were editing, deleting and moving entries between dates; and an "On this day" view was a good-to-have. Entries were limited to 280 characters. His summary: "You don't need folders or search bars to start. You just need to make the core action frictionless."
The useful part is the middle category. A supporting function is one the core cannot work without for a real user. Deleting a journal entry is not the promise, but a journal you cannot correct is not usable.
In B2B the supporting layer is larger. Here is the invoice-approval promise above, sorted. It is an illustration, not a client project:
| Core: the promise itself | Supporting: the promise fails without it | Later: valuable, not needed to prove the promise |
|---|---|---|
| Create an invoice record from an upload | Roles for submitter, approver and finance admin | Analytics dashboard |
| Route it to an approver by amount | Approval limits each approver cannot exceed | Custom workflow builder |
| Approve or reject with a reason | Admin setup of users and limits | Integrations beyond the one accounting system the first customers use |
| Show its status before the payment run | Import of existing suppliers from the current spreadsheet | Mobile app |
| Rejection, correction and resubmission | Theming and white-labelling | |
| A record of who approved what, and when | Single sign-on, unless the first customers' IT requires it | |
| A nudge when an invoice waits too long |
The test for the middle column: remove the item and ask whether the first customer could still complete the job, on their own data, with their own colleagues, without calling you. If the answer is no, it is supporting, and it ships.
When we build a SaaS product, we check the first release against six concerns, each phrased as a question the release must answer:
| Concern | The first release must answer |
|---|---|
| Roles and access | Can the intended users enter and act safely? |
| Core object | Can it be created, changed, found and understood? |
| Workflow | Does normal and material exceptional work complete? |
| Integration | Is state dependable across systems? |
| Operations | Can the team support, observe and recover the product? |
| Learning | Which assumption will the release test? |
What B2B adds that consumer MVP advice leaves out
MVP advice written for consumer apps pictures one person using one app. A B2B product is used by an organisation, and that changes the minimum.
More than one role. The person who buys, the person who sets it up and the people who do the work are different, and each has to get something done. At Tcules, we found this on the Auxentios CPQ product: before designing, we ran eight user interviews with people in different countries across six roles (sales representative, sales manager and product, pricing, solution and maintenance experts). The feature list came from the problems those interviews surfaced, together with the client's requirements. Because the system was going to have more than 200 screens, after designing the core experience we designed documented components that developers could use to build new screens, with key screens as examples rather than every screen drawn.
Permissions. Who can see, change and approve what is part of the product's behaviour, not a later hardening task. The OWASP Top 10:2025 keeps broken access control at number one and reports that 100% of the applications tested had some form of it. An MVP that lets an approver exceed their limit has not proved the promise; it has made a different one.
An admin who sets things up. Someone has to invite users, assign roles and set the rules before anyone else can start. If that person needs you on a call to do it, the release has not been tested; your team has.
Data import. B2B customers arrive with history: suppliers, accounts, products, open records. A product that starts empty asks them to retype it before they can judge it. A plain import of the file they already keep belongs in the supporting column, not the later one.
The tool you must beat or live alongside. The Auxentios research found users moving between separate tools for opportunities, communication, contracts and quotations. Your first customers have an equivalent: a spreadsheet, a shared inbox or an older system. Decide whether the MVP replaces it for the promised job or sits next to it, and if next to it, how data gets back and forth.
Misuse. In our interview with him, Karthik Pasupathy told us of stories he had heard about a tool where unlimited file uploads, meant to let customers submit any number of bills, turned it into cloud storage for any file: "UX needs to account for potential misuse, too." In B2B, the limits are part of the scope.
Leave things out on purpose, and write the omission down
Every MVP leaves things out. The difference between a deliberate omission and a gap is whether anyone decided.
| A deliberate omission | A gap |
|---|---|
| Is on a written list, with the reason it waits | Nobody listed it |
| Does not break the promised job | Breaks the promised job for some role or some case |
| Has a workaround the first customers have been told about | Is discovered by the customer |
| Has a signal that would bring it in, such as three customers asking or a deal that depends on it | Arrives as a support request, a spreadsheet on the side or a job that never finishes |
To find gaps before customers do, walk the promise once per role and ask "what happens when...?": when the data is wrong, when the approver is away, when someone loses access, when an import fails halfway, when two people edit the same record. Each answer is either already in scope, a deliberate omission with a workaround, or a gap to close before release.
Prototype, coded prototype or first release: which answers which question
Not every question needs a release. Building one to answer a question a prototype could answer costs time; showing a prototype to answer a question only a release can answer gives you false confidence.
| If the question is | The cheapest thing that can answer it |
|---|---|
| Do the people with this problem want this way of solving it? | Interviews and a clickable design prototype |
| Can each role understand and complete the workflow? | A clickable prototype tested with every role |
| Does it work with real data, model output or a real integration? | A coded prototype |
| Will they use it in real work, return to it and pay for it? | A first release in the hands of real users |
The UK government's Service Manual draws the same line for public services: in alpha, "build things that are just complex enough to let you test different ideas, not production quality code," and expect to throw away the code and many of the ideas tested. Beta is where you "take your best idea from alpha and start building it for real."
At Tcules, we use a coded prototype when the evidence depends on real data, model output, browser behaviour or technical feasibility. We record what is real and what is simulated, and the prototype ends in a deliberate decision: retire it, harden it into a product slice, or carry selected parts into delivery. If you already have a prototype built with AI tools and are deciding whether it can become the first release, we cover that path in I vibe-coded an app. Now what?
How to know the MVP has proved its promise
Decide the evidence before release, in the same document as the promise. Four things show that a B2B first release has proved its promise to its first customers:
- Completion. Each role completes the promised job on their own data without your team's help.
- Return. They come back for the next instance of the job without being prompted.
- Replacement. The spreadsheet or old tool stops being used for that job.
- Commitment. They pay, sign, or put more of their team on it.
Survey measures can help once you have enough users. In a 2018 First Round Review article, Rahul Vohra, then founder and CEO of Superhuman, described the survey Sean Ellis devised: ask users how they would feel if they could no longer use the product, and measure the share who answer "very disappointed". Vohra reports that, after benchmarking nearly a hundred startups, Ellis found that 40% was the line: companies with strong traction "almost always exceeded that threshold". Vohra notes that results become directionally correct at around 40 respondents. A B2B first release with a handful of customer accounts may not reach that many respondents; until it does, the account-by-account evidence above is the better test.
At Tcules, we design release evidence with the product: acceptance covers normal, exceptional and recovery paths using representative roles and data, and analytics are chosen because they could change a product decision. A result that says "no" is still a result. If the promise did not hold, the release has done its job, provided you decided in advance what you would do next.
Who can design and build a B2B SaaS MVP
Whoever you choose, a few questions show quickly whether they will scope the release around a promise or around a feature list:
- Do they ask what the release must prove, and to whom, before they ask for features?
- Will they talk to each role that will use the product, not only the founder?
- Do they treat roles, permissions, import and recovery as part of the first release?
- When they build a prototype, do they say what is real and what is simulated?
- Do they say who will host, monitor and support the product after launch?
Tcules is a digital product design studio creating ambitious new software products and making established ones better. Product design is the foundation of our work, extended by design engineering and software development, and we focus particularly on SaaS. We were founded in 2017, are based in Ahmedabad, India, and have delivered more than 90 projects for clients across 19 countries.
For a new SaaS product, we define the first release around one product promise and include the actors, records, workflow, states and services that promise needs. We can take responsibility from research and product definition through frontend, backend, integrations, QA and deployment configuration, within the boundary we agree, and defined projects are priced on their agreed scope. That is how we approach SaaS and Web Application Development. If you are weighing how to staff the design work itself, our guide to dedicated, fractional, subscription or senior-led design help covers that choice.