MVP & SaaS product development
Build the part that proves the product.
We help founders and teams turn a product idea into the smallest useful release — then design and build the product, admin and data it needs to learn what deserves to exist next.
- Clients
- Tasks
- Roles
- Notifications
- Files
- Chat
- Reports
- Billing
- Automation
- Integrations
- Mobile app
- AI
- Who is it for?
- A small operations team of four.
- What has to work?
- A request moving from incoming to complete.
- What can wait?
- Most of it — until real use says otherwise.
Replace the damaged panel in the lobby
No client — a request has nobody to belong to
- Owner
- Riya
No owner — nobody can be responsible for this
- Request created from an email
- Assigned to Riya
- Moved to In progress
- Marked complete
The job still completes.
The job cannot complete.
Twelve modules, before anyone has used anything.
Illustrative product · sample data
Where it starts
A product idea is not a feature list. It is somebody’s bad afternoon.
The first useful question is not what to build. It is who is stuck, and on what.
A useful MVP starts from the most important problem one real user has, and the smallest workflow that solves it well enough to be used every day. Features that do not help prove that core workflow can wait — not because they do not matter, but because nothing is known yet about which of them will.
- The ideaA client operations platform
- Who uses itA small operations team of four
- What they are trying to doMove a client request from incoming to complete
- What gets in the wayAn inbox, a spreadsheet, and no shared idea of who owns what
- So the product job isEvery request has an owner, a state, and a next step
That last line is the product. Everything else on the list is a decision for later.
The slice
Twelve modules in. Three come out.
Take the rest away and the product still does its job. Take the wrong one and it stops being a product.
Deciding what goes into an MVP is not a matter of cutting until it is cheap. It is working out which parts the core job genuinely depends on, keeping those properly, and letting everything else wait for evidence. Cutting scope should cost the product nothing a user would notice on the first day.
Take a module out and watch the product.
The core job- 01A request arrives
- 02It belongs to a client
- 03Someone owns it
- 04Its state is visible
- 05It gets completed
Nine of the twelve are gone and the job still completes.
Replace the damaged panel in the lobby
No client — a request has nobody to belong to
- Owner
- Riya
No owner — nobody can be responsible for this
- Request created from an email
- Assigned to Riya
- Moved to In progress
- Marked complete
The job still completes.
The job cannot complete.
The first release
One request, all the way through.
This is the whole of version one. It is small, and it is genuinely useful.
An MVP is judged by whether a real user can finish a real job in it, not by how much of the roadmap it contains. If a request can arrive, get an owner, change state and be completed — and the team can see all of that — the product is doing what the first release exists to do.
Replace the damaged panel in the lobby
No client — a request has nobody to belong to
- Owner
- Riya
No owner — nobody can be responsible for this
- Request created from an email
- Assigned to Riya
- Moved to In progress
- Marked complete
The job still completes.
The job cannot complete.
One workflow, four states, and a history. That is a product people can use on Monday.
Underneath
Small scope is not the same as careless work.
The surface is deliberately small. What holds it up is not.
An MVP being small is a decision about scope, not about quality. The first release still needs real accounts, a data model it can grow into, permissions where they matter, validation, sensible empty and error states, and somewhere real to run. Skipping those does not make a product cheaper — it makes the second release a rebuild.
- Clients
- Tasks
- The workflow between them
- Sign in
- Real accounts, because real client data is in here
- Data model
- The shape the product grows into, decided once
- History
- What changed, when, and who changed it
- Validation
- A request that cannot be saved half-made
- Basic admin
- Somebody has to add a client and fix a mistake
- Empty & error states
- The first screen a new user sees is empty
- Deployment
- Somewhere real, that can be updated safely
The opposite mistake is just as expensive: building for a scale, a team and an integration list the product has not earned yet.
What waits
Not now is not never.
Everything cut from the first release is on a list, in an order, with a reason.
Nothing that comes out of an MVP is thrown away. It goes into an order, and the product earns its way down that order: the first release produces real use, real use produces evidence, and evidence decides which of the waiting things gets built next. That is the point of releasing something small — the next decision is made with information instead of opinion.
- NowThe core workflow, used by the team
- Requests
- Clients
- Owners and states
- History
- NextThe first thing daily use will ask for
- Notifications
- LaterWaiting for a reason to exist
- Files
- Reports
- Chat
- Integrations
- If provenOnly once the product has earned it
- Billing
- Mobile app
- Automation
- AI
A thing moves left when the product gives you a reason to move it.
Product maturity
Four different things, often called the same thing.
Most disagreements about an MVP are really disagreements about which of these you are buying.
A prototype exists to test an idea and is not built to be used by real people with real data. An MVP is a real, working release where one core job can genuinely be done. A V1 makes that proven workflow complete enough to rely on. An expanded product adds the roles, workflows and integrations the evidence justifies. They are different pieces of work, and knowing which one you need is most of the scoping conversation.
Is the idea worth building?
- What it is
- Clickable, not connected
- Who uses it
- You, your team, a few friendly users
- Data
- Fake
- One screen flow
- A design direction
- Real accounts
- Real data
- Anything saved
Will people actually use this?
- What it is
- A real product, deliberately narrow
- Who uses it
- Real users, doing real work
- Data
- Real
- The core workflow
- Sign in
- A data model
- Basic admin
- Most of the roadmap
- Reporting
- Integrations
Can we rely on it?
- What it is
- The proven workflow, made complete
- Who uses it
- The whole team, every day
- Data
- Real
- Edge cases
- Notifications
- Better admin
- Support for the awkward days
- Everything a mature product has
Where does it go now?
- What it is
- A product with a roadmap it earned
- Who uses it
- More roles, more companies
- Data
- Real
- More workflows
- Integrations
- Reporting
- Scale where justified
- Anything the evidence has not asked for
Three decisions
The three questions every SaaS MVP has to answer.
None of them has a default answer, and assuming one is how first releases get expensive.
Admin, payments and platform are decided per product, not by habit. A product with real users usually needs somewhere to fix a record. Billing belongs in the first release only when payment is part of what is being tested. And a responsive web app is often enough to prove a workflow that a native app would only make more expensive to change.
Almost always — but a small one.
The moment real users put real data into a product, somebody has to be able to add a client, fix a typo, close an account or look at why something went wrong. That does not mean an admin product. In a first release it is usually a handful of screens the team uses, built on the same data model.
- Add and fix records
- Manage users and roles
- See what went wrong
- A full back-office suite
- Configurable everything
- Its own design system
Only when money is part of what you are testing.
Billing belongs in an MVP when payment is part of what the product must validate, or when the business genuinely cannot run the first release without collecting money. Otherwise it is scope that delays the thing you actually want to learn. Invoicing a first cohort by hand is a legitimate answer.
- Plans and what each includes
- A checkout and a provider
- What access a payment grants
- Renewal, failure and cancellation
- Usage metering before you have usage
- Multiple currencies on day one
- Discounts, coupons and trials at once
Responsive web proves most first workflows.
A responsive web app is usually enough to prove a first workflow, and it is far cheaper to change while the product is still moving. A native app earns its place when the product depends on the device itself, on frequent use away from a desk, on push being central rather than useful, or on app-store distribution.
- Device capabilities the job needs
- Used on the move, not at a desk
- Push is the product, not a nicety
- The store is how users find it
- It feels more serious
- Competitors have one
- It might be needed later
After launch
The release is not the finish line. It is the first real information.
An MVP exists to make the next product decision better than a guess.
Once a first release is in real use it starts answering questions that no amount of planning could. Which part of the workflow is actually used, where people stop, what they ask support about, which requests repeat, and what the team still ends up doing by hand. Those signals are what the next build decision should be made from.
- Release
- Real use
- Signals
- The next decision
- Which workflow is actually used
- And which screens nobody opens
- Where people stop
- The step that quietly does not work
- What support gets asked
- Usually a missing state, not a missing feature
- What requests repeat
- The same ask from different users is a signal
- What the team still does by hand
- The clearest candidate for the next build
What those signals say is genuinely unknown before launch. That is the reason to launch something small.
If something already exists
Most founders are not starting from nothing.
A Figma file, a no-code build, an old MVP, half a codebase. We look before we decide.
We review what already exists before deciding what is worth keeping. Sometimes a design file is most of the product definition and saves weeks. Sometimes a no-code build has already proved the workflow and only needs to be rebuilt where it has hit its limits. Sometimes an old codebase is genuinely worth continuing, and sometimes continuing it costs more than starting again — which is a finding, not a sales position.
- A Figma prototype
- Often the fastest start: much of the product definition already exists
- A no-code build
- Usually proof the workflow matters. Rebuild where it has hit its ceiling
- An older MVP
- Keep the data and the learning; the code is judged on its own
- Part of a codebase
- Reviewed honestly — continued if that is genuinely the cheaper path
- Keep
- Rebuild
- Connect
- Move forward
- The problem is common and well solved
- A good product already exists
- Configuration gets you there
- The software is not the business
- The product is the business
- The experience is the differentiator
- The core workflow does not fit existing tools
- The product, data and control matter
We would rather say this in the first conversation than three months in.
Scope
What makes one MVP bigger than another.
Almost never the idea. Nearly always the count.
Scope on a product build is mostly arithmetic: how many kinds of user, how many workflows, how many platforms, how much has to be administered, and how many other systems it has to talk to. What affects development time most is rarely the cleverness of the idea — it is the number of distinct things that have to be designed, built, tested and supported, and the state of anything being carried over.
- User rolesHow many kinds of person use it
- Core workflowsHow many jobs it has to support
- Data modelHow much the records relate to each other
- PlatformsResponsive web, native, or both
- Admin depthHow much the team has to manage
- PermissionsWho can see and do what
- PaymentsPlans, checkout, entitlement, renewal
- IntegrationsEach other system is its own piece of work
- Multi-tenancySeparate companies with separate data
- Existing assetsThe state of a prototype or codebase carried over
- NotificationsEmail, in-product, or push
- ReportingWhat has to be counted and shown
- ComplianceWhere a standard genuinely applies
- MigrationBringing real data across
If different companies will use the product independently, it needs separate organisations, their own users and permissions, and a real boundary between their data. It is worth deciding early because it shapes the data model — but it is not automatically part of a first release, and a single-company first version is often the right call.
The product, its code and its data are yours. Work is handed over with the repository, the deployment and the access it runs on, and with documentation where that is part of the scope. Hosting and ongoing support are arranged to suit the team you have — some clients take everything in-house at handover, some keep us on. What applies to a given project is written into that project’s scope rather than assumed here.
Selected work
Products and software we have designed and built.
Published projects where people use something we designed, built and shipped.
Selected product and software work. Scope for each project is listed from its own record.
Questions
MVP and SaaS product development, answered.
- What is an MVP?
- An MVP is the smallest real release of a product in which a user can genuinely complete the core job it exists for. It is a working product with real accounts and real data, deliberately narrow — not a demo, and not a first draft of everything.
- What is SaaS product development?
- Designing and building a software product that people use through a browser or app and typically pay for over time. It covers product definition, UX and UI, the application itself, the admin and data foundation behind it, and the staged releases that follow.
- What is the difference between an MVP and a prototype?
- A prototype exists to test an idea: it is usually clickable, not connected to anything, and nothing it does is saved. An MVP is a real product doing real work for real users with real data. A prototype answers whether the idea is worth building; an MVP answers whether people will actually use it.
- What is the difference between an MVP and a V1?
- An MVP proves one core workflow is worth having. A V1 takes that proven workflow and makes it complete enough to rely on every day — the edge cases, the awkward days, the notifications and the better admin that daily use turns out to need.
- What is the difference between MVP development and custom software?
- Custom software usually starts from a business process that already exists and needs better software around it. MVP development starts from a product hypothesis that has not been proved yet, and builds the smallest real release that can test whether users value the core experience.
- What should be included in an MVP?
- The core workflow, the records it depends on, and the foundation that makes it a real product: sign-in, a data model it can grow into, permissions where they matter, validation, sensible empty and error states, basic admin, and somewhere real to run.
- How do you decide what waits?
- By asking what the core job actually depends on. Anything the job cannot happen without stays. Anything else waits for evidence from real use — it goes into an ordered list with a reason, not into a bin.
- Does an MVP need authentication?
- If real users are putting real data into it, yes. Real accounts are part of what makes a first release a product rather than a demo, and retro-fitting them later usually means reshaping the data model.
- Does an MVP need admin tools?
- Almost always, but a small one. Once there is real data somebody has to add a record, fix a mistake, manage users or see why something went wrong. In a first release that is usually a handful of screens on the same data model, not a separate product.
- Does every SaaS MVP need payments?
- No. Billing belongs in the first release when payment is part of what the product must validate, or when the business genuinely cannot operate without collecting money. Otherwise it is scope that delays what you actually want to learn, and invoicing a first cohort by hand is a legitimate answer.
- Should we build a web MVP or a mobile app?
- A responsive web app proves most first workflows and is far cheaper to change while the product is still moving. A native app earns its place when the product depends on the device, on frequent use away from a desk, on push being central, or on app-store distribution.
- Can you work from an existing Figma prototype?
- Yes, and it is often the fastest start — a considered design file is a large part of the product definition. We review it against the core workflow first, because a prototype is usually broader than a first release should be.
- Can an existing no-code MVP be continued?
- Usually the learning and often the data are worth carrying forward. Whether the build itself continues depends on where it has hit its limits — no-code that is working is worth keeping, and no-code that the product has outgrown is worth rebuilding around the same proven workflow.
- Can an existing codebase be reviewed?
- Yes. We look at what is there and say honestly whether continuing it is the cheaper path or not. Sometimes it is, and sometimes rebuilding costs less than working around it — that is a finding we report either way.
- Can AI and integrations be added later?
- Yes, and later is usually the right time. Both are easier to add well once the data model is settled and real usage shows where they would actually help. Designing the data model with them in mind costs nothing; building them before there is evidence usually does.
- Who owns the product, code and data?
- They are yours. Work is handed over with the repository, the deployment and the access it runs on, and with documentation where that is in scope. What applies to a specific project is written into that project’s scope rather than assumed.
- What determines MVP scope?
- How many kinds of user, how many core workflows, how many platforms, how much administration is needed, how the records relate to each other, and how many other systems it has to talk to. The idea itself is rarely what makes a build large.
- What affects development time?
- The number of distinct things that have to be designed, built, tested and supported — plus the state of anything carried over from an existing prototype or codebase, and any decisions still open when the build starts. We scope from your actual workflow rather than quoting a standard number here.
- What happens after launch?
- Real use starts producing signals: which parts get used, where people stop, what support gets asked, what requests repeat, and what the team still does by hand. Those decide what gets built next — which is the reason to release something small in the first place.
- What should we send before starting?
- Who the user is, what they need to do, what you think the first version needs, and whatever already exists — a design file, a no-code build, a codebase or just notes. That is enough to work out what has to be real first.
Start here
Bring us the product idea. We’ll work out what has to be real first.
You do not need a specification. You need to know who is stuck, and on what.
- Who the user is
- The person whose afternoon this fixes
- What they need to do
- The one job, described plainly
- What you think V1 needs
- Your list — we will read it honestly
- What already exists
- A design, a no-code build, code, or nothing