The short answer
Before accepting an MVP development quote, agree what the first release must let a specific user complete and what the startup needs to learn from that use. Define the whole workflow, including failure and recovery, then name its exclusions, acceptance checks and operating owner. A prototype that tests an assumption and a live product that handles customer data are different purchases. Price and schedule should follow that written boundary; neither is a reliable promise when the work is still undefined.
What should a startup's first MVP actually deliver?
Start with the action a customer needs to complete, rather than the screens a founder wants to commission. For a startup preparing its first release, the useful question is: what must work so that a real user can try the service and the team can decide whether to keep investing in it? Record the evidence behind that choice and any assumptions that still need testing.
Keep product learning separate from delivery acceptance. A customer completing a task may tell you something about usability. A passing acceptance check tells you that the agreed behaviour works. Neither alone proves demand, willingness to pay or a viable business.
How do you turn that outcome into an agreed scope?
Write down the user's trigger, the action they take and the result they need. GOV.UK's guidance on writing user stories uses the actor, need and goal to describe a service requirement, with acceptance criteria stating the outcomes that show it has been met. This is a useful way to discuss a startup workflow too; it does not prescribe the product, its price or its delivery time.
- Name the first user group and the task it must complete, including where the task starts and ends.
- List the steps required for that task, including any manual work performed by your team.
- Identify the data, permissions and external systems those steps depend on.
- Define what happens when input is invalid, access is denied or a dependency is unavailable.
- Agree observable acceptance checks and who can approve them.
- Write an exclusion list and record which open decisions prevent a quote from being dependable.
- Make repository, hosting, domain and third-party account ownership explicit.
What does a bounded MVP workflow look like?
Consider a hypothetical supplier-onboarding product. The startup wants to learn whether an operations coordinator can collect and review a supplier's required documents through one workflow. This is an illustrative scope, not an ApexStack project, quote or delivery promise.
| Decision | Included in the example | Acceptance evidence to agree |
|---|---|---|
| Submit documents | A supplier opens an invitation, uploads permitted files and sees whether submission succeeded. | Invalid files are rejected with a useful message; an interrupted upload can be retried without creating a duplicate submission. |
| Review a submission | A coordinator sees the submitted documents and records an accepted or missing-information decision. | The correct coordinator can see the submission; another supplier cannot access it; the decision is saved and shown accurately. |
| Handle exceptions | The coordinator can request a correction and the supplier can replace the relevant document. | The revised submission is identifiable and the coordinator can complete the review without editing the database. |
| Learn from use | The startup records completion and drop-off at agreed steps, subject to the data and privacy requirements of the pilot. | The team can distinguish a completed task from an abandoned or failed attempt without treating either as proof of commercial demand. |
In this example, billing, native mobile apps, automated document scoring and ERP integration are deferred. Identity, access control, file handling and the minimum review tools remain real work to scope and price. Calling the workflow small does not make those responsibilities free or place it within a starting offer.
If your own idea still mixes the core task with later features, send ApexStack the workflow and open decisions through the contact action below. A bounded Product Blueprint can help establish what must be agreed before implementation is quoted.
Do you need a prototype or a live first release?
If the unresolved question is whether users understand a flow or whether a critical integration is feasible, commission a test of that assumption before committing to the whole product. GOV.UK's alpha guidance distinguishes prototypes used to test risky assumptions from production-quality code. Its government delivery process is not an MVP schedule for a startup, but the distinction between evidence work and a live service is useful.
If customers will rely on the release, state the operating requirements in the brief: access, data handling, deployment, recovery and support ownership. A convincing demo does not establish those properties. Ask which parts can be reused, what must change and what evidence is still missing before the prototype becomes a live product.
When is a price and delivery plan ready to accept?
- The proposal names the workflow, users, platforms and exclusions being priced.
- Assumptions about access, integrations, data and buyer decisions are visible, with an owner for each unresolved item.
- The delivery plan includes review, testing, deployment and handover, with the dependencies that can change its dates.
- Acceptance checks cover important behaviour and relevant failure paths, not only whether screens exist.
- The agreement states account and repository ownership, change approval and what support is included after release.
Use these as questions to resolve with the supplier, not as a universal contract template. A fixed price can describe a bounded engagement, but a fixed total does not resolve an unknown workflow. Ask for the assumptions behind both cost and schedule and agree how a change will be assessed before work expands.
What should happen after the first release?
Review what users actually did against the question the release was meant to answer. Separate a defect in the agreed workflow from a request for new behaviour. Then decide whether to repair, investigate further, expand the scope or stop. A longer feature list is not evidence that the original assumption was correct.
Keep the repository, deployment instructions, account access and open issues available to whoever will operate the product. Give that person a support boundary and a way to recover from failures. Agree later development separately unless the original engagement explicitly includes it.
Sources
- Writing user stories — GOV.UK Service Manual
- How the alpha phase works — GOV.UK Service Manual
Frequently asked questions
- What should an MVP development quote include?
- It should identify the first user and workflow, required platforms, data and integrations, explicit exclusions, assumptions, acceptance checks, deployment and account ownership. Keep unresolved questions visible and agree how changes affect cost and schedule.
- Can an MVP have a standard price or timeline?
- A provider can publish a starting offer for a bounded engagement, but that is not a quote or delivery promise for every startup idea. The workflow, access, dependencies, verification and operating requirements need to be agreed before its price and schedule can be assessed.
- Is a Product Blueprint a production-ready MVP?
- No. ApexStack's Product Blueprint starts from US$1,000 for bounded planning and de-risking. It can clarify the workflow, assumptions and next decision; production implementation is a separate scope.
- When should the scope expand?
- Expand only after the core workflow has produced evidence that the next feature, role or integration is necessary. A longer wish list is not evidence.
How can ApexStack help define your first MVP release?
Send ApexStack the intended user, the task they need to complete, your current evidence and any existing prototype. We can help separate the first-release scope from assumptions and later features. A Product Blueprint starts from US$1,000 for bounded planning and de-risking, not a production-ready MVP. If the workflow is ready for implementation, a Launch Sprint starts from US$2,500 for planning, UX direction, implementation, testing and deployment of one tightly scoped first release or core workflow. Authentication, billing, mobile apps, advanced AI, multiple integrations, data migration, compliance and extensive administration can increase the quote. The MVP Development service and pricing pages explain the supporting scope; use the contact action to discuss which starting point fits your brief.