How to Decide What Belongs in an AI SaaS MVP

Almost every AI SaaS plan I see has the same problem. It is too big and too small at the same time.

Too big, because it lists a dozen features: multiple AI modes, integrations, team collaboration, analytics, a marketplace. Too small, because it skips the unglamorous things that make the one core feature usable by someone other than the founder: accounts, permissions, saved state, what happens when the model fails, how anyone will know if the product is working.

I have made this mistake with my own products, so I do not say it from a distance. This article is the scoping method we now use at Technobita, both for our own SaaS and for founders who come to us with an idea. It is not complicated. It is mostly about asking one question with discipline.

Start with the job, not the feature list

Feature lists are seductive because they feel like progress. You can add to them, reorder them, show them to investors. But a feature list does not tell you what the product is for.

The first thing we write down is the job. One sentence. Who is the user, what are they trying to accomplish, and what does success look like from their point of view? Not "an AI platform for prompts". Something like: a person who knows what they want from AI but writes vague prompts gets a structured, stronger prompt they can trust and reuse.

That sentence does a lot of work. It names the user. It names the problem. It implies the outcome. And it gives you a test for every feature that anyone proposes afterwards: does this help that person do that job, or is it something else?

If you cannot write the sentence, do not start scoping. You are not ready. That sounds harsh, but it is far cheaper to spend a week on the sentence than three months building the wrong thing.

The one-workflow test

Once the job is clear, the MVP question becomes simpler. What is the smallest complete workflow that does the job end to end?

The important word is complete. An MVP is not a demo of the exciting middle step. It is the whole loop, from the user arriving with their problem to the user leaving with their outcome and being able to come back. If the loop has a gap, the user falls through it and never returns.

For Promptelligence, the loop looked like this. The user writes a rough idea. They choose the task type and how much depth they want. The product structures the idea into a prompt. It evaluates the result so the user can see the improvement. The user refines it in plain English if it is not quite right. The user saves it so it is there next time.

Every one of those steps is in the MVP. Not because each one is impressive on its own, but because removing any of them breaks the job. Without evaluation, the user cannot tell whether the output is better. Without refinement, every imperfect output is a dead end. Without saving, the value evaporates after one session. The loop is the product.

An MVP is not a demo of the exciting middle step. It is the whole loop, from the user arriving with a problem to leaving with an outcome and being able to come back.

What has to be in, even if it is boring

Here is the part that gets cut from most AI MVP plans and should not be. These are not features. They are the conditions for the features to work for real people.

• Accounts and ownership. Someone has to be able to log in and find their own work. Even a single-user product needs this the moment a second person signs up.
• Workspace or tenancy structure, at least in the data model. You do not need team features on day one, but if every record is not already tied to an owner or workspace, adding teams later means a painful migration.
• Persistent state for the core objects. The thing the user created has to exist tomorrow. This sounds obvious and is skipped constantly in AI products built around a chat box.
• A defined output contract for every AI step. The model returns a structure the application validates, not free text the UI prays is well formed.
• Failure handling that keeps the workflow intact. The model will be slow, wrong or unavailable. The user should see something honest and keep their work.
• A basic cost control. A limit, a tier, or at least visibility, so that volume does not surprise you in month two.
• A way to learn. Some record of what users did and where they stopped. Without it, you will make the second version based on guesses.

What can wait, even if it is exciting

And here is the list that founders find hardest to accept. These are good ideas. Many of them are on our own roadmaps. They do not belong in the first version, because they do not complete the loop, they widen it.

• Additional AI modes. Promptelligence will have dedicated image and video prompt modes. The MVP had text, because text was the job. Each new mode is a new workflow with its own evaluation, not a checkbox.
• Integrations with other tools. Valuable later, expensive now, and each one is a reliability dependency you do not control.
• Team collaboration features. Sharing, comments, roles beyond the basics. Build the data model to allow them. Build the features when users ask.
• Analytics dashboards for the user. First prove the core output is worth measuring.
• A marketplace, a community, a template library of other people's content. These are growth features. They assume a product that already works.
• Optimisation for specific target AI systems, fine-tuned models, agents that act autonomously. All of this is architecture you can add once the simple version has shown you what users actually need.

The Promptelligence decisions, honestly

I want to show what this looks like in practice rather than in theory, so here are the actual scope decisions we made for Promptelligence and the reasoning behind each.

Transformation, evaluation and refinement went in together. We considered shipping transformation alone, because it was the impressive part. We decided against it because a transformation the user cannot evaluate or adjust is just a different kind of guesswork. The three together are the job.

Enhancement levels went in. Smart, Deep Think and Elite. This was partly a product decision, giving the user control over depth, and partly a cost decision, making the expensive operations a deliberate choice. One feature solved both problems, which is usually a sign it belongs in the MVP.

Templates and a library went in, in a simple form. We debated this one. It is not part of the transformation. But the job sentence said "trust and reuse", and reuse without a library is not reuse. So a basic version was in scope and the fancier organisation features were not.

Workspaces went in as a foundation, not a feature. The data model knows about workspaces from day one. The interface barely shows them. This is the pattern I recommend most often: build the structure, defer the surface.

Image mode, video mode, target-AI optimisation and deeper brand context all stayed out, and they are still labelled as planned until each one is actually verified in the product. Not because they are bad ideas, but because each one is its own loop with its own evaluation, and shipping a half-built loop is worse than shipping none.

Cost and model choices in an MVP

A question I get a lot: should the MVP use the best model or the cheapest one? My answer is that the MVP should make model choice a decision the product can change, not a decision the product is built around.

Concretely, that means the model call lives behind a clear contract. The application knows what it sends and what it expects back. If you swap the model, the contract still holds and the evaluation tells you whether quality moved. Build that boundary and the question of which model becomes a tuning decision you can revisit monthly rather than an architecture decision you are stuck with.

It also means thinking about where the cost sits. If one step is expensive, can it be a user choice, like a deeper enhancement level? Can context be reused instead of rebuilt? Can a cheaper model handle the simpler jobs? These are MVP questions because they shape the workflow, and the workflow is hard to change later.

Make model choice a decision the product can change, not a decision the product is built around.

A scoping exercise you can do this week

If you have an AI SaaS idea and a feature list, here is the exercise we run. It takes a few hours and it usually changes the plan.

• Write the job sentence. One user, one problem, one outcome. Rewrite it until everyone on the team agrees it is right.
• Draw the loop. Every step from the user arriving to the user coming back. Mark where the AI acts and where the user or the software acts.
• For each feature on your list, ask: does the loop break without it? If yes, it is in. If the loop still completes, it is later. Be honest. Most things are later.
• Add the boring conditions. Accounts, ownership, persistent state, output contracts, failure handling, cost control, a way to learn. These are in by default.
• For every AI step, write its job in one sentence and decide what the application checks before using the result.
• Write down what you are deferring and why, so the roadmap is a record of decisions rather than a wish list.
• Estimate the loop. If it is still too large, the job sentence is probably too broad. Narrow the user or the problem, not the loop.

The point of a small first version

A small MVP is not about doing less work. The boring conditions alone are a lot of work. It is about putting the work in the right place: into one workflow that actually completes, built on a foundation that can grow, with enough measurement to know what to build next.

The products that expand well are the ones whose first version was narrow and complete. The ones that struggle are the ones that were wide and leaky. Scope is not about ambition. It is about sequence.

Understand the job. Build the loop. Defer the rest on purpose. Then let real usage, not the original feature list, decide what comes next.