MVP Development for a focused first product release.

Source code with its full history, database schema and migration record, environment configuration and how to reproduce it, build and deployment steps including rollback, test coverage and how to run it, operating responsibilities, known limitations and outstanding issues, and credentials for accounts already in your name. A repository archive is not a handover. The standard worth holding to is that a developer who has never spoken to us could set the system up, deploy a change and recover from a failure using only what was provided.

Almost never, and the instinct to do so has probably wasted more startup budget than any other technical decision. Architecture built for imagined future volume is slower to build, harder to change and usually wrong about where the load will actually appear. Build for the users you have with sensible foundations — clean boundaries, sane data modelling, no obviously quadratic queries — and measure. Scaling problems are real problems with real solutions, and they are far cheaper to solve when you can see them than to guess at in advance.

Then stopping is the correct outcome, and it should be possible without losing everything spent. Building in slices means there is always a working state to stop at, and testing the riskiest assumption first means the bad news arrives while the investment is still small. That is the entire point of sequencing risk early rather than saving the hard part for last. A supplier who cannot tell you that something is not working, or who keeps building on momentum after the evidence has turned, is more expensive than one who says it plainly.

Map users, decisions, roles, data, integrations, current workarounds and measurable outcomes. Prototype the most uncertain workflow or technical dependency before turning every idea into a backlog.

A prototype tests an assumption and may be disposable. An MVP is a minimal operable product for real users, with essential validation, security, administration, measurement and support.

Use server-side validation, scoped credentials, idempotency keys, signed webhooks, bounded timeouts, retries and a reconciliation job that catches whatever slipped through. The interface needs matching states: pending, failed and recovered, shown honestly. An order must never depend on the customer's browser returning successfully from a payment page.

Include environment documentation, schema and migration history, build and deployment steps, test coverage, operating responsibilities, known limitations and access owned by the client—not only a repository archive.

Cost follows workflow depth, integration count, data sensitivity and how much of the surrounding operation has to change, not screen count. A bounded first release solving one journey is far more estimable than an open brief. Expect a discovery step to produce a defensible range; anyone quoting a fixed figure before understanding the data model is guessing.