From project brief to source handover.
A clear scope, working software to review and a handover you can use. The process follows the project, from first spec to production.
Define it. Build it. Hand it over.
Make the brief concrete.
Tell us who the product is for, what they should be able to do and which constraints matter. Existing source, integrations, launch dates and confidentiality requirements all change the scope.
We identify missing information and the questions that need investigation. A new build and a takeover do not start from the same evidence. If the existing product cannot be run, that is a prerequisite to resolve before estimating its completion.
Agree the release and its boundaries.
The proposal defines the deliverables, assumptions, exclusions and review points. It also states the payment asset, network and milestones. Scope and payment arrangements are settled before the build starts.
Acceptance criteria describe observable behaviour. They should be concrete enough for both sides to tell whether a flow works. A visual reference can guide design, but it does not replace a definition of the product's behaviour.
Review the work as it becomes usable.
Design and architecture decisions are tied to the requirements. Implementation is reviewed through working parts of the product, so permissions, data and interactions can be assessed alongside appearance.
When a new requirement appears, we discuss its effect on the agreed release. We do not hide changes inside a timeline that no longer describes the work. The project needs a single owner for consolidated feedback.
Check the environment that will run it.
Launch preparation covers the agreed user journeys, configuration, deployment and any required migration. Domain ownership, service accounts and access need to be settled before the product depends on them.
For a public website, that includes index controls, metadata and existing URLs. For an application, it includes the important access rules and operational flows. The launch checklist follows the risks of the actual product.
Leave the product in your hands.
Handover includes the custom source, setup notes and the agreed access and operating instructions. Known limitations and outstanding work are recorded. Dependencies and recurring costs remain visible.
Ongoing support or further releases can be scoped separately. The handover should also allow another developer to continue the work without reconstructing the project from conversations.
A few things to know.
Can requirements change during the project?
Yes. A change is reviewed against the agreed scope, with its impact on cost and timing made explicit before it is added to the release.
Do you offer a fixed timeline before seeing the brief?
No. A useful estimate depends on the deliverables, existing systems and unresolved dependencies. Those need to be understood first.
From first spec to production.