MVP launch: what has to stand before your first paying customer
For: Founders and product leads
Updated: 2026-09
Five things have to stand before an MVP launch: a working payment path, a data model that permits later change, a route to delete accounts, a way to learn that something has broken, and basic legal documents. Everything else can wait.
The hardest question before an MVP launch is not what to build but what expressly not to. Every additional feature delays the moment you find out whether anyone pays at all — and that finding is the whole point of the exercise.
This list separates the two. It deliberately contains only items whose absence either makes launch impossible or becomes disproportionately expensive to correct later.
The checklist
- 01
Run the payment path end to end
Signup, subscription, failed payment, cancellation and refund each run through once for real. Failures here cost revenue and trust immediately.
Done when: All five cases were tested with a real payment, including a failed one.
- 02
Check the data model for changeability
The data model is the most expensive decision in the product. Check whether tenancy, user roles and billing units can be changed later without a rewrite.
Done when: For the three most likely model changes, the route to each is roughly described.
- 03
Implement account deletion
Users must be able to delete their account and data. It is legally required and hard to retrofit if the data model did not anticipate it.
Done when: An account deletion was performed and afterwards verified to leave no personal data behind.
- 04
Publish basic legal documents
Imprint, privacy policy and terms that describe the actual product. A borrowed template that does not match the product is worse than none.
Done when: The privacy policy names every third-party service actually in use.
- 05
Learn when something breaks
Error capture and an alert on outage. Without them you find out about problems through departing users — too late and with no detail.
Done when: A deliberately triggered error reached the alerting channel within minutes.
- 06
Test backup and restore
Not just configure it, restore from it once. In a young product, data loss is the one failure you effectively do not recover from.
Done when: A restore was carried out and the time it took is known.
- 07
Create a route for feedback
A visible way to reach you. Early users are the most valuable source of information a product will ever have; the route to them should not be obstructed.
Done when: A contact route is visible in the product and incoming messages demonstrably arrive.
Common mistakes
- —Launch slips for features nobody asked for. The purpose of the MVP — finding out whether anyone pays — slips with it.
- —The payment path is only tested in sandbox mode. Real payments behave differently in edge cases, particularly on failures and refunds.
- —Account deletion is deferred. Where the data model does not anticipate it, it becomes a larger rebuild.
- —The privacy policy is a template naming services that are not in use — or omitting the ones that are.
What this checklist does not cover
- —This list addresses readiness to launch, not product quality. It does not answer whether the product has a market.
- —Security appears here only at a foundational level. Sensitive data or regulated sectors require their own assessment.
- —Where the product carries AI functions, AI Act classification and transparency duties come on top and are not covered here.
- —Marketing, pricing and sales are deliberately out of scope.
Parent service: SaaS Product Development
Matching offers
Fixed-price MVP development
Fixed-price MVP development delivers a clearly scoped, working product at a price defined up front — on a modern, EU-hosted stack. Not an open-ended hours bucket, but a defined scope with a clear result.
SaaS launch package
The launch package takes a SaaS product from idea to market: a sound architecture, the decisive core features, billing, onboarding and deployment — guided, with a clear focus on the first paying customer. The result is not a prototype but a production-ready product that can generate revenue.
FAQ
What can safely wait?
Fine-grained roles and permissions, multiple languages, elaborate settings pages, a public API and most integrations. These can be added later without touching the foundation.
Does an MVP need a processing register already?
Once personal data is processed, yes. The effort is small at the start and grows with every month it is deferred.
How long should an MVP take?
Shorter than most plan. The decisive measure is not duration but how quickly the first real payment arrives, since that is what tests the assumption.
More checklists
Preparing a cloud migration: the questions before anything moves
Cloud migrations rarely fail on technology; they fail on preparation. Unknown dependencies, unresolved data classification, a cost model that only becomes visible after the move, and missing acceptance criteria against which success could be measured at all.
Replacing a legacy system: the groundwork that decides the outcome
Legacy replacements usually fail on three things: undocumented business logic nobody understands any more, data quality that only surfaces during migration, and a missing switch-off date, which leaves both systems running in parallel indefinitely.
Choosing a software partner: what to settle before you commission
Choosing a software partner is decided less by references than by four contractual points: who owns the result, who holds access to the systems, what a handover looks like, and what happens when the engagement ends.