Question 1

Is 8 weeks realistic?

Accepted Answer

Not for every feature — for the first value-delivering version, yes. Scope is defined together at the start of the sprint and protected weekly: what is in and what is out gets written down in week one and is not renegotiated later. The eight weeks are planned for the product spec, design, development and deployment; the 30-day stabilisation runs after that. A separate process handles scope creep.

Question 2

What is an MVP, and what is your definition of it?

Accepted Answer

An MVP is a product's first value-delivering version — not a trimmed feature list, but working software that does one job end to end. In this package the MVP runs in production, opens to real users, is wired to metrics and is stabilised for 30 days. It is the first production release in market, not a prototype or a demo. Monitoring and alerting are set up from day one; measurement is not bolted on later.

Question 3

Do we really own the source code?

Accepted Answer

Yes, with full ownership. The handover includes the repository, architecture documentation and dependency list; the operations runbook covers daily maintenance, the incident response procedure and a scaling guide. The internal team can extend, modify or decommission the infrastructure — the team finishes, the product stays. No external dependency is engineered in, and the TypeScript monolith default serves the same end: whoever inherits it manages a single codebase rather than a scattered set of services.

Question 4

What happens when the 30-day stabilisation ends?

Accepted Answer

The product transfers to the internal team. During stabilisation bugs are tracked in the live environment, minor fixes ship, the user feedback loop runs and the handover documentation is completed. After day thirty, maintenance runs with the internal team or the existing vendor; the operations runbook, architecture docs and metric wiring are prepared for exactly that handover. A continuing engagement is defined with its own scope and its own price — there is no mandatory maintenance contract.

Question 5

What is not included in the price?

Accepted Answer

Three items sit outside the package price: cloud infrastructure, the domain and third-party licences. The price covers the five scope items: product spec, UI/UX design, development, deployment and the 30-day stabilisation. Maintenance after day thirty is not on that list either and is discussed separately. Consumption-based costs are never folded into a fixed price, because they rise as usage rises.

Question 6

How does our existing software team take part in the MVP development?

Accepted Answer

Work runs in the same repository, under the same architecture decisions. A TypeScript monolith is the default and the rationale is written down; the internal team joins the decision through the architecture documentation from the start. Handover is a transfer of the knowledge needed to sustain the codebase rather than a file drop — the operations runbook, architecture docs and dependency list are written for that purpose. By the end of week eight the team should know its own product, not meet a new codebase.

Question 7

What do you need from us across the 8 weeks?

Accepted Answer

The heaviest input is at the front: the product spec and user stories are written together, and the priority order and scope boundary are drawn there. After that, design and development decisions need approval rather than production work, and the final check before deployment sits on the client side. During stabilisation, routing bug reports through one counterpart keeps the process fast. No full-time resource is required; a single counterpart for decisions is enough.

Question 8

What happens if the scope changes?

Accepted Answer

Scope is written together at the sprint start and protected weekly. When a new feature request arrives, two options are put on the table: drop an item from the current list, or recalculate duration and price. No third path is offered — a quietly added feature is what turns eight weeks into twelve, and it is the most common break point in the commitment. A fixed price only stands on a fixed scope, so every change goes on paper.

Question 9

Who is this package not for?

Accepted Answer

Not for work whose requirements are still undefined. The spec is the first step of the eight weeks, not a discovery phase; where what gets built is unclear, the right starting point is the Digital Transformation Audit. Migration projects replacing a large existing system also sit outside this scope. Where testing whether an idea holds is enough, the AI Pilot is the cheaper and faster route.

Question 10

Is the price fixed, or do extra line items appear along the way?

Accepted Answer

The price is fixed and tied to the scope list. No extra line item appears inside the eight weeks; if scope changes, repricing is put in writing. Cloud and licence costs vary with consumption, so they are excluded from the outset. The 30-day stabilisation is inside the price, and maintenance after that is defined as separate scope. The scope list is part of the agreement and is protected weekly across the eight weeks.

Question 11

Do we need new software or a process fix — how do we decide?

Accepted Answer

If the constraint sits in the gap between existing systems, new software may not be needed. MVP Build exists to build work that has no counterpart today — an OMS, order tracking or a customer portal; where a ready tool does the same job, writing software is the expensive route. Where it is unclear how the current flow stalls, the Digital Transformation Audit maps it in three weeks and produces the spec where one is needed. The two packages can run back to back.

MVP Build

What's included?

What you get.

Who it fits.

Frequently asked.