A process you can follow.

1. Scope produces a written boundary; it needs context and decisions from the client.
2. Design produces a clickable study; it needs feedback on journeys and edge cases.
3. Build produces reviewable work; it needs timely acceptance input when a decision is ready.
4. Hand over produces source and operational documentation; it needs a named owner for the relevant accounts.

This is the typical shape of a project, not a quotation or a schedule commitment. The actual order, dependencies and effort are set in the written proposal once the problem, access and risks are known.

We begin with the task the product needs to support, the people using it and the constraints around it. Discovery produces a written scope: supported journeys, exclusions, dependencies and acceptance criteria. You keep that document whether or not the build goes ahead.

We identify decisions that need an answer before implementation, including access to existing systems and ownership of external accounts. An unknown dependency stays visible. It does not quietly become an assumed feature or a delivery promise. The constraint may be technical, organisational or legal; naming it early is more useful than designing around an imagined answer.

The interface takes shape in code so you can open it, move through a journey and point to the exact moment that needs to change. We review empty states, errors, keyboard use and narrow screens alongside the main path.

Illustrative data and local interactions are labelled. A working front-end study helps settle behaviour, but it does not imply that storage, permissions or integrations exist behind it. We make those boundaries explicit before moving into the build, so a convincing screen is not mistaken for a completed system.

Weekly builds give you something concrete to review. Each review relates to the agreed scope and identifies what is ready to try, what remains unfinished and which decisions need your input.

A requested change is considered against the scope before implementation. We describe its effect on the work and schedule, then agree how to proceed. Verification follows the behaviour being delivered, including failure paths and the boundaries between connected systems. This protects the useful flexibility of a build from becoming an unrecorded accumulation of assumptions.

You receive source, accounts and documentation. We walk through setup, releases and the ordinary tasks needed to operate the product. Known limitations and unfinished items stay visible in the handover record.

Ownership should not depend on remembering a conversation. Account access and responsibilities are documented, and secrets are kept separate from source code. Any further development or support is an explicit next engagement; leaving should always be possible.

Fixed fee

For a defined scope, we agree the deliverables, acceptance criteria and change process before work begins. A new requirement is discussed as a scope change, with its effect on the work made explicit.

Time & materials

When exploration is necessary, we can agree a bounded discovery engagement based on the work involved. We define the questions to answer and a review point before proceeding. The resulting scope then provides the basis for a build proposal.

The proposal states which basis applies. Neither approach requires a long-term retainer.

• The source repository, with a record of the branch and release state handed over.
• Deployment accounts and a documented account-ownership map for every relevant service.
• Environment configuration instructions, with secrets kept out of source code and transferred through an agreed secure route.
• A written runbook for setup, deployment, routine operation and recovery checks appropriate to the product.
• A record of verification performed, outstanding known issues, limitations and work not included in the agreed scope.

The exact artefacts depend on the product boundary, but the operating information is part of the deliverable rather than an informal courtesy. A handover is complete when another authorised team can locate what exists, understand its limits and take responsibility without relying on a private chat history.