My MVP Development Process, Week by Week

My MVP development process has two parts: a short, paid discovery phase at a fixed price, where you and I cut your idea down to the smallest version that can prove it, and a build phase in weekly increments with a demo every week until real users have it in their hands. Below is the full plan week by week, what I need from you along the way, and where MVP timelines usually slip.

The example assumes a typical SaaS MVP: user accounts, two or three core features and subscription billing. Yours may run shorter or longer, but the order stays the same.

The short answer: the whole plan on one page

The rule behind the plan is simple: if a feature isn't needed for your first customer to solve their problem and pay for it, it doesn't belong in weeks 1-8. Eight build weeks isn't a magic number. A product with one core flow and no billing can be done in half the time, while several integrations, multiple user roles or a native mobile app push it the other way. If you're wondering what that does to the budget, I've broken down realistic MVP development costs separately.

The hard part is rarely the code. It's staying focused on the one problem the product exists to solve. I've written about that side of things in from idea to SaaS: choices and priorities.

Week 0: a paid discovery phase that locks scope and price

Most of what decides whether an MVP works gets decided before any code is written. That's why I start larger projects with a paid, fixed-price discovery phase. Some studios call it a scoping sprint or a product workshop. Whatever the name, this is where the big decisions happen:

1. We start with the goal. Who has the problem, how do they solve it today, and what has to be true after launch for you to call the MVP a success? A good goal is measurable, such as "ten paying customers" or "five companies using it every week".
2. We map the one core flow: the path from a new user signing up to solving their problem for the first time. Everything else is secondary.
3. Every idea goes into one of three piles: must have, can wait, won't do. The middle pile almost always ends up the biggest, and that's a healthy sign.
4. I put together the technical plan: data model, EU hosting, billing, integrations, and what can be bought off the shelf instead of built from scratch.
5. You get a written scope, sketches of the key screens, a weekly plan with milestones and a fixed price for the build.

The discovery output is yours. You've paid for it, so you can take the scope to another developer if you'd rather. That makes the decision to continue easier for both of us, because you're never committing to the full build on a vague brief.

For the wider picture of how working with me goes, MVP or not, see my freelance project process from first call to launch.

Weeks 1-2: foundations and a first clickable build

The first two weeks go into everything you can't see but the rest of the product stands on. By the end of week 2, you can sign up and log in on a staging site (a private test version of the product), and the sketches have turned into real screens.

1. I create a repository in your own GitHub or GitLab account, so the code is yours from the first line.
2. The data model is built from the scope. It's the most expensive part to change later, so it gets proper attention.
3. Sign-up, login and basic permissions go in.
4. The staging site goes live, and new code is deployed to it automatically, so you can always see the latest version.
5. The sketches become a simple, consistent design built from ready-made components. Nobody should spend weeks on a pixel-perfect design for a product no user has seen yet.

The first demo is rarely exciting: a login page and an empty dashboard. But it proves the foundation works, and it's your first chance to say "we've misunderstood this" while a fix takes minutes rather than days. The tools I rely on at this stage are listed in my freelance developer toolkit.

Weeks 3-5: core features, one at a time

Now I build the core flow we mapped in discovery. I finish one feature before starting the next, instead of keeping five half-done things in the air. Each week ends with a demo of what's new, and you get a couple of days to click around and send feedback.

This is also when new ideas show up. That's a good thing: it means you're seeing the product with fresh eyes. It's also the biggest threat to the timeline, which is why I work with one fixed rule:

I write automated tests for the parts where bugs do the most damage, usually billing, permissions and anything that calculates money. Not everything needs tests in an MVP, but anything that can cost you customers or revenue does.

Halfway through, we check in properly: are we on track, and do the priorities still hold? If something has turned out harder than expected, this is when you hear about it. Not in week 8.

The classic trap at this stage is trying to match every feature your competitors have. If you want to know the pitfalls in advance, I've collected 10 pitfalls in SaaS development.

Weeks 6-8: billing, real users and launch

Weeks 6-7: billing, admin and your first test users

1. Subscription billing goes in, usually with Stripe: plans, an optional free trial, receipts and VAT. If you sell to consumers in other EU countries, VAT is charged at the customer's local rate, and the EU VAT One Stop Shop lets you file a single return for those sales. Confirm the setup with your accountant before launch, not after.
2. You get an admin panel where you can see users, help them and fix data without having to call me.
3. Error tracking and logging go in, so I see problems before your users email you about them.
4. Simple analytics show how the product is used: how many people get through the core flow, and where they drop off.
5. A handful of test users get access. Not friends and family, but real people from your target market whom you've lined up in advance.

Feedback from those test users is the most valuable output of the whole project. Most of it turns into small fixes, but now and then it shows that a flow needs rethinking. Far better to find that out in week 7 than three months after launch.

Week 8: launch and handover

1. The production environment goes up with backups, monitoring and SSL, hosted in the EU, which keeps data residency questions simple when your customers are in Europe.
2. The privacy policy and cookie notice go live, and you put data processing agreements in place with the vendors that handle personal data for you. GDPR applies to EU companies and to companies elsewhere that offer services to people in the EU, so check with a lawyer if you're unsure what you need.
3. The first launch goes to a limited group, such as your waitlist or test users, rather than a big public launch on day one.
4. You get documentation, every login and a short walkthrough of how the product fits together.
5. We plan the next iterations based on what test users and analytics have shown.

After launch, the direction is your call: a maintenance retainer where I keep the product updated and keep building, or a handover to your own team.

What the process needs from you

An MVP is only as good as the decisions made along the way, and many of them only you can make. Plan for this every week of the project:

• A fixed weekly demo of under an hour, same time every week.
• A few hours to click through the staging site and answer questions within a day or two.
• One person who can say yes or no. A project with three decision-makers and nobody holding the final word moves slowly.
• Copy, pricing, terms and a logo. I can build the frame, but I can't write your business for you.
• Test users lined up before week 6, not once the product is finished.

In my view, the three most common reasons an MVP timeline slips are late feedback, ideas sneaking in without anything going out, and content arriving in the final week. None of them are about code, and all three are in your hands.

When this MVP development process is the wrong fit

The plan works best for a focused product with one clear audience and an owner who has time. It's a poor fit when:

• You haven't talked to potential customers yet. A developer is an expensive way to test an idea. Start with conversations, a landing page with a waitlist or a clickable prototype in a tool like Figma.
• The idea can be proven with existing tools. If you can test demand with a no-code tool, a spreadsheet and some manual work behind the scenes, do that first.
• The product needs a full team from day one, such as native iOS and Android apps, a web dashboard and several heavy integrations at once. One developer becomes a bottleneck, and an agency or small team is the better choice.
• Price is your only criterion. Scandinavian freelance rates tend to sit at the higher end in Europe, and an offshore team will usually quote a much lower hourly rate. If the lowest possible quote matters most, I'm not the right fit.
• You want a fixed price on a larger project without discovery. I don't offer that, because a fixed price on a vague brief ends in either a large risk premium or a dispute.

Next steps: getting ready for discovery

You don't need a full specification to get started. This is enough for a productive first conversation:

Once you have that, the next step is a conversation about your idea. You can see what I offer and how a typical engagement is set up on my page about SaaS and MVP development.

Frequently asked questions

Can an MVP be built in less than eight weeks?+

Yes, if the scope is smaller. A product with one core flow, no billing and no integrations can often be built in a few weeks. What makes an MVP fast is rarely a developer typing faster. It's fewer features and fewer decisions. If you want to launch sooner, cut scope during discovery instead of squeezing the timeline once the build has started.

What if we realize mid-build that the idea needs to change?+

We stop and reprioritize. Small adjustments go through the swap rule, so the timeline and price hold. If the change is bigger, such as a new target audience or a different core flow, we agree a new plan with time and price in writing before I build further. Finding that out in week 4 is good news compared with finding it out after launch.

Does this process work if I'm not based in Denmark?+

Yes. Discovery, weekly demos and feedback all happen over video calls and shared tools, so the process runs the same remotely. The practical limit is time zone overlap rather than location. I work on Central European Time, which gives full overlap with UK and EU business hours and a few hours of overlap with US East Coast mornings. Further west, plan for an early weekly demo on your side and most communication in writing.

Can I do some of the work myself to save money?+

Yes, and it's often a good idea. You can write the copy, recruit test users, draft the terms of service and handle support after launch. That saves hours and gives you a better feel for your own product. The code itself should have one clearly responsible person, so there's never any doubt about who built what.

What happens after the eight weeks?+

The first weeks after launch are about bug fixes, feedback and small improvements. After that, you choose between a maintenance retainer, where I keep the product updated and keep building at a pace that suits you, or a documented handover to your own team. Version 2 gets planned from real usage data, not from the original wish list.