Process
Six stages, each ending in a deliverable
What sinks software projects is rarely the technology. It is vague scope. So every stage here ends in something written or something you can try, and you approve it before we move to the next. No stage ends in a verbal understanding.
The stages
Exactly what happens in each stage
And why we skip none of them.
Scoping
A call to understand your business, the problem and where you want to get to, then agree what is in the project and what is not. You receive a written summary of what was agreed.
Plan and cost
A document with the specification, delivery stages, cost and timeline. You review it and request changes, and no build starts before your written approval.
Design and structure
The key screens and the data model or site map. You see the shape and the flow before it becomes code that is expensive to change later.
Build in batches
We deliver in short stages, and you review each one on a live link and ask for changes. You never wait until the end of the project to see the result for the first time.
Testing and launch
Testing on real devices and browsers, checks on performance, accessibility and search readiness, then launch with code, documentation and training for your team.
Support and iteration
An agreed support period after launch to fix whatever surfaces. After that we either continue on a clear arrangement, or your team continues using the handover documentation.
Deliverables
What actually reaches you in writing
Documents and files, not verbal promises.
Before any build starts
- A written summary of the scoping call
- A detailed project specification document
- A stage schedule with delivery dates
- An itemised cost and payment stages
- An explicit list of what is out of scope
At launch and after
- The complete source code repository
- Operational docs and deployment steps
- A training session for your team
- A performance and accessibility report
- Support channels and an agreed duration
Changes
How we handle change requests
Change during a project is normal and we do not treat it as a problem. The real problem is unpriced change that quietly eats the schedule. So anything outside the agreed scope gets an estimate in time and cost in writing, and you decide whether it goes in now or waits for a later stage.
The rules on changes
Delivery questions
How a project actually runs
How long from first message to work starting?
Who do we talk to during the project?
What if we are late reviewing a stage?
Can you work alongside our in-house technical team?
Start here
Tell us about your project
Send us two lines about what you need on WhatsApp. We reply, book a short scoping call, then send a written plan with cost and timeline before you commit to anything.