How to build an MVP that still works in month nine

To build an MVP that still works in month nine, decide five things before the first screen: the data model, accounts and roles, payments, the hosting region and the release pipeline. Then cut the first release to one user, one job and one path, ship it through an automated pipeline, and write down every significant decision as you make it. Everything else, from admin dashboards to microservices, can wait.

The reason is month nine. By then you have real users, a second engineer and a roadmap, and every shortcut from month one sets the pace of month ten. This guide covers the decisions that are expensive to reverse, how to choose who builds, the GDPR basics, a four-week plan, scoping and handover.

#An MVP is not a prototype

Eric Ries defined the minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. Learning from real customers means real accounts, real data and, sooner or later, real money.

A prototype answers "could this work?" and is meant to be thrown away: a clickable design, a pitch-day demo, a script on a laptop. An MVP answers "will people use and pay for this?", and the people who answer leave their data in it. You cannot throw that away.

The trouble starts when a prototype is promoted to production without anyone deciding to promote it. Screens, business rules and database queries end up in the same files, login and payments are bolted on late, and deploys run from one person's machine. Nothing looks wrong in month two. By month nine, every feature costs more than it should.

Martin Fowler describes that extra cost as the interest on technical debt: the extra effort it takes to add new features because of deficiencies in internal quality. Some debt is a fair trade for speed. The aim of a first version is to take on debt deliberately, in places that are cheap to repay, and never in the foundations.

#Five decisions to make in week one

Week one is for decisions on paper, not screens. Each of these five is cheap to get right before the first line of product code and expensive to change once users depend on it.

1. The data model

Write down the core entities, how they relate and who owns each record. For most B2B products the decisive question is tenancy: does every customer organisation get its own space, and does every relevant table carry an organisation reference from day one? Retrofitting tenancy into a single-tenant schema touches every query you have written. Keep the schema in versioned migrations, never in manual changes to the live database.

2. Accounts, roles and permissions

Decide how people sign in, how users relate to organisations and which roles exist. Two or three roles are enough to start, but they should be checked in one place on the server, not scattered across screens as if-statements. Use an established authentication provider or library rather than writing password handling yourself, and leave room for single sign-on, because your first enterprise customer will ask for it.

3. Payments

Even if you charge nothing at launch, decide who pays (a person or an organisation), what they pay for (seats, usage or a flat plan) and where subscription state lives. Use a payment provider's hosted or embedded checkout so card data never touches your servers. Stripe, for example, explains that its low-risk integrations send payment details directly to Stripe and reduce your PCI DSS obligations.

4. The hosting region

Choose the region for your database, backups, logs and file storage, and check the region of every vendor that touches personal data. For a product sold in Germany, Austria and Switzerland, an EU region is the sensible default. It does not remove your GDPR duties, but it takes the international transfer question off most of the customer security questionnaires you will receive.

5. The release pipeline

From the first commit, every change goes through version control, automated tests and an automated deploy, first to staging and then to production. Nobody deploys from a laptop. A pipeline is dull to set up in week one and very hard to introduce in month nine, when the team has learned to ship by hand and every release is a held breath.

What to leave out on purpose

• Microservices. One well-structured application with clear internal layers (interface, business rules, data) is easier for a small team to change and to run.
• A custom admin panel. Use a database client or a simple internal tool until support work shows what admins actually need.
• Native apps on both platforms, unless the product needs device features. A responsive web app is often enough to learn from.
• More languages than your first market needs, though you should store text, dates and currencies in a way that allows them later.
• Home-grown infrastructure such as your own analytics stack, feature flag service or design system.
• Edge cases for customers you do not have yet.

#Which decisions are expensive to reverse

In his 2015 shareholder letter, Jeff Bezos split decisions into one-way and two-way doors: consequential, nearly irreversible ones that deserve care, and reversible ones that should be made quickly by a small group. Most startup decisions are two-way doors. The skill is spotting the few that are not, and not letting the reversible ones eat week one.

Look at what sits on the expensive side: data, identity, money and where they live. Those are the decisions to agree in writing in week one. The rest can be made by whoever is building, on the day, and changed when you know more.

#No-code, agency, freelancers or in-house

The right way to build depends less on budget than on two questions: who will own and understand the code in month nine, and how much of your product is the software itself. If you are a founder searching for "App entwickeln lassen", ask every provider those two questions before you compare offers.

Whichever you choose, the contract should say that code, repositories, cloud accounts and domains belong to your company from the start, and that documentation is a deliverable, not a favour.

#GDPR basics to get right from day one

The GDPR asks for data protection by design and by default (Article 25). For a first version that comes down to four practical things. This is general information: if you process health, financial or children's data, or anything unusual, talk to a data protection lawyer before you launch.

Hosting region and international transfers

The GDPR does not require data to stay in the EU. It requires a legal basis under Chapter V for any transfer outside the EEA, such as an adequacy decision or standard contractual clauses. For US vendors, the EU-US Data Privacy Framework covers transfers to companies certified under it. The General Court upheld the framework in September 2025, but an appeal (Case C-703/25 P) is pending at the Court of Justice. Keeping primary data in an EU region and knowing the transfer basis of every vendor limits your exposure whichever way it is decided.

A DPA with every processor

Every vendor that processes personal data on your behalf, from hosting to email delivery and error tracking, needs a data processing agreement under Article 28. In Germany it is the Auftragsverarbeitungsvertrag (AVV), and your B2B customers will ask you for one too. Keep a list of vendors with the data each receives, where it is stored and when you signed the DPA. That list is also the start of your records of processing under Article 30, whose exemption for organisations under 250 people does not apply once processing is more than occasional.

Consent, and when you do not need it

Many first versions collect consent they do not need and miss consent they do. Data you need to deliver the service under your contract does not need consent. Non-essential cookies and similar access to a user's device do: in Germany, § 25 TDDDG requires consent unless the access is strictly necessary for a service the user asked for. Where you rely on consent, record what was agreed and when, because Article 7 requires you to demonstrate it and makes withdrawal as easy as giving it.

Deletion that actually deletes

Article 17 gives people the right to erasure, and Article 19 requires you to tell the recipients you shared their data with. Design deletion in week one: which records are deleted, which are anonymised or retained because the law requires you to keep them (invoices, for example), how deletion reaches processors and backups, and who can trigger it. A soft-delete flag on the user table is not a deletion process.

#A week-by-week plan for the first four weeks

This plan assumes a narrowly scoped product and a small senior team. A larger scope takes longer, but the order stays the same: decisions, then the skeleton, then the first release.

From then on, release on a fixed rhythm, weekly is a good default, with one short review that decides what ships next. A steady rhythm matters more than the size of each release.

#How to scope the first release

Scope the first release around one user, one job and one path. Write it as a single sentence: "A clinic manager can invite her team and see this week's bookings in one place." Everything that does not serve that sentence goes on the cut list. Keep the list, because it becomes your roadmap.

1. Name the first user precisely: role, type of company and what they use today.
2. List the steps of the one job from first visit to outcome, and delete every step that is not essential.
3. Mark the steps that touch the expensive decisions (data, roles, money). Build those properly; the rest can be plain.
4. Choose one or two signals that tell you it worked, such as activation or a repeat action, and instrument only those.
5. Fix a date and cut scope to meet it, rather than moving the date.

A good first release feels small to the founder and complete to the first user. If your list of must-haves fills a page, you are describing version three.

#What a proper handover looks like

The test of a handover is simple: can an engineer who was not in the room deploy, debug and extend the product without calling the person who built it?

Decision records are the most underrated part. Michael Nygard's architecture decision record format captures each significant decision in a short file with its context, the decision, its status and its consequences. In month nine, when the second engineer asks why tenancy works the way it does, the answer is in the repository rather than in someone's memory.

Accounts are the other trap, and some take time. Apple requires an organisation to enrol as a legal entity with a D-U-N-S number, and Google Play will not create an organisation developer account without one; the free application can take up to 30 days. Start early, in the company's name, never in a freelancer's or an agency's.

#How we can help

Bespoke IT builds first versions for startups in Germany, Austria and Switzerland on the schedule described here: architecture in week one, a working product in week three and a handover your first engineering hire can run without us. If you are planning a first version, or already have one that feels like month nine, see how we work with startups.