How a project runs: five steps, and what goes in the contract
Most software projects go wrong for predictable reasons: unclear scope, late surprises, dirty data and decisions that wait. The process below is arranged around those.
The five steps
- 01
Discover
We sit with the people who run the process, read your data exports and map the exceptions. You get a findings document and a fixed-price proposal for the first release. Both are yours to keep.
You get
Findings document, prioritized scope, risk register
- 02
Blueprint
Screens, data model and integration map, reviewed with you before code is written. A clickable prototype lets your team react to real screens. Changing a screen costs an afternoon now and a sprint later.
You get
Clickable prototype, data model, delivery plan
- 03
Build
Two-week sprints. Each ends with a demo on a staging site loaded with your data. Your team tests the early builds and decides what comes next.
You get
A demo every two weeks
- 04
Launch
Migration rehearsed on copies and reconciled to control totals, users trained, go-live in phases with a rollback point. Our developers work alongside your team through go-live week and check in daily for the first month.
You get
Migrated data, trained team, cut-over run-sheet
- 05
Care
Monitoring, backups, security updates and a monthly block of hours for improvements chosen with you.
You get
Support channel, monthly improvement list
You can walk away and still have a working system.
- You own it
- At handover you receive the source code, the database, the documentation and the deployment scripts. There is no license to renew.
- Paid discovery first
- Discovery is a fixed-scope, paid phase. You keep the findings document and the fixed-price proposal whether or not you hire us to build.
- A demo every two weeks
- You see the build on a staging site with your data in it, and you decide what gets built next.
- Packaged if it fits
- If an off-the-shelf product suits your process, we help you shortlist it instead of selling you a build.
Pay in the way that suits how certain the scope is.
- Fixed price per release
- A fixed price against written acceptance criteria. Changes go through a written change request with an estimate before any work starts. Suits clear requirements after discovery.
- Time and materials
- You pay for the time worked in each sprint, reported every cycle. Suits a product that will change as you learn.
- Dedicated team
- Named developers assigned to you for a set term, usually after a first release.
- Retainer
- A monthly block of hours for support and improvements after launch.
What we put in writing
- Ownership
- You own the software we build for you. Open-source and general-purpose tools we use keep their own licenses.
- Acceptance criteria
- Each release has written criteria agreed before build. A release is accepted when it meets them.
- Change requests
- Scope changes are written down and estimated before any work on them starts.
- Warranty
- Defects found after go-live are fixed under a warranty period set out in the contract.
- Support targets
- Response targets by severity are written into any support agreement.
- Confidentiality
- We sign a mutual NDA before you share process details or data.
Four things that decide how smoothly it goes
- A named decision-maker
- One person on your side who can say yes, no or not yet. Projects slow down most when decisions wait.
- Access to the people who do the work
- A few hours each in discovery, then short check-ins during the build.
- Your data exports
- From the systems you use today, even if they are messy. Early sight of the mess saves time later.
- Your real constraints
- Budget ceiling, hard deadlines and legacy systems you cannot retire.
Next step
Ready to scope it?
Send a project brief. We reply within one business day, usually with a few questions and a suggested time to talk.