AI MVP development: how do you scope the core journeys?

01AI MVP development starts with journeys that prove someone will pay

An AI MVP has one job: find out whether customers will pay for the outcome. That sounds obvious, yet most MVP scopes are built around features, not around that question. This is part of our larger guide, What is forward deployed engineering?.

We start by writing down the shortest path from a stranger to a paying, satisfied customer. For most B2B products it has four journeys:

• Sign up and set up. An account, the right roles and enough configuration to start.
• Pay. A price the buyer understands and a billing flow that works without a sales call.
• Get the core value. The one AI-powered outcome the product exists for.
• Come back. A way to see past results, so the value is not a one-time trick.

If a feature does not serve one of these journeys, it is not in the MVP. It may be valuable. It may be what wins the second year of renewals. It still waits.

The AI part deserves the same discipline. Google's People + AI Guidebook makes the point that teams should start from the user problem and ask whether AI actually improves the experience, because simpler rules are often easier to build, explain and maintain. Google's Rules of Machine Learning say the same from the engineering side: do not be afraid to launch without machine learning where a simple rule does the job. In an MVP, keep AI where it creates the core value and use plain logic everywhere else.

02Rank every feature with one test

We run every requested feature through the same question: can a customer sign up, pay and get value without it? The answer decides the phase.

The table is not a rule for every product. It is a way to make the argument about each feature short and visible. When a stakeholder wants something moved up, the question becomes concrete: which of the four journeys fails without it?

03Write the proposal in versions

The single most useful scoping habit we have is writing the proposal in more than one version. It turns a vague argument about ambition into a decision with dates and effort attached.

1. 01

   Version A, the sellable core.

   Only the four journeys, with the AI outcome done properly.

2. 02

   Version B, the core plus one expensive extra.

   Usually customization, because it touches the data model, the admin screens and testing.

3. 03

   State the difference plainly.

   What Version B adds, how much later it lands and what it puts at risk.

4. 04

   Put the expensive item last in the build order.

   If the decision is to include it, build everything else first so the core can ship even if the extra slips.

5. 05

   Agree what success means for the MVP.

   Paying customers, repeat use, or a specific number of accounts set up without help. Decide before the build starts.

This also gives the buyer an honest way to cut scope without feeling that quality was cut. They are choosing between two complete products, one smaller than the other.

04Decide the foundations that are expensive to change later

An MVP can be small in features but should not be careless in foundations. A few decisions are cheap at the start and very expensive to reverse.

• Roles and data structure first. Decide who the users are, what each role can see and whether end users need accounts at all, before anyone designs screens. Screens can then be built in parallel.
• One system of record. Avoid splitting accounts, billing and core data across two platforms because each was quick to set up. Sync between them becomes its own product, full of failed payments and mismatched accounts.
• Sensitive data rules. If personal or regulated data is involved, decide now what never goes to an outside model and strip it before any call.
• Tenant separation. If the plan is to sell to many organizations, separate their data from the first build.

For established products adding AI, the same logic applies to the existing platform: change only what the new capability needs. We cover that in adding AI agents to an existing SaaS product without rebuilding it.

05Protect the scope once the build starts

Scope rarely grows in one big request. It grows in chat threads, one small idea at a time, each reasonable on its own. Shifting scope costs more time than building.

Two habits keep it under control. First, replace open-ended chat with regular meetings and written requirements. Ideas still arrive, but they land in a document where they can be ranked against the four journeys instead of slipping straight into the sprint. Second, simplify pricing. Complex pricing creates complex billing logic, more admin screens and more edge cases to test. A single, clear model, such as a price per user or per provider, keeps the billing journey small and gives every customer the same product.

06What we see in production

For a clinician-founder in healthcare, we designed and built the first version of an AI patient intake product for the founder's own pain clinic: an adaptive questionnaire covering pain, history, medications and treatments tried, with an AI-written summary for the physician and voice answers. It ran in three practices, and the founder used it on about 100 of their own patients. It was still a proof of concept, with hard-coded questions and no multi-tenant database.

The second phase had to turn it into a product clinics could buy without the founder, against a fixed launch target. The proposal went through several versions as features were cut to reach the market sooner. We wrote it in two versions, with and without template customization, and put customization last so everything else could ship first.

We simplified pricing to a per-provider model so every clinic gets the same product. We defined roles and the data structure before screens: super admin, clinic admin and provider, and patients without accounts. We kept one database on Azure for everything instead of syncing with a separate sign-up tool the founder had started, which would have split data across two platforms. We stripped patient identifiers before any data reached the model. And we replaced chat back-and-forth with regular meetings and written requirements.

The result was a commercial product where clinics register, pay per provider, add providers and customize their intake templates, with the working intake flow kept intact underneath.

Frequently asked questions