MVP in 4 Weeks: What You Can Realistically Build (and How Long It Takes)

You're building a product and you hear two extreme answers: some promise a working app "in two weeks," others quote half a year before you even see the first screen. For most projects the truth sits in between — a sensible MVP ships in 4–8 weeks. Below I lay out what you can realistically fit into that window, what you deliberately leave for later, and how a sprint like this runs week by week. No magic promised — this is a description of what we actually ship, not a marketing line.

What realistically goes into an MVP in 4–8 weeks

An MVP isn't a "stripped-down app." It's the smallest version of the product that closes one value loop: a user shows up, does the thing they came for, and you get data or money out of it. On a Next.js + TypeScript + PostgreSQL stack, in 4–8 weeks you can realistically fit:

• Authentication and accounts. Sign-up, login, password reset, sessions. A proven mechanism, not something reinvented from scratch.
• Payments. Stripe or a local processor: one-off payment or subscription, webhooks, basic order statuses. Money actually comes in.
• An admin panel. A place where you or your team manage content, users and orders — without poking around in the database by hand.
• A custom backend and database. Your own API and data model in PostgreSQL, shaped to your business logic, not to a template that starts chafing a month in.
• 1–2 AI integrations. Content generation, classification, summaries or chat over your data. One, at most two — in a critical path, with a fallback and a cost cap, not a demo that falls over on the first unusual input.
• A basic user panel. Profile, history, settings — what a user needs in order to come back the next day.

That's a complete set you can launch a product on and start selling or testing with real people. Everything else is expansion, not foundation. The order isn't random either: we stand up the skeleton first (auth, database, the core flow), and only bolt on payments, AI and integrations once there's something to connect them to. By the midpoint of the sprint you're clicking through a working product, not reviewing static mockups. If you'd like that scope written up as a concrete service, we've laid it out on the MVP build page.

What you won't get — and why that's good

If something goes in, something has to come out. At the start, we deliberately leave overboard:

• Elaborate roles and permissions. One, at most two user types are enough to validate. A "who-sees-and-can-change-what" matrix is weeks of work, not a hypothesis to test.
• Multi-language. One language, one market. You add i18n when you know a second market actually makes sense — not just in case.
• Advanced reports and dashboards. Early on, a handful of key numbers matter — not configurable charts with export to five formats.
• A native mobile app. A responsive web app (or a PWA) covers most MVP needs. A separate iOS and Android build is a second project, not an "while we're at it."
• Edge cases. What happens on the 47th step of an unusual scenario? For now, nothing — because nobody has even taken step one yet.

This isn't cutting corners. An MVP exists to test one hypothesis: do people want this, and will they pay. Every feature that doesn't help answer that question is a burned week and a delayed moment of truth. You build v2 on data from users — not on your own guesses from before launch. That's why trimming scope up front isn't a quality compromise; it's the cheapest way to learn something faster.

Week by week

An MVP sprint isn't a black box you pour money into and wait. We work in weekly cycles, and the code lands in your Git repository from day one — not at the end, "once the invoice is paid." Here's how a typical six-week run looks:

Every week you get a live demo and a short review: we show what works, you say what to fix or why to reprioritize. That rhythm does two things. First, there's no surprise at the end — we correct course mid-flight, not after the fact, when reworking something costs ten times more. Second, you keep your hand on the scope: if in week three it turns out you actually need a different feature than planned, we move the priority instead of dutifully delivering a plan that's already gone stale. A narrow scope closes in four weeks, a more complex one stretches to eight — depending on the number of integrations and how tangled the logic is — but the pattern stays the same: a week of work, a demo, a decision.

Why "six months for an MVP" is a red flag

If someone quotes half a year for an MVP, one of three things is usually going on. Either it isn't an MVP but a full product with v2 already crammed into scope. Or the scope was never locked and "six months" is a buffer for chaos quietly shifted onto you. Or the team is building just in case — microservices, scaling for a million users and five integrations nobody needs yet.

For you as a founder, every one of those is expensive. Half a year is half a year of burned runway before you even learn whether the idea lands. An MVP exists to answer that question quickly and cheaply — and if the answer is "no," you want to hear it after six weeks, not after six months and hundreds of thousands spent. The longer the first cycle, the later you learn anything about the market. And early on, the speed at which you learn is the only real edge you have.

What it costs

Concretely: an MVP starts at €4,200 net with us and ships in 4–8 weeks. We set the price as fixed price after scoping — first we lock the scope, then we give you a fixed figure and deadline, not an "around this to that" range with surcharges appearing mid-build.

If the idea isn't pinned down yet — you have a direction but a pile of product decisions ahead — we start with a Discovery Sprint from €700. You leave it with a defined scope, an architecture and a real MVP quote. It's the cheapest moment to catch that half the dream features aren't needed to validate. You'll find the full breakdown on the pricing page, and if you want to see what this kind of scope looks like on a real project, we wrote up building a production system from zero in eight weeks.

What comes after the MVP

An MVP is a start, not an end. After launch you have three paths:

1. v2 on data. You gather feedback and metrics, we go back into a sprint and build what people actually use — roles, reports, more integrations. Now it makes sense, because you know what to grow.
2. A retainer. If the product is alive and needs ongoing care, we move into a Ship & Support model from €580/month — fixes, small changes, monitoring and growth in small steps.
3. A clean handover. Have your own team or developer? We hand over the code, documentation and access. The code is yours from day one, so handover is a formality, not a negotiation over vendor lock-in.

None of these paths is imposed up front. You pick the one that fits where the product and your team are.

Start with something concrete

Have an idea and want to know what you can realistically fit into the first 4–8 weeks? Book a scoping call — you'll leave with a defined scope, a fixed price and a deadline, not another "it depends." Take a look at the pricing and tell us what you're building. We'll map out the rest together, in numbers.