You have an idea for a software product that businesses would pay for every month. You may already have a feature list, and it is probably long. The first decision in SaaS MVP development is not which technology to use. It is which parts of that list go into the first release, which parts your own team can do by hand for a while, and which parts wait until a customer asks for them.
We are a product engineering team at Infopark in Kochi. We build SaaS platforms for businesses in India, the UAE and Australia. This guide is the conversation we have with a founder before any code is written, including the cases where our advice is not to build yet.
The short answer
A SaaS MVP should do one job completely for one kind of customer. Build that one workflow, and build the account foundation under it properly: sign-in, separate data for each customer, and basic roles. Do everything else by hand or leave it out. If you have not yet confirmed that anyone will pay, test the idea with something simpler before you commission software.
Before you build: can you test the idea without software?
An MVP answers one question: will people use this and pay for it? Sometimes that question can be answered more cheaply without a product. If so, answer it that way first.
Run the service by hand for three or four customers. Use spreadsheets, forms and messages behind the scenes. You learn what they value and what they ignore.
Show a clickable design prototype to ten people who have the problem. Ask them to walk through it and tell you where it fails them.
Ask for a commitment. A signed letter of intent or a paid pilot tells you more than any number of people saying the idea sounds good.
Check whether an existing product, configured well, already solves the problem. If it does, your idea needs a sharper edge before it needs code.
Build when the manual version is working and the manual effort is the thing holding you back. At that point you know the workflow from experience, and the software has something real to copy. If nobody will commit to the manual version, software will not change their mind.
What a SaaS MVP is, and what it is not
A SaaS MVP is the smallest version of the product that a real customer can use for real work and would pay for. It is narrow, but the part that exists is finished. A customer can sign up or be signed up, do the one job, and come back the next day to find their data where they left it.
It is not a demo. A demo impresses in a meeting and breaks in daily use. It is also not the full product with every feature half built. Ten features that each work halfway are worth less to a customer than one feature that works every time.
A SaaS product also differs from ordinary business software in one way that matters here. It serves many customer companies from one system. That fact shapes the foundation, and the foundation is the one place where cutting corners in the first release costs more later.
What goes in the first release
Sort every item on your list into three groups: build now, do by hand for now, and leave out. The table shows where the common items usually fall.
| Part of the product | First release | Why |
|---|---|---|
| The core workflow | Build now, completely | It is the reason a customer pays. It has to work every time. |
| Sign-in and password reset | Build now, using a proven service or library | Customers will not use a product they cannot get back into. |
| Separate data for each customer | Build now | Adding this boundary later means reworking most of the product. |
| Basic roles, such as admin and member | Build now, two or three roles only | Most customer companies need at least one person in charge of the account. |
| Customer onboarding | Do by hand | Setting up the first customers yourself teaches you what onboarding needs to do. |
| Billing and invoices | Do by hand or with a payment link | A handful of customers can be invoiced manually. The product only needs to know which plan each one is on. |
| Reports and dashboards | One or two that customers ask for | Reports are easy to add once you know which numbers people act on. |
| Integrations with other software | Leave out unless the product is useless without one | Each integration is its own build and its own maintenance. |
| Mobile app | Leave out. Make the web version work well on a phone | A dedicated app is a second product to build and maintain. |
| Custom branding, many languages, advanced settings | Leave out | These matter to later customers, not to the first ones. |
One workflow, done completely
Pick the single job your product does better than the spreadsheet or the tool it replaces. Follow it from start to finish. If the job is raising a quotation, the customer must be able to create it, change it, send it and find it again next month. Every screen on that path gets built and tested. Screens off that path wait.
A useful test is to describe the first release in one sentence that names the customer and the job. If the sentence needs the word "and" three times, the release is still too wide.
The account foundation
Under the workflow sits the part customers never praise and always notice when it is missing. Each customer company has its own account. Its users sign in. Its data is kept apart from every other company's data. Somebody in the company can invite colleagues and remove them.
How accounts, roles, billing and usage limits work is cheap to decide at the start and expensive to change in the second year. We settle those questions before the first feature ships. That does not mean building all of it. It means the first release is built on a tenancy boundary and a simple record of which plan each customer is on, so that billing and limits can be attached later without rebuilding.
The basics that protect you
A first release also needs a few things no customer will ask for. Automatic backups that have been tested by restoring one. A staging environment where changes are checked before customers see them. Error reporting, so you learn about a failure from the system and not from an angry call. A privacy policy and terms that match what the product does with data.
What your team can do by hand
With five or ten customers, your own people can do work that software will do later. This is not a shortcut to be embarrassed about. It is how you find out what the software should do.
Create each customer account yourself and load their starting data for them.
Send invoices from your accounting software and record the plan in an admin screen.
Handle plan changes, refunds and cancellations on request.
Answer support questions directly, and keep a list of the ones that repeat.
The repeated questions and the repeated manual steps become the plan for the second release. Automate a task when doing it by hand starts to slow growth, not before.
What to leave out, and what it costs you
Leaving a feature out is safe when it can be added later without disturbing what exists. Reports, integrations, extra roles, notifications and a mobile app are usually in this group. They sit on top of the product.
Leaving something out is risky when it sits under the product. Data separation between customers is the main example. So is the basic shape of the data: what a customer, a user and a record are, and how they relate. Spend your design time there. Our product engineering work starts with a product definition for this reason: the problem, the audience, the measurable outcome and the smallest version that can prove it.
How a SaaS MVP build usually runs
A sensible build starts with a short discovery, moves in short cycles and puts working software in front of you early.
Discovery. A short paid phase, typically one to three weeks, that produces the product definition, an architecture direction and a delivery plan. You can take that plan to any team, including someone else.
Design the core workflow. Screens for the one job, tested with people who have the problem.
Build in fortnightly cycles. You see working software every fortnight, so scope decisions are made against something you can click.
Pilot with a small group. Real customers, real data, and your team doing the manual parts.
Measure, then decide. Keep what customers used, cut what they did not, and plan the next release from evidence.
This follows the same six-stage process we use on every product. A focused first release typically takes weeks to a few months from discovery to go-live. The time depends on integrations and on how quickly decisions are made, so treat any figure given before discovery as a guess.
Common mistakes in a first release
Building for three kinds of customer at once. Each one needs different screens, and none of them gets a finished product.
Automating billing before there is anyone to bill.
Treating data separation as something to fix after launch.
Adding features to avoid launching. Feedback from one paying customer is worth more than another month of building.
Choosing a team on price alone. Our guide on how to choose a software development company lists what to check first.
Having no way to see what customers do in the product. Without usage data, the second release is planned on opinion.
Frequently asked questions
What is a SaaS MVP?
A SaaS MVP is the smallest version of a subscription software product that a real customer can use for real work and would pay for. It does one job completely, on a proper account foundation, and leaves the rest for later releases.
How long does SaaS MVP development take?
It depends on the workflow, the integrations and how quickly decisions are made. A focused first release typically takes weeks to a few months from discovery to go-live. A short discovery phase is what turns that range into a plan.
Does an MVP need subscription billing?
Usually not in the first release. The first customers can be invoiced by hand or sent a payment link. The product should still record which plan each customer is on, so that automated billing can be connected later without rework.
Should the MVP be multi-tenant from the start?
In most cases, yes. You can start with one customer per installation and add tenancy later, but it is the most expensive change we see teams make. We usually build the tenancy boundary from the start, even when the first customers are onboarded by hand.
Do I need a mobile app in the first release?
Rarely. A web product that works well in a phone browser serves most first customers. Build a dedicated app when the job needs something a browser cannot do well, such as working offline. Our guide to mobile app development cost in India explains what an app adds to a budget.
Who owns the code of an MVP built by an agency?
You should, and the contract must say so. On our projects the source code, designs, database and hosting are in the client's name from the first day, and no per-user licence is paid to us.
Conclusion
A SaaS MVP is a decision about what to leave out. Test the idea by hand first if you can. When you build, build one workflow completely, put it on a foundation that keeps each customer's data apart, and let your team do the rest manually until the manual work is the bottleneck. The second release then comes from what paying customers did, not from the original list.
If you have a product idea and a list that feels too long, tell us what the product has to do. We will come back with the questions the first release depends on, and a straight answer on whether it is time to build.
Human. Digital. Future.
