MVP Development

An MVP is not a cheaper version of your product. It is the smallest working product built to answer one question, and if that question is not written down, what comes out is not an MVP but an unfinished product. An unfinished product teaches you nothing. That is why we do not start with a feature list but with a single sentence: which assumption, if it turns out to be wrong, makes everything else pointless? Once that sentence exists, two lists follow, one of things to build and one of things not to build. The real work of this service is defending the second list. Writing the code is the most predictable part of the job.

How we define an MVP

An MVP is not a prototype. A prototype answers an internal question, "does this technically work", and it lives under test conditions. An MVP goes outside, touches real users, and works fully within a narrow scope: people sign up, pay, and see the error screen. There is also the v1, a first release with the feature list closed up front and no hypothesis attached. A v1 is legitimate work, but its timeline, price and risk differ from an MVP, so we tell you in the first meeting which of the two your request is. There is work we decline as well: projects with no definition of success, requests shaped as "let us ship first and look later", and measurements nobody will use to make a decision. For the history of the idea, the different MVP types and where the practice stands today, see our MVP development guide.

How we build an MVP

The six headings below cover every decision made in an MVP project. The first three describe how the work is set up: cutting scope, designing the validation, and the delivery rhythm. The next two cover what happens after launch: how a demo differs from real usage, and what is done with technical debt in production. The sixth is the opposite of the others, the cases where an MVP is the wrong answer and we say so before any contract is signed.

Cutting scope: deciding what will not be built

Cutting scope is not deleting features. It is tying every feature to one question: which assumption does this test? A feature with no answer is not thrown away, it goes on the post-MVP list handed to you at the end of the project. The clearest example is BiTalih, where teams needed to produce social media content and what they did not get was a design tool. Fixed templates were defined and users were given permission to update only the variable fields such as place, time and amount. That was a decision, not a gap: because design consistency held, content production dropped from hours to minutes.

Designing validation: which question, which measurement

Three lines are written before any code. The assumption to be tested, the metric that will measure it, and the threshold that counts as a yes. If the threshold is not set in advance, any outcome can be narrated favourably afterwards, so the metric stays binary: it either cleared the bar or it did not. The same document records who the measurement runs on and how those users are reached, because an MVP with no traffic produces guesses rather than measurements. Event tracking ships with the first release, since instrumentation added later cannot recover the data from the early weeks.

Constant contact and pre-prod visibility

We stay in constant contact with the client throughout the project; progress is shared on most days it is possible to share it. Early on, we set up a staging environment that closely mirrors the live system but is not yet open to real users; we call it pre-prod, and changes made there can usually be watched in near real time. The evidence of progress is not a screenshot but working software at a real address, and what makes that possible is a deployment pipeline set up from the very start. Lextum AI, Biletico, Anneekspres and World Summer Schools all had CI/CD automation running on Jenkins. Releasing has to stop being an event before that transparency can hold.

Investor demo versus real user testing

An investor demo is built around a ten-minute narrative and follows the happy path. Real user testing needs the unhappy paths: empty states, invalid input, an abandoned payment, a weak connection, a small phone. Both come out of the same product, but the order matters: we build the real flow first, and the demo becomes a scripted route through it. When we took over Biletico, the platform had a foundation but the payment flow had been left half finished. When payment does not work, every other measurement loses its meaning, because the user leaves before reaching the purchase step. That is why payment took first priority, and payment, search, profile and ticket management were all made functional before the platform went live.

Moving from MVP to production and the technical debt decision

Not every piece of technical debt gets repaid; what gets decided is the order. At the end of an MVP we usually share a written assessment separating what must change before growth from what can live as it is for a long time; that split follows the project and is not divided into the same fixed categories every time. The point is that the decision can be made commercially rather than technically. Lextum AI is the concrete example of what belongs on the production side: the system is built on a microservice architecture with asynchronous processing over RabbitMQ, and role-based access and a full audit trail are part of that same structure. High-traffic enterprise use is what makes those items non-negotiable. When the problem is load rather than demand, the work leaves MVP territory and moves to backend scaling.

When an MVP is the wrong answer

There are four situations in which we do not recommend an MVP. First, questions that are already answered: if a process has been running inside the company for years, the job is not to test demand but to build a system with a written scope. Second, work whose result nobody will act on: if no one is authorised to change direction when the measurement lands, it is only an expense. Third, flows where the smallest working version is not actually small: payment, identity verification and regulated steps cannot be left half done. Fourth, cases where the product exists already and the problem is visibility or resilience rather than demand, where a new MVP is not the answer.

The project delivery package

When an MVP finishes, you hold four things. The code, with its full history, in a repository on your own account rather than as a compressed folder, so who changed what and when stays readable. The running infrastructure: server, database and deployment pipeline sit on accounts opened in your name, which keeps the handover from becoming a separate migration project. The data and the measurement: the database schema, the event records, and the report that answers the question you started with. And the handover document: how the system comes up locally, how it is deployed, which decisions were deliberate, and what has accumulated on the post-MVP list. All four are delivered whether or not you continue the project with us.

How budget and scope are protected

What protects a budget is not fixing the number but keeping scope in writing. Duration is estimated upfront, and because progress stays visible through the pre-prod environment the date does not turn into a surprise; scope is the thing that flexes. Every new request that arrives during the project is priced with one question: if this comes in, which item goes out, or does it open a separate line item? The decision is yours and the exchange is recorded in writing, so that at the end of the project there is no argument about where and why the scope grew. You keep the right to stop at any point, and because everything produced by then is already yours, stopping is a decision rather than a loss. Third-party costs, meaning payment commissions, cloud bills and app store fees, are listed separately from the start and billed to your own accounts rather than hidden inside a development fee.

Our measurement scope

What we measure is completion of the core flow: could the user perform the action the product exists for, in how many steps, where did they drop off, did they come back. In a product that takes money the payment step is tracked separately, because the gap between intent and payment is the most expensive information available. There are things we deliberately do not measure: page views, sign-up counts on their own, time-based engagement averages, satisfaction scores on small samples. A product can fail while all of those rise, which is why they cannot drive a decision. Our own speed is not a success metric either; how many items we closed is internal tracking data. The measurement window and the sample size needed vary by project; if the data is not yet mature enough to support a conclusion, we say so rather than reporting a result as more certain than it is.

Our technology selection criteria

An MVP is a bad place to learn a new technology, so the choice is made from a narrow set: tools we already run in production and that somebody else can maintain after handover. When transaction complexity, role structures and enterprise integrations dominate, the backend is .NET, as in Lextum AI, World Summer Schools and Welldone. When the weight of the work sits in the data model and the admin screens, Python and Django get there faster, and the Anneekspres marketplace was built that way. React and Next.js carry the interface, and we reach for Flutter or React Native when a single codebase has to reach field users on both iOS and Android. Three criteria drive the choice: who maintains it after handover, whether people who know that technology can be hired, and whether hosting stays on your own accounts.

What this looks like in practice

The work listed below is either live or completed, and each project has its own page in the success stories section.

• Lextum AI: document generation, contract review, simultaneous editing and versioning for legal teams. Taken to production with a microservice architecture, RabbitMQ, role-based access and an audit trail.
• Biletico: a platform with a foundation in place but almost nothing working was taken over; payment, search, profile and ticket management were made functional and a canvas-based seating plan was added.
• World Summer Schools: hundreds of summer school programmes gathered into one searchable catalogue, with content entry accelerated through an OpenAI integration and role-based authorisation in place.
• Anneekspres: a marketplace for mother and child products built from scratch: seller panel, payment and order flow, infrastructure on PostgreSQL and RabbitMQ.
• BiTalih: a content production platform built on fixed templates and variable fields; with role-based access, content production went from hours to minutes.
• Welldone: a Flutter mobile app, a React management panel and .NET services for industrial laundry operations, with QR-code packaging in the field and real-time reporting for managers.
• Terazzi: work on an existing platform covering design and customer panel improvements, search engine visibility and backend performance.