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 cut scope to something you can finish, what a first version must include, what drives the cost, 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 two thirds 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 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. For example: "An outsourced accountant uploads a client's documents and gets a monthly summary."
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 to have" 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 becomes the roadmap for the months after launch.

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. Both are legitimate; the wrong choice is simply the one that costs more later.

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, money changing hands), build a custom web app from the start. Rebuilding a no-code MVP that took off is a common and entirely predictable project.

The stack matters less than the scope

The most common question we hear about building an MVP is which framework to use. For a first version it is close to irrelevant. A typical stack today is a TypeScript front end (Next.js or similar), a managed PostgreSQL database, a proven authentication library and hosting: boring, well documented and cheap to run.

What matters more: the team can maintain the app or hand it over cleanly, the data is exportable, and a second developer can read the code in a year. In Kazakhstan there is one more condition: if the app stores personal data of citizens, the database must be located in the country (Law of the Republic of Kazakhstan No. 94-V of 21 May 2013 On Personal Data and Their Protection, Article 12(2), text on adilet.zan.kz). Choosing a server in Kazakhstan from day one is easier than moving after launch. If some of the data goes to a foreign service (email, analytics, AI), that is a cross-border transfer, and the user's consent has to say so.

What a first version must include

Cutting scope does not mean cutting the boring parts. A 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:

• Sign-in. Sign-up, login, access recovery, account deletion. A phone number with a one-time code works well.
• The core flow. The one journey from the scope exercise, finished end to end, with empty states and clear error messages.
• Payments, if you charge. A bank's hosted payment page or an invoice through Kaspi, one plan, and documents your bookkeeper will accept.
• An admin view. A page where you see users and 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 tells you when something breaks.
• The legal minimum. A personal data policy, a separate consent checkbox, terms of use and, if you sell online, a public offer.

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 the work on an MVP runs: stages

With a fixed scope, a small team and a founder who answers questions the same day, the first working version can be shown within a few weeks. The exact timeline depends on the scope and goes into the contract after the brief. How we run these stages is described in how we develop an MVP.

What stretches the timeline is scope added mid-build and slow decisions: a founder who reviews interim versions and answers within a day keeps the schedule. If your idea is an area for existing customers rather than a new product, the same stages apply; see what a customer portal is and when you need one.

What drives the cost of an MVP

MVP development cost is mostly a function of scope and of who builds it. A freelancer is usually the cheapest, with wide variance in quality and timing, and design, testing and support are often not included. A small studio charges more but answers for design, testing and launch as a team. A large agency costs the most: the price carries managers, approvals and overhead.

At Pazl a web app or MVP starts from 1 000 000 ₸. The price is fixed in the contract before work starts and covers the design of the agreed screens, development, testing, deployment and a six-month warranty. See MVP pricing for what the starting scope includes. The number rises with screens, integrations and roles, not with the ideas in the deck.

What pushes the cost up, in order of impact: integrations with external systems (1C, Kaspi, the ESF e-invoicing system, a CRM, logistics), roles and permissions, real-time features, custom design instead of a component library, and a native mobile app alongside the web app. The less of this in version one, the faster and cheaper you learn what matters.

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, a WhatsApp or Telegram group. 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 an access 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.
• A home-made card form. Use the bank's hosted payment page or widget: card data never touches your server, and the bank covers the security requirements. 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, the payment agreement with the bank: all in your company's name, LLP or sole proprietor, 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: by card, through Kaspi, by invoice.
• 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 release on a Saturday. In the first months this is often the founder plus the studio on a small monthly agreement; 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, a link to 1C. That is the moment to revisit the architecture rather than bolt things on.