How we develop an MVP: our process step by step

Building a minimum viable product sounds straightforward until a couple of months in, the scope has tripled, and the original deadline is a distant memory. Most MVPs do not fail because of bad ideas; they fail because the process around them is loose. No fixed scope, no regular checkpoints, no clear definition of "done". The timeline slips, the budget follows, and by the time something ships, the market has moved.

This article walks through how MVP development actually works: what the steps are, what realistically fits into a first version, what the price is made of, and how we run it at Pazl.

Why the first version should be short (and when it should not)

A short timeline is not a magic number. It is the shortest window that allows for a real development cycle with regular demos, a proper handoff, and enough functionality to test a core assumption with real users. We show the first working version within a few weeks, and the exact timeline goes into the contract after the brief.

Too short a window gives you a prototype, not an MVP. Too long a window gives you a small product with all its risks. A short first version forces scope discipline: only what tests the idea gets in.

That format works when:

• the core user flow is one to three screens or steps;
• there are one or two integrations (Kaspi, 1C or a bank's payment page, for example);
• the design is functional rather than showroom-polished;
• the team has done this type of build before.

It does not work when the client wants a marketplace, a multi-role platform, or real-time features that require significant infrastructure. Those are legitimate products; they just need a different schedule, and we split them into stages.

The process, step by step

Step 1. Scope on paper and a technical foundation

The first step is not about writing code. It is about making sure everyone agrees on exactly what will be built, and what will not.

This means a written technical specification (not a slide deck), a defined user flow, and a decision on the tech stack. Any ambiguity here costs double later. A client describes "a booking system" and the developer hears something completely different. A specification with wireframes closes that gap.

By the end of the step:

• the scope is locked in writing and attached to the contract;
• the tech stack is chosen;
• the development environment and server are set up;
• the first demo is scheduled.

Step 2. The core flow

This is the heaviest part of the build. The goal is to have the primary user flow working: not beautifully, but functionally. A user can complete the main action the product is designed for.

For a B2B ordering tool, that means a user can log in, create an order, and see it in their account. For a loyalty app, it means a user can register, earn points, and check their balance. The feature set is narrow by design.

Step 3. Integrations and edge cases

This step connects the core to the outside world: payments through a bank or Kaspi, phone-number sign-in, exchange with 1C, a CRM or the ESF e-invoicing system, third-party APIs. It also handles the edge cases the second step left open: error states, empty states, input validation.

Testing runs in parallel with development rather than after it. Leaving tests for the end is the surest way to miss a deadline.

Step 4. Polish, testing and handoff

The last step before launch is not for adding features. It is for making what exists reliable: performance and security checks, fixing bugs surfaced in testing, and preparing the handoff documentation.

At the end, the client has a working product they can put in front of real users, along with the source code, deployment instructions and all credentials.

Step 5. Launch and warranty

After acceptance, the product goes to users. From that moment a six-month warranty applies: if something in the scope we built breaks because of us, we fix it at no charge. New features after launch are estimated separately and agreed before work starts, and after the warranty the product can stay with us for support and maintenance or move to your own team.

What realistically fits into a first version

The scope column matters as much as the timeline. A short MVP means a specific scope; it does not mean a compressed version of a product that would normally take six months.

What does an MVP cost: how the market prices it

Pricing varies a lot depending on who you work with.

A few things worth knowing about these formats:

Hourly vs. fixed price. Hourly billing means the client carries the risk of scope creep: if the project takes longer, the invoice grows. A fixed price transfers that risk to the studio, which is why fixed-price studios scope more carefully upfront. A full comparison: fixed price vs. hourly billing.

What "MVP" means to the vendor. Some agencies use "MVP" to mean a stripped-down version of a full product, priced accordingly. Others mean a true first-test build. Ask for a written scope before comparing quotes.

Post-launch costs. Hosting, the domain, and developer accounts in the App Store and Google Play are paid by the client directly, in the client's company name. A decent studio does not bury them in the project fee or mark them up.

How we run an MVP at Pazl

We work on a fixed-price model. The price and timeline go into the contract after the technical specification is approved, not before. This protects both sides: the client knows exactly what they are paying, and we know exactly what we are building.

Our process:

1. Discovery call. We understand the product idea, the core assumption being tested, and any constraints: existing code, required integrations, target platform.
2. Proposal. A written scope, a price and a timeline.
3. Contract and specification. A contract with your LLP or sole proprietorship, priced in tenge. The specification is an appendix to the contract; anything outside it gets a separate agreement with a price before work starts.
4. Development in short iterations. After each iteration you see a working version and give feedback before the next one starts.
5. Handoff. Source code, deployment documentation, credentials, and a six-month warranty on everything we built.

The warranty matters. If something breaks because of our code in the six months after launch, we fix it at no charge. Servers, domain renewals and paid third-party services are always the client's direct expense; we do not mark those up.

A web app or MVP with us starts from 1 000 000 ₸, a mobile app from 1 000 000 ₸. More complex builds (multi-role platforms, mobile apps with their own backend, AI integrations) are priced after we have reviewed the requirements, not before. See MVP pricing for the starting scope and mobile app development for the mobile option.

An example from our work. For an events agency we built an AI agent that handles everyday client messaging: it understands text, voice, photos and video, creates tasks in Trello and calls in a manager when a person is needed. That kind of build, a working AI agent connected to a task system, fits a short cycle well when the scope is defined tightly.

We have also built an ERP for a logistics company (fleet, documents, finance and operations in one system) and a loyalty app for a retail chain connected to its tills and 1C. The common thread: a defined scope, regular demos, and a handoff the client can actually use.

The most common reasons short MVPs fail

Scope added mid-iteration. Every new feature request that arrives during development either pushes the deadline or displaces something already planned. The specification exists to make this visible: "yes, we can add that, here is what it replaces or here is the cost to add it."

No decision-maker available. Demos only work if someone with authority to approve or redirect shows up. If feedback has to travel through three layers of internal approval, the project stalls.

Third-party API surprises. Integrating with a bank, a marketplace or an accounting system often takes longer than expected, especially if the documentation is poor or the sandbox behaves differently from production. We scope integrations conservatively and flag this risk early.

Design decisions deferred too long. Deciding on navigation or the user flow halfway through means rebuilding work that is already done. Design decisions happen in the first step.

Treating the MVP as the final product. An MVP is a test, not a grand launch. The goal is to learn something about the market, not to build everything the product will eventually need. Teams that treat the first version as the final release tend to over-scope and under-deliver.

Data and the law: what to consider in Kazakhstan

If your MVP collects personal data (a name, a phone number, an email), the personal data law applies from the first user, not after some threshold. The data is stored in a database located in Kazakhstan (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). You need user consent that can be proven, a processing policy, and a way to withdraw consent. We cover this in detail in our personal data guide.

If some of the data goes to foreign services (email, analytics, AI), that is a cross-border transfer and it has to be stated in the consent. This is not a reason to delay building, but it is a reason to put the right data handling into the specification from the start rather than retrofitting it later.

For payments, use a bank's hosted payment page or Kaspi: card data never passes through your server, which is the right architecture for an MVP. If you sell to companies, check with your accountant in advance which documents buyers need: an invoice, an acceptance certificate, an electronic invoice through the ESF system.

How to evaluate a studio before you sign

A few questions worth asking any vendor before committing to a fixed-price MVP:

• Can I see the specification from a past project? A studio that cannot show you what a specification looks like probably does not write them.
• Who owns the code at the end? The answer should be: you do. The source code is handed over to you, not hosted on the vendor's infrastructure indefinitely.
• What happens if something breaks after launch? A warranty period with defined terms is standard. "We'll take a look" is not.
• How are out-of-scope requests handled? In writing, with a price and timeline impact. Verbal agreements about "small additions" are how projects go over budget.
• Do you have examples of similar builds? Not case studies with vague outcomes, but actual products you can open and try.

Wrapping up

A short MVP is achievable, but it requires discipline on both sides. The studio needs to scope tightly, demo regularly, and deliver what was agreed. The client needs to make decisions quickly, stay available, and resist the urge to expand scope mid-build.

The fixed-price model exists to align those incentives. When the price is set and the scope is written, both sides have a reason to stay focused. For how to prepare the product itself, read how to create a web app as an MVP.