What is included in an MVP: what $9K buys

Founders ask me the same question on almost every first call: what is included in an MVP, and what do I give up to launch in weeks instead of months? It is a fair question. “Minimum” means different things to different people, and a fixed price only works when everyone agrees on the same list before anyone writes code. This post is the honest answer for our Launch package for MVPs. I will cover what is in it, what we leave out on purpose, how the list gets agreed, and what happens once you are live.

What is included in an MVP

Our Launch package starts at $9K and takes 4–6 weeks. The promise is short: an MVP that makes money from launch. Three things make that possible.

Core user flows, designed and built. These are the few paths a user takes to get value from your product and pay you for it. Sign up, do the main thing, pay. We design these flows and screens with you first, then build them. If a flow is not needed for a user to get value or to pay, it probably belongs in a later phase.

Payments. Your product can charge customers from the day it goes live. I will come back to why this matters so much, because it is the part founders most often try to drop.

An admin panel. Someone has to run the business on day one, and the admin panel is where they do it. Without one, every small task for a customer turns into a request to a developer.

Around those three, every package comes with the same working setup. You get design, QA on every feature before it reaches your demo, and a CI pipeline with automated builds and checks from the first week. You also get a weekly demo of working software on a call, full IP transfer and a 3-month warranty after launch. The source code lives in your own repository from day one.

Here is the checklist of what you walk away with at handover:

• Source code in your repository, with full IP transfer
• Editable design files for every screen and flow
• A CI pipeline your next team can keep using
• The live product, and for mobile, the app store release
• Handover docs: how it is built, how to run it, how to change it
• A 3-month warranty on what we built

You also talk directly to the people who build it. The engineers on your first call are the ones who build your product.

What we cut, and why

An MVP is defined as much by what it leaves out as by what it holds. The Launch package leaves out four things that the bigger packages include. The table shows where each one lands.

Analytics and reporting. Dashboards on sales and usage are useful once you have sales and usage. In the first weeks after launch, your payments and your admin panel already show you who is paying. If you need numbers on sales and usage from day one, that is a sign you are past the idea stage, and the Product package is the better fit.

Team roles and permissions. Launch assumes a small team running the product, often the founder. If several people will run the business from the admin panel, each needing to see different things, you need roles. That is also a Product feature.

Integrations and load testing. Connecting to an ERP, a CRM or a logistics provider, and testing for heavy traffic, belong to our Scale package. Most MVPs do not need them yet. If downtime on launch day would cost you customers, we should talk about Scale instead.

Beyond the package lines, there is a second kind of cut. These are features that are good ideas but do not help you learn whether people will pay. Reviews, in-app chat, loyalty points, a second language and a full marketing site are the usual ones. When a founder lists them, I ask one question: does a user need this to get value or to pay? If not, I suggest we keep it for the next phase.

Cutting is not a judgment on the idea. A short list ships sooner, costs less, and gets you real feedback while you still have the budget to act on it. The next phase can then be planned around what your first users actually did.

How the feature list is agreed in week 1

Everything above only works if the list is written down and agreed. Here is how that happens.

It starts before you pay anything. Discovery is free: a 30-minute call with an engineer, then a written feature list and a fixed quote. There is no commitment at that stage. If you need an NDA, we sign it before the first call.

The price on our site is a starting point. A project is only agreed once you approve the written feature list and the fixed quote. Prices are in USD, and there is no hourly billing.

Week 1 is kickoff and design. We go through the feature list with you, then design the main flows and screens together. From that point, the feature list agreed in week one is the contract. Your fixed price covers those features and main user flows.

Scope will change. It always does, and the rules for it are simple:

• Swaps are free. Trade a feature for one of similar size, any time before we start building it.
• New features get a quote first. You get a fixed price before any work starts. Add it now, or keep it for a later phase.
• Small tweaks are always included. Copy, color and small layout changes never count as a change request.

Payment follows the same logic. You pay in three milestones of 30%, 40% and 30%, each tied to something you can see working. The first is due after you approve the feature list, the second at the mid-project demo, and the last at launch, when the code is handed over.

Why payments are in from day one

This is the part I feel most strongly about. An MVP that can’t take money doesn’t tell you whether the idea works.

Here is my reasoning. Sign-ups are cheap. Compliments are cheap. People will tell you your idea is great and then never come back. A waitlist tells you that the pitch is interesting. It does not tell you that the product is worth paying for.

A payment does. When a stranger enters their card details for the thing you built, you have learned something no survey can teach you. When they don’t, you have learned something too, and you learned it in weeks rather than after a year of building.

So I push back when a founder wants to launch free first and add payments later. “Later” often means after you have trained your first users to expect it free. It also means your first real test of the business happens months after launch, when the budget is smaller.

Having payments in from the start also changes the build. Pricing, plans and what a customer gets for their money have to be decided in week one, not left vague. That conversation alone tends to sharpen the whole product.

That is why payments are part of the Launch package rather than an add-on. It is the core of what an MVP is for.

What happens after launch

The last week is launch and handover. We go live, hand over the code and the docs, and your 3-month warranty starts.

For those 3 months, we fix bugs in what we built, at no cost. The warranty covers our work. It does not turn into a maintenance plan, because we don’t run maintenance retainers after the warranty ends.

That is deliberate. Before handover we document the code and leave the CI pipeline in place, so your own team or any vendor can take over. You are not locked in to us to keep the product running.

Some costs were never ours to bill. App store developer fees, hosting and infrastructure, and third-party licenses and paid APIs are billed to you directly. That way you stay the owner of every account your product runs on.

When the first version has earned its keep and you know what to build next, there are three common paths:

1. Grow into Product. Add analytics and team roles once more than one person runs the business.
2. Plan a custom phase. Each phase gets its own scope and fixed price, so you never commit to more than you can see.
3. Add an AI feature. Search, summaries or an assistant inside your app are scoped and quoted on their own, then built into the same weekly demos.

If you have a clear core idea and a few must-have flows, and you want to charge customers from day one, Launch is likely the right start. If you are unsure, a free 30-minute discovery call is the fastest way to find out.

Questions people ask

Written by

Ricky Tran

CEO, JUST.engineer. Runs your first call and stays on your project until it launches.