MVP in 6 Weeks from idea to a first version in front of real users

A minimum viable product built to a fixed scope in six weeks: one job, done properly, deployed where real users can reach it.

Four things exist at the end:

• a working first version, running in your own cloud accounts
• the agreed scope, and the list of what was deliberately deferred
• the repositories, the pipeline and the infrastructure, yours throughout
• a costed plan for the next phase

A first version, not a feature-complete launch, and the difference is the point.

Scope sets the price, and both are settled in writing before week one. None of it is billed by the hour, and nothing is left open to discover later.

The variable is what the first version has to do: a booking flow and a regulated financial workflow are not the same six weeks. We price it once we know which of those you are building.

Work after the six weeks is quoted separately, under whichever of our three engagement models fits: time and materials, fixed price, or team extension.

When you can name the one thing the product has to do for its first users, and one person can settle arguments about it inside a day.

You do not need designs or a specification. What stalls a six-week build is not a missing wireframe; it is an idea that is still three ideas, or a decision that needs a committee.

If that is where you are, product design and development is the week before this one.

We say so on the scoping call, before there is a contract.

Three things genuinely do not fit:

• deep integrations with third parties who move at their own speed
• anything gated behind a certification or an external approval
• a product whose core is still being argued about internally

Then we say which engagement does fit, and the answer is more often a smaller first version than a longer timeline. Nobody gains from agreeing to six weeks and renegotiating it in week four.

A decision-maker who can answer product questions the same day, access to your cloud accounts, and whoever will support the product in the room while we harden it.

Across the fixed-scope set that is between four and ten hours of your team's time in total, depending on the offer, and a build sits at the top of it.

The expensive part is never the hours; it is a question that waits a week for its answer.

You do, from day one rather than at handover: you own the code after MVP development because you owned it while it was written.

Repositories, the deployment pipeline and the cloud accounts are yours throughout, so there is no migration at the end and nothing to negotiate if you take the next phase elsewhere.

Our own access is least-privilege, agreed with your technical contact and read-only wherever the work allows, and we work inside your own cloud environment where your customers, insurers or shippers require it.

Whatever the first users tell you should, and you decide it with evidence rather than a hunch.

Week six ends in one of three places:

• re-order the deferred list against what actually happened, and fund the next phase
• stop, which is a legitimate answer and cheap to reach at six weeks
• take the code and the plan elsewhere

A post-launch warranty period is standard on our fixed-scope work, with the length agreed in the contract, so the people who shipped it fix what the first users find.

One of them, usually, and we decide which in week one.

Integration is where a fixed timebox is most often lost, because the schedule stops being ours the moment it depends on a third party's sandbox, their support queue or their credentials process.

So we scope one integration into the six weeks where the first version genuinely needs it, name the rest in the deferred list, and cost them in the next-phase plan, where the timeline is not load-bearing.