ServiceSoftware development
From idea to MVP: build the smallest thing that proves it, then grow it
Our MVP and prototype service turns a business idea into something people can use, in two steps: first a clickable prototype to check that the idea makes sense to the people it is for, then a minimum viable product (MVP) — the smallest version that real users can sign up to, pay for or rely on. It is built on the same foundations as a full product (dev, uat and prod, previews, automated builds), so a successful MVP grows instead of being rewritten.
What we do for you
- A scoping session that turns the idea into one sentence, one target user and one measurable question
- A clickable prototype on a preview address you can share with prospects or partners
- An MVP with the few features that answer the question — and a written list of what is deliberately left out
- Payments when the question is "will people pay" (hosted checkout such as Stripe), email when it is "will they come back"
- Basic analytics on the actions that matter, so the answer is measured, not guessed
- dev, uat and prod from day one, so the MVP can become the product
- A decision meeting: continue, change or stop, based on what users actually did
Who it is for
- Fits: founders and business owners with an idea for a new product, platform or internal tool
- Fits: companies that want to test a new offer with real customers before funding a full build
- Fits: teams that need a working demo for investors, partners or a pilot client
- Does not fit: projects where every feature is "essential" from day one — that is a full build, see custom software
- Does not fit: native mobile apps; our MVPs are responsive web apps that can be installed on a phone
Prototype, MVP, product: three different things
Saying in advance which stage you are building avoids the two classic failures: a prototype sold as a product, and a product built for months before anyone touches it.
| Stage | What it is | What it proves | What it is not |
|---|---|---|---|
| Prototype | Clickable screens, realistic content, little or no back end | That the idea is understood and wanted by the people it is for | Something people can rely on |
| MVP | The smallest working version: real accounts, real data, often real payments | That people use it, come back or pay | Complete, polished or scaled |
| Product | The MVP grown with what users asked for | That it can run a business | Finished — it keeps evolving |
How we run it
- One question. "Will training organisations pay for this tool?", "Will customers book online instead of calling?" The MVP exists to answer it.
- Scope on one page. Features in, features out, and the measure of success.
- Prototype. Screens on a preview address. You show them to five or ten real people and we adjust.
- MVP build. In small slices, each visible on its own preview, with uat for your tests before release to prod.
- Launch to real users. Payments and analytics in place from the start so the answer is in the data.
- Decide. We review usage with you and agree what comes next — or that it should stop.
Products we have built and run
Products of the kind an MVP leads to, which we built and run today: a management SaaS for training organisations in France (Next.js + Postgres, now live), document generators that produce letters and regulatory documents in the buyer's name and sell them online, an e-learning platform selling SCORM courses with certificates, directories such as one listing more than 4,900 sworn translators, and a quote assistant for a safari company in Southern Africa built with separate dev, uat and prod environments from the start. We do not publish their revenue; we can walk you through how they were scoped.
Built small, but not built badly
An MVP can skip features; it should not skip foundations. Ours get the same pipeline as larger projects: builds on GitHub Actions, where each run executes in a fresh virtual machine; protected branches that require a review and passing checks before merging; Docker Compose so the MVP runs the same way on every environment. For payments we use hosted checkouts — Stripe describes Checkout as a payment page "either embedded on your site or via a redirect to a Stripe-hosted page" — rather than building payment forms ourselves. This is what lets a successful MVP grow without a rewrite.
What you own, and what we need
- You own the code (in a repository you control), the domain, the payment account and the user data
- We need one decision-maker, available weekly
- Access to five to ten real people from your target users for prototype feedback
- Your honest answer, at the end, on whether the data says continue
Questions we get
What is the difference between a prototype and an MVP?
A prototype is clickable screens to check that the idea is understood and wanted. An MVP is the smallest working version that real users can sign up to, use or pay for.
Will the MVP have to be rewritten later?
Not if it is built on proper foundations. Ours use the same environments, builds and hosting as a full product, so it can grow.
Can the MVP take payments?
Yes. When the question is whether people will pay, we add a hosted checkout such as Stripe so you get a real answer.
How do we decide whether to continue?
With the measure agreed at the start (sign-ups, bookings, payments, return visits) and a review meeting where we look at what users actually did.
Can you build it as a mobile app?
We build responsive web apps that can be installed on a phone. We have not shipped native iOS or Android apps yet.
Sources
- GitHub Docs — Understanding GitHub Actions (checked 2026-10-06)
- GitHub Docs — About protected branches (checked 2026-10-06)
- Docker Docs — Compose application model (checked 2026-10-06)
- Stripe Docs — Build a payments page (Checkout) (checked 2026-10-06)