Twenty starts and no finish
A user cannot validate a product they cannot complete.
MVP and web app development
Build the smallest version people can actually use.
One complete user journey, real feedback and a codebase with a next step. Focused MVP builds are provisionally £3,000 - £10,000.
Responsive web products. Native mobile apps, regulated decisions and broad platforms need separate discovery.
First release loopsynthetic plan
01One user arrives
02Completes the core task
03Receives a real outcome
04Creates evidence
✓ Useful end to end beats impressive but unfinished.
Onecomplete user outcome
Realpeople and behaviour
Ownedcode, data and access agreed
Nextdecision made visible
Interactive first-release scope
Start with the loop. Then choose the features.
Choose the closest product shape. The preview shows what must work, what can wait and where the first serious risk sits.
Scope explorer
01
User outcomeWhat must become true
First evidence
A customer signs in, submits one request and can see its real status.
One customer role, one request type, one owner queue and essential notifications.
Complete loopSign in → request → owner action → status → confirmation
02
Product boundaryWhat the proposal protects
focusedLikely build route
Responsive web app with a focused account area
- Leave for later
- Complex permissions, several request families, native apps and broad reporting.
- Test the risk
- Identity, access boundaries and the information visible to each account.
Minimum does not mean careless
Cut surface area. Keep the whole outcome.
Ideas become expensive when the first scope tries to satisfy every future user, copy every competitor and solve every edge case. The result is often a long feature list with no complete journey, no owner for decisions and no clear evidence of whether the product should grow.
The loudest opinion becomes scope
Likely users and real behaviour provide better evidence.
A convincing screen hides missing work
Data, admin, failures and support still make the service real.
Traffic is called product proof
The measure must connect to the outcome being tested.
The unit of scope
One useful journey, front to back.
The screen a customer sees is only one part. A dependable MVP also needs the owner action, data state, failure route and confirmation that complete the service.
- 01A clear start and eligibility
- 02The smallest useful input
- 03A real rule, owner action or integration
- 04A visible result for the user
- 05A record, measure and recovery route
Six decisions before code
Clarity is the first development tool.
These answers turn an app idea into a proposal that can be tested and changed without pretending uncertainty has disappeared.
User
Who has the problem and can we reach them?
Outcome
What can that person do after release?
Owner
Who makes product and operational decisions?
Data
What enters, where it goes and who may see it?
Risk
Which assumption could make the product fail?
Signal
What behaviour informs the next decision?
A phased build with decision points
Learn before launch. Learn again after it.
Discovery identifies one user, one costly problem and one complete outcome. Ernest maps the smallest dependable loop, prototypes uncertain parts, builds the agreed web product, connects only essential services, tests the real journey and launches to a controlled first audience. What users do next informs the next release.
The proposal names deliverables, dependencies, acceptance checks, ownership and what is outside the first release.
- 01Frame
User, outcome, constraints and evidence.
- 02Prototype
Test the uncertain interaction or rule.
- 03Build
Complete the agreed front and back journey.
- 04Verify
Usability, accessibility, security and failure checks.
- 05Release
Controlled launch, support route and measurement.
- 06Decide
Improve, expand, change direction or stop.
Technology follows the product
Use the lightest foundation that can carry the next step.
The right answer may be a focused WordPress and PHP application, a bespoke React and Node product, or a careful extension of something the business already owns.
WordPress and PHP
Strong when content, publishing, accounts and familiar administration form most of the product.
Avoid rebuilding a capable CMSReact and Node
Useful for bespoke workflows, live interfaces, application logic, integrations and product-led experiences.
Use complexity where it earns its placeExtend or connect
Sometimes the fastest proof is a new interface or workflow around an existing CRM, shop, API or database.
Preserve useful systems and dataProduction basics belong in version one
Risk is scoped. It is not postponed.
Controls match the people, data and consequence involved. A small release still needs deliberate access, validation, recovery, privacy and an accessible core journey.
Roles, sessions and account recovery fit the product.
Collection, storage, sharing and deletion have owners.
Errors are visible and important actions can recover.
The complete core task works beyond one device and input method.
Backups, logs, support and provider costs have a real path.
Working product proof
Not only client websites. Products with real moving parts.
These current Work records show React and Node products with users, providers or operational records. The figures describe those products, not a promise for a new MVP.
Provisional MVP build range
Enough to learn. Built to continue.
Useful for a founder or established business with access to likely users, a decision owner and a real problem worth testing. The provisional range covers focused web products; regulated decisions, native mobile apps, several user organisations, complex migrations or broad integrations may need a larger phased proposal.
See all website and system prices →Focused one-off build£3,000 - £10,000hosting and external service costs separate
- Outcome framing and first-release scope
- Responsive interface and essential back-office path
- Core data, roles and agreed integrations
- Acceptance checks, controlled release and handover
Near the lower end means one role, one core loop, light administration and few dependencies. Multiple organisations, payments, migration, AI, complex integrations, regulated data or richer operations move the work upward or into phases.
Schedule and ongoing support are proposed after scope. No fixed standalone monthly figure is claimed.
Before funding the first release
MVP build questions.
Is an MVP only a clickable prototype?
Not by default. A prototype can test a risky idea before coding, while the MVP described here is normally a focused working web product that completes one real journey with appropriate production basics. The proposal states clearly which stage is being priced.
How do we decide what belongs in the first release?
Start with one user, one important problem and the smallest complete outcome that can produce useful evidence. A feature stays when removing it breaks that journey, makes the test unsafe or prevents the result from being measured. Useful extras become named later work.
Will I own the code, data and service accounts?
Ownership and access are written into the proposal. The preferred setup keeps the agreed source code, domains, hosting and core service accounts visible and transferable, subject to any third-party licences or provider terms identified before work starts.
Can the first version include payments, AI or integrations?
Yes when one of them is essential to the outcome being tested. Each connection adds provider rules, failure states, cost and testing, so the first release normally chooses the smallest dependable path rather than connecting every future system.
Is security, privacy and accessibility left until later?
No. The level of control depends on the data, users and risk, but access, validation, backups, privacy, essential security testing and accessible core journeys begin in the first release. High-risk or regulated work may require specialist review and a larger scope.
What happens after the MVP launches?
The first release needs an owner, a support route and a small set of agreed signals. Real use is reviewed against the original assumption, then the next decision can be to improve the loop, add a proven capability, change direction or stop without pretending every idea must become a large platform.
Bring the problem, not a perfect specification
Find the first outcome. Protect the next decision.
Show Ernest who struggles, how they cope today and what evidence you already have. You will get a clear route before a large feature list becomes a commitment.
Discuss your product ideaExplore every system and add-on →Email or telephone only. No obligation and no ownership ambiguity.