Services with a clear place in the wider system.

Usually, and the technical feasibility is rarely the constraint. The real questions are whether your plan tier includes API access — a surprisingly common blocker — whether the API is documented and has a sandbox, and whether your IT policy permits the credentials required. Legacy or on-premise systems without an API can still be integrated through database access, file exchange or a small middleware service, with different fragility trade-offs that should be stated upfront rather than discovered. Every integration also needs failure handling designed in: retries, idempotency and reconciliation, not just a working connection.

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.