Defined product builds
Deliver a focused product or capability people can actually use.
Build a first product, add an important capability to an existing one, or take a promising prototype towards production. Agree the outcome, delivery boundary and acceptance evidence before implementation begins.
Use a defined build when the outcome has a clear delivery boundary
A defined product build can create a first useful product or deliver an important new capability for software already in use. The outcome, dependencies, responsibilities and acceptance evidence are agreed before implementation, while detailed decisions continue as working software reveals what matters.
An MVP, or minimum viable product, is one form of defined build: the smallest product release that lets an intended user achieve a useful outcome and gives the business evidence for its next decision. “Viable” means usable in the agreed operating context, not a polished demonstration with the difficult steps left out.
If the business has a continuing backlog rather than one bounded phase, consider ongoing product engineering. If the main uncertainty is whether people understand a proposed experience, use the MVP vs prototype comparison first.
Agree one complete outcome
Choose one initial audience and describe the journey from entry to a confirmed result. Name the essential actions, data, permissions and operating responsibilities. Put later features in a separate list so they do not quietly become launch requirements.
- User outcome: what can someone finish without the team pretending an unfinished step works?
- Business outcome: what evidence would justify continuing, changing or stopping?
- Operating boundary: who handles exceptions, corrections and support?
- Acceptance: what must the team demonstrate before inviting users?
A narrow release can include an agreed manual back-office step. That step needs an owner, capacity and honest expectations; it must not conceal a missing capability that the trial is supposed to test.
Already have an AI-built prototype?
A prototype created with Cursor, Claude, Codex or another coding tool can be useful evidence. Before inviting real users or depending on it operationally, LCR can review what exists, identify the production gaps and agree the smallest responsible next release.
The review may cover architecture, authentication, tenancy, data handling, integrations, tests, observability, deployment, recovery and maintainability. Some prototypes can be strengthened incrementally; others reveal decisions that are safer to revisit before more work accumulates. No production-readiness outcome is assumed before the implementation is inspected.
Build and review in useful slices
Agree the discovery questions, first-release boundary and acceptance evidence before estimating delivery. Review working slices of the journey as they become available, including failure states rather than just the easiest demonstration.
A typical scope discussion covers the user experience, application logic, approved integrations, access controls, testing, release process and handover. Confirm which of these LCR will deliver and what the client or another supplier owns. External account approvals, content, specialist review and access to existing systems remain explicit dependencies.
For a web application, Laravel may be a suitable foundation. A device-led experience may instead need the mobile app development route. Choose the architecture for the task, not because a framework promises a universal shortcut.
A smaller product, not a smaller promise
Hypothetical example: a service business wants customers to request a visit, receive a reviewed response and follow its status. The first release could support one service type, one review team and a clear status history.
Automatic dispatch, a marketplace, recurring billing and a native mobile app could wait unless the first customer outcome depends on them. A team member might review scheduling manually, provided the customer understands when a response will arrive and the business can support the trial.
Success is not the number of screens delivered. Observe whether customers complete requests, whether staff can handle exceptions and whether the promised response reaches the customer. That evidence shapes the next investment.
Estimate the actual release, including AI assistance
There is no responsible universal price or timeline for an undefined MVP. Work with the delivery team to estimate the agreed core journey, technical dependencies and acceptance work. Read the cost planning guide and delivery planning guide for the questions that make an estimate useful.
Tools such as Cursor, Claude and Codex can assist coding and test preparation. Agree their use with the team and verify the resulting work. They do not remove the need for product decisions, permissions, reliable integrations or user acceptance. Avoid budgeting around a promised percentage saving before the workflow has been assessed.
Plan the scope and check the release
Use the SaaS MVP budget guide for customer accounts, billing and service operation. Decide which features belong in the first release, then gather the evidence in the MVP development checklist.
For a broader business application, start with the custom software buyer guide and compare custom, packaged and hybrid options before committing to a build.
Launch to learn, with someone responsible
Agree who can access the release, how users get help, what is measured and what happens when a material defect appears. Confirm ownership of the repository, hosting accounts, deployment process and support responsibilities before handover.
The GOV.UK beta guidance illustrates testing a working service with users and improving it from evidence. It is a delivery reference, not a requirement that a commercial MVP follow government phases.
Bring a sample user request, the current process, the desired outcome and any systems the product must use. Learn how LCR carries engineering responsibility, then use those inputs to start a focused discussion.
Sources and review date
Sources reviewed on 6 September 2026 and linked beside the guidance they support. Examples are hypothetical. This page provides planning guidance, not a project quote, fixed delivery promise or guarantee of commercial results. Confirm scope and responsibilities with the delivery team.
Questions
Frequently asked questions
Can an MVP include manual work?
Yes, where it is deliberate, supportable and does not invalidate the learning goal. Define the owner and user expectations rather than pretending that manual work is automated.
Do you quote a fixed MVP price here?
No. Agree the core journey, dependencies and acceptance criteria with the delivery team before estimating the release.
Must we build a mobile app first?
No. Choose the channel that supports the initial user task. A web product may be enough; device-specific needs can change that decision.
Plan a defined build
Bring the product problem and the outcome you need.
Discuss the core journey, the systems it depends on and the evidence needed before launch.