How to create a web app: a founder’s guide to building an MVP

If you are asking how to create a web app for a new product, the short answer is: build a minimum viable product. Pick one user journey, ship a web app that completes it end to end, and put it in front of real users within weeks, not months. Everything else — the second feature, the mobile app, the integrations — waits until you have watched people use the first version.

This guide is for founders who want a working product, not a pitch-deck prototype: what an MVP is and is not, how to build an MVP with a scope you can finish, what a first version must include, what MVP development costs, and what to plan for after launch.

What an MVP is — and what it is not

Before deciding how to build an MVP, be precise about what one is. A minimum viable product is the smallest version of your product that a real customer can use to get a real result. "Viable" is the word people forget. An MVP is not a clickable mock-up, not a landing page with a waiting list, and not a half-built platform with ten features that each work 60% of the way.

A minimum viable product web app is complete on one path and silent on all the others. A user signs up, does the one thing your product promises, and sees the outcome. If that path works, you have something to learn from.

How to build an MVP: cut scope to one user journey

Scope is where most first products fail, before a line of code is written. Write down the one journey a paying user takes from arriving at your app to getting value, and build only that:

1. Write the promise in one sentence. "A freelancer uploads receipts and gets a monthly expense report."
2. List every screen that sentence needs. Usually five to eight, not thirty.
3. For each screen, list what the user must be able to do. Everything marked "nice" goes to a parking list.
4. Ask of every remaining item: if this were missing, would the user still get the result? If yes, cut it.

Team roles, a native mobile app, social login and a public API usually fall out at this stage. They may matter later; none of them tell you whether the core idea works. The parking list is the roadmap for the months after launch.

How to create a web app: no-code or custom code?

The first fork in the road is whether to build with a no-code tool or commission a custom web app for startup use. Both are legitimate; the wrong choice is the expensive one.

Our rule of thumb: if the product is a form, a list and a dashboard, start with no-code. If the product is the logic — matching, pricing, workflows, anything with money changing hands — build a custom web app from the start; rebuilding a no-code MVP that took off is a common and avoidable project.

The stack matters less than the scope

The most common question we hear about how to build an MVP is which framework to use. For an MVP it is close to irrelevant. A typical stack today is a TypeScript front end (Next.js or similar), a managed Postgres database, a hosted auth provider, Stripe for payments and hosting in a European region: boring, well documented and cheap to run.

What matters more: the team can maintain the app or hand it over cleanly, the data sits in the EU and is exportable, hosting stays under a few hundred euros a month, and a second developer can read the code in a year.

What a first version must include

Cutting scope does not mean cutting the boring parts. A minimum viable product web app that real people use needs a floor of functionality that has nothing to do with your idea and everything to do with running a product:

• Authentication. Sign-up, login, password reset, account deletion. Use a hosted provider.
• The core flow. The one journey from the scope exercise, finished end to end, with empty states and error messages.
• Payments, if you charge. Stripe or a local equivalent, one plan, invoices a bookkeeper accepts.
• An admin view. A page where you see users, what they did, and fix a record without opening the database. Founders skip this and regret it in week one.
• Analytics and error tracking. The three or four events that show the journey completed, and an error tracker that emails you when something breaks.
• The legal minimum. Privacy policy, terms, a cookie notice that matches what you load. In the EU this is not optional.

An MVP does not need a design system, but the core flow must be clear on a phone. A short product design phase before the build — user flows, wireframes, one visual direction — pays for itself by removing screens that would otherwise be built and thrown away.

How to build an MVP in 6–8 weeks: a realistic timeline

With a fixed scope, a small team and a founder who answers questions the same day, a custom MVP fits in six to eight weeks.

The six to eight weeks below cover a full MVP: design, payments, an admin view and a pilot with real users. A smaller first version — one flow with no payments — can be shorter; at Pazl a starting delivery plan can be around four weeks once the scope and inputs are ready. How we run those weeks is described in MVP in four weeks: our development process.

Here is how we split it:

What stretches this is scope added mid-build and slow decisions: a founder who reviews weekly and answers within a day keeps the schedule. If your idea is a portal for existing customers rather than a new product, the same timeline applies; we describe that variant in our customer portal service, which also starts from €2,500.

MVP development cost: what drives the price

MVP development cost is mostly a function of scope and of who builds it. Rough market ranges in Europe in 2026, by our estimates: a freelancer typically €3,000–15,000, with wide variance in quality; a small studio typically €5,000–30,000 for a custom MVP with the six essentials above; a larger agency often €30,000–80,000.

At Pazl a web app or MVP starts from €2,500 at a fixed project price, with senior review and a six-month warranty; product design starts from €1,200. See our MVP development services for what the starting scope includes. The number rises with the screens, integrations and roles, not with the ideas in the deck.

What pushes the cost up, in order of impact: integrations with external systems (accounting, CRM, logistics), roles and permissions, real-time features, custom design instead of a component library, and a native mobile app alongside the web app. For a wider look, see our guide to how much it costs to build an app in 2026.

How to test an MVP with real users

Knowing how to build an MVP is half the job; testing it is the other half. An MVP only your team has used is not tested. Plan the pilot before the build ends:

• Recruit five to ten users from people you already talk to — a mailing list, a community, existing customers. Not friends.
• Give them one task in one sentence, the promise from the scope exercise, and nothing else.
• Watch three of them live on a screen-sharing call. Say nothing; where they hesitate is your next iteration.
• Measure the rest with your events: how many started, finished, and came back within a week.

If most users complete the journey and some come back, you have a product. If they complete it and never return, you have a feature. If they cannot complete it, fix the flow before adding anything.

Common mistakes when you create a web app

• Building the second journey before the first one works. Team accounts, notifications and a settings page feel essential. They are not, until one user has completed the core flow without help.
• No admin view. In week one someone will need a password reset or a refund. Without an admin page, every request becomes a database query.
• Choosing the stack before the scope. Framework debates take weeks and change nothing for the user. A boring, well-documented stack is the right default.
• Taking payments with a home-made card form. Use the provider's hosted or embedded checkout; it handles Strong Customer Authentication for you. More in how to accept payments online.
• Launching to friends. Friends are polite. Five strangers who have the problem you solve will tell you more in a week.
• Not owning the code and the accounts. Domain, hosting, repository, payment account — all in your company's name from the first day.

Checklist before you brief a developer

• The product promise fits in one sentence.
• The core user journey is written as a list of screens (usually five to eight).
• Everything else is on a parking list with a reason it can wait.
• We know whether users pay in version one, and how.
• We know who needs an admin view and what they must be able to fix.
• We have a budget range and a launch date we would accept.
• We have five to ten real users lined up for the pilot.
• We know who will support users after launch.

A developer who receives this list can give you a fixed price. One who receives a pitch deck can only guess.

After launch: support and iterations

Launch day is the start of the expensive part, not the end of the project. Plan for three things.

Support. Someone answers users within a day, and someone can fix a broken deploy on a Saturday. In the first months this is often the founder plus the studio on a small retainer; see product support after launch.

Iterations. Take the parking list, cross off what the pilot showed nobody needs, and ship one improvement every one or two weeks.

The next threshold. At some point the MVP stops being minimal: more roles, a client area, a mobile companion. That is the moment to revisit the architecture rather than bolt on. If your next step is a login area for existing clients, read what a customer portal is and when you need one. Our article on when a landing page is not enough describes the same transition one step earlier, and our project Numera Ledger shows a finance web app built this way.

Frequently asked questions

How long does it take to build an MVP?

With a fixed scope of one user journey, a custom web app takes six to eight weeks from workshop to launch. No-code versions can be ready in days but usually need rebuilding when the product grows.

How much does an MVP cost?

By our estimates, market prices in Europe range from about €3,000 with a freelancer to €80,000 and more with a large agency. At Pazl a web app or MVP starts from €2,500 at a fixed price, and product design from €1,200.

Should I build the MVP as a web app or a mobile app?

Almost always a web app first: it runs on every phone, needs no app-store review and can be changed the same day. A native app is worth it when users need push notifications, offline use or the camera in the core flow. Our mobile apps start from €4,750.

Can I start with no-code and move to custom later?

Yes, when the product is mainly forms and lists. The move is a rebuild, not a migration: the data comes across, the logic is written again. If the value is in the logic or you take payments from day one, starting custom is usually cheaper over twelve months.

Do I need a technical co-founder to create a web app?

Not for the first version. You need someone who owns the product decisions — usually you — and a developer or studio who owns the build. A technical co-founder becomes important once the product works and you are hiring an in-house team.

What is the difference between a web app and a website?

A website mostly shows information: pages, articles, a contact form. A web app lets users do something and keeps their data: sign in, create records, pay, see their history. Most MVPs are web apps, even when they look like a simple site.