SaaS MVP: build it with AI or hire? A worked example

A founder — let’s call her Claire — wants to launch a small online product for consulting firms: tracking their clients’ requests on a single board. She has put no-code tools together before but has never written code. She has seen demos where an AI agent builds an app in an afternoon. Should she build it herself, buy an existing tool, or hand the project to a developer? This case follows the diagnostic’s method, step by step.

Illustrative example: Claire and her project are fictional. No real client is described here, and the recommendation only holds under the assumptions written below.

With three answers: an orientation, not a verdict

First answers: a SaaS, at the first-version-to-launch stage (MVP), of “normal” importance to her business. With so little information, an honest answer stays provisional. The diagnostic (in French) says:

« Orientation préliminaire : approche hybride à évaluer. Les données traitées, les droits d’accès et votre capacité à maintenir le produit restent à préciser. »

In English: “Preliminary orientation: a hybrid approach to evaluate. The data processed, the access rights and your capacity to maintain the product remain to be specified.” Why not decide right away? Because what you do not know is not low risk. A SaaS handling medical records, or isolating several customer companies with their roles, is not decided like a SaaS storing contacts. The first three answers say nothing about data, access rights or who will maintain the product — exactly the points a demo does not show.

The explicit assumptions

Claire completes the diagnostic. The recommendation below only holds under these assumptions: a non-technical solo founder; a narrow B2B workflow, one core task for one type of customer; ordinary contact and business data, no sensitive or regulated records; standard billing through a payment provider; a limited pilot with a few known customers; no hard real-time requirement; no bespoke financial decision engine.

She has also looked for an existing product: the tools she tried do not cover the specific workflow her customers ask for. She can give it 5 to 15 hours a week, with a budget of CHF 2’000 to 10’000 over twelve months, and she plans to look after the product after launch without yet knowing how.

The recommendation: hybrid

« Construire le parcours principal avec l’IA, acheter les composants standards et faire vérifier les accès, paiements et procédures de reprise avant un lancement payant. »

In English: “Build the core workflow with AI, buy the standard components, and have access, payments and recovery procedures checked before a paid launch.” In practice, Claire builds with a coding agent what makes her product valuable: the core workflow, the screens, the lists. She writes neither her own sign-in nor her own payment handling: she buys them from specialised services — an authentication provider, a payment provider, an email service — and configures them. Before the first real payment, an experienced person checks three specific things: that each account only sees its own data, that access really follows the confirmed payment, and that a backup restores.

This is not “have a developer do everything”. The review is bounded, dated, and covers the points where a mistake is expensive yet invisible in a demo.

The eight stages

The matrix splits the project into stages. Each has a decision, a main risk, the evidence that lets you move on, and the costs to evaluate. It is shown below as published in French; an English summary follows.

• Validate — test one paid problem, including manual delivery. Risk: building unwanted features. Exit: target user, core task, success criteria and demand evidence written down.
• Scope — keep one workflow and list exclusions. Risk: scope creep and integration overload. Exit: written scope and acceptance examples.
• Choose components — compare reuse or buying with custom work. Risk: lock-in, poor fit, an unnecessary stack. Exit: ownership, export and hosting compatibility checked.
• Build a vertical slice — one end-to-end user outcome. Risk: a polished demo with a broken workflow. Exit: successful and failing flows demonstrated.
• Verify identity and access — test ownership and tenant boundaries. Risk: reading or changing another user’s data. Exit: cross-user denial tests pass.
• Connect billing — server-verified payment and access. Risk: unpaid access, or a paying customer locked out. Exit: success, failure, replay and recovery tests pass.
• Pilot safely — a small, controlled rollout. Risk: unseen bugs and no recovery owner. Exit: monitoring, a tested restore, rollback and a named owner.
• Operate and decide — measure use and maintain. Risk: support burden and accumulating defects. Exit: the user outcome is achieved and a maintenance plan accepted.

Ticking a row is not technical proof: the proof is the observed test — two accounts, a declined payment, a successful restore — written down with its date.

What would change the recommendation

The recommendation depends on the assumptions. Changing a single one is sometimes enough to reverse it:

• Sensitive records — health, personal finances, identity documents: a specialist review becomes mandatory before any real data, and the sensitive parts are handed over rather than built alone. Or the scope shrinks so these data are not stored at all.
• Permissions across several customer companies, each with its roles: isolation between customers becomes the riskiest part of the product; a specialist designs it rather than only reviewing it.
• Heavier losses from downtime: monitoring, a tested restore and someone able to step in come before launch, which pushes towards handing operations over.
• Stronger technical capability — Claire codes, or a technical person joins: building it herself becomes reasonable, with a review targeted at payments.
• An adequate existing product: buying and configuring it becomes the recommendation, and building no longer makes sense.
• An impractical budget: it does not make the risk disappear. Shrink the scope, deliver the service by hand first, or postpone the paid launch — do not skip checking access and payments.

The costs to look at

Cost is not just a developer’s invoice. Separate the cash that leaves — tool subscriptions, hosting, review, payment fees, a contingency reserve — from the total economic cost, which adds the founder’s time. A project that is “free” because she builds it alone can still mean hundreds of hours. Conversely, a few hours of review at the right moment often cost less than an incident with a customer’s data.

Run the exercise on your project

The free diagnostic (in French) asks the same questions in plain language, with “I don’t know” always available. It gives an orientation from three answers, then a reasoned recommendation, what remains to be specified and your next actions — no email, no payment. To understand the limits of AI task by task, see the limits of AI for building a web product.