- Name the uncertain assumption
- Choose the smallest valid test
- Define one complete user journey
- Price delivery and operation separately
- Review evidence before expanding
| Phase described by the source | Main purpose | Pricing implication for a private brief |
|---|---|---|
| Discovery | Understand users, problem and constraints | Separate investigation from a software-build commitment |
| Before proceeding beyond discovery | Decide whether further investigation is worthwhile | Define a decision point rather than assuming all phases are purchased |
What does MVP mean in the project you are pricing?
Write down the deliverable instead of relying on the abbreviation. A prototype can show interactions using sample data. A supervised pilot lets a limited group attempt a real task with known support. A public release must handle the actual conditions and responsibilities of serving its intended audience. Each can be useful, but they are not interchangeable quotes.
A fictional supplier creating an artwork-approval tool might first need to learn whether customers understand version status. A prototype could help answer that question. If the question is whether the workflow reduces confusion during real production handoffs, the team needs a different test with appropriate controls, permissions, and outcome definitions.
Do not confuse an MVP with a deliberately broken version of the final product. Limit feature breadth while preserving the reliability needed for the chosen test. Removing a reporting dashboard may be sensible; omitting the distinction between approved and outdated artwork could invalidate the entire learning exercise.
Which assumptions should be investigated before development?
Identify the uncertainty most likely to change the decision. It could concern demand, comprehension, workflow fit, technical feasibility, or operating capacity. Avoid using a large software build to answer a question that a smaller investigation could address more directly.
The UK Government Service Manual describes discovery as understanding the problem, users, and constraints before committing to a service. Its public-service process is not a mandatory method for a private startup, but the distinction is useful: learning what should be built is separate work from producing the software.
For the artwork example, interview the staff and customers involved in the current approval process. Learn what they consider a final version, who can approve it, and what happens after a change. Record the evidence and limitations. A request from one enthusiastic contact does not establish market demand or justify a revenue forecast.
What makes a user journey complete enough to estimate?
Describe the starting condition, action, confirmation, and exception. For a limited artwork pilot, a customer receives access, views a specific version, chooses the permitted response, and sees confirmation of what was recorded. Staff can identify the same version and decision. That is more informative than a list containing login, dashboard, and approval button.
Include the failures that would make the test misleading. What if the link is expired, the wrong person opens it, the customer submits twice, or a new version arrives while the old one is open? The team does not need every future feature, but it needs a defensible response to the situations included in the pilot.
Use acceptance criteria that an owner can review. For example, an approval record must identify the version and authorized user, and a later upload must not silently change that record. These are illustrative requirements for the fictional workflow, not a claim that a particular system already implements them.
Which cost drivers matter more than the number of screens?
User roles, data relationships, external integrations, reliability requirements, and platform coverage can dominate the work. Two screens may require complex permissions and synchronization, while a longer informational journey may have simpler behavior. Ask the provider to explain the difficult parts of the estimate.
An integration needs more than an available endpoint. Confirm access, documentation, test data, limits, error behavior, and responsibility for changes. If the product depends on an external system that has not been assessed, keep that uncertainty visible. A guessed integration allowance is not evidence that the connection will work.
Content and data preparation also require ownership. The supplier may need sample files, approved wording, onboarding instructions, and a way to identify existing customers. Decide who provides and checks those inputs. Developers should not invent production rules or migrate confidential data without an agreed process.
How should prototype, pilot, and public-release costs be separated?
Ask for separate outputs and decision points. A prototype estimate can include interaction design, sample content, and a research plan. A pilot estimate adds the functions and safeguards needed for the agreed users. A public-release estimate may add broader operations, support, distribution, and resilience requirements.
The Government Service Manual's alpha guidance discusses testing risky assumptions through prototypes before deciding how to proceed. Apply that principle with a clearly scoped private-business test rather than copying a government timetable or treating its phase names as a price benchmark.
For the fictional supplier, a prototype could be discarded after the workflow is tested. Reusing it as production software might require substantial rebuilding. Ask which materials are intended to survive into the next phase and which are temporary. Cheap prototype code is not automatically a head start on a maintainable public product.
Does AI-assisted development make an MVP cheaper?
AI tools may assist with implementation, but a quote still needs design decisions, review, testing, deployment, and ownership. GitHub's responsible-use guidance describes limitations and the need to review agent output. The presence of an AI coding tool does not establish the quality or total cost of the delivered product.
Ask how generated work is checked against the product requirements and how dependencies, permissions, and failures are reviewed. A quick demonstration can hide insecure access or unreliable state changes. The buyer needs evidence of behavior, not a claim about how many lines of code were generated.
In the artwork pilot, independent checks should establish that one customer cannot access another customer's files and that approval refers to the correct version. Faster creation of the interface does not remove these questions. Compare the complete delivery process rather than assuming a universal percentage saving from AI.
What operating costs begin during a pilot?
List the services required to run the pilot: hosting, storage, authentication, monitoring, messaging, and any platform accounts that apply. Verify current vendor pricing and usage assumptions for the actual architecture. Do not treat a testing allowance as a permanent production cost estimate.
Include the human work of onboarding participants, answering questions, investigating failures, and recording what the test teaches. A manually supported pilot can be a deliberate choice, but that support has a capacity limit. Describe it accurately so participants do not believe an automated capability exists when staff perform the step.
Plan how the pilot ends. Decide whether data is retained, exported, or removed through the approved process, and tell participants what happens to access. If the business continues, identify who maintains the product. An MVP budget that ends at deployment omits the period when the team is supposed to learn from use.
How do you compare proposals without buying different products?
Give each provider the same problem statement, audience, journey, acceptance criteria, known integrations, and readiness level. Ask for included work, exclusions, assumptions, delivery responsibilities, and a process for unresolved questions. A proposal for a prototype should not compete as if it were a public production release.
Request an estimate breakdown that makes uncertainty visible. Discovery, design, implementation, testing, launch preparation, and initial support can be separate lines. An exact-looking total may be less useful than a bounded proposal that explains which unknown must be resolved before the next commitment.
For the artwork example, ask every provider whether permissions, version history, repeated submissions, staff handoff, and pilot closure are covered. Record the answers in the same decision sheet. This creates a practical comparison without inventing a market rate or pretending that the cheapest headline contains the same work.
How should scope changes and the next decision be handled?
Create a separate backlog for ideas that arise during the pilot. Evaluate each request against the learning objective and the consequences of delaying it. A feature that is useful eventually may still distract from the first test. Conversely, a missing recovery path may need attention before the test can produce trustworthy evidence.
Choose the review point and evidence before adding more work. The supplier could review whether participants can identify the current version and whether staff can interpret the resulting decision reliably. Record confusion and failures rather than counting only successful demonstrations.
The outcome may be to continue, revise the workflow, investigate another assumption, or stop. Those are product decisions supported by evidence, not guarantees that an MVP becomes a profitable business. Qualified financial and legal advisers should review decisions in their areas where needed.
What should a Dappr MVP estimate include?
Bring the intended user, business assumption, complete journey, available evidence, known systems, and constraints. The estimate should identify the deliverable, acceptance criteria, ownership, operating costs, and the support period. Confirm whether mobile distribution, third-party systems, or ongoing product work are included.
Dappr's published marketing plans start at $3,500 per month for Signal, $6,500 for Momentum, $10,000 for Command, and $15,000 for Fractional CMO. These figures describe marketing capacity, not MVP development prices. Recheck the current plans page and written agreement; major app work is separately scoped.
This guide does not present an unsupported MVP market range. No suitably scoped current primary range or approved Dappr project range has been established for this article. Use the scope framework to obtain a concrete estimate, and treat any future cited benchmark as context with its methodology and date visible.
Questions before you begin
Is a prototype the same as an MVP?
People use the terms differently. State whether the deliverable is an interactive demonstration, a supervised working pilot, or a production release. The distinction changes the work, risks, and price more than the label.
Should we build every feature needed for the final vision?
Start with the complete journey required to test the chosen assumption. Keep later ideas separate while preserving the safeguards needed for the actual pilot. A narrow but coherent test is easier to interpret than an unfinished collection of features.
Can a manual process be part of an MVP?
Yes, when it is deliberate, appropriately controlled, and described honestly. Include the staff effort and capacity in the operating plan. Do not present a manually performed step as a finished automated capability.
What if the integration requirements are unclear?
Resolve the consequential uncertainty through discovery or a bounded technical assessment before committing to a full implementation price. Record access, limits, data ownership, and failure behavior rather than assuming an integration is routine.
Does meeting the pilot goal guarantee commercial success?
No. A pilot tests defined assumptions under particular conditions. Broader demand, operations, pricing, retention, and other business questions may remain unresolved and require their own evidence.