How we work
A process designed so nothing important is discovered in the final week
Four phases, with explicit deliverables and explicit expectations on both sides. Most project failures trace back to an assumption nobody wrote down — this is our attempt to write them down.
- 011–3 weeks
Discovery & strategy
We spend real time on your business goals, constraints and users before proposing anything. The output is a technical strategy and a roadmap with dated milestones — and occasionally the recommendation that you don't need the project you came in asking for.
What you get
- Requirements and process documentation
- Technical strategy and architecture direction
- Project roadmap with milestones
- Fixed scope and cost proposal
What we need from you
Time from the people who know the process, and access to the systems being replaced or integrated.
- 022–4 weeks
Design & architecture
Interface design, system architecture and technical specification, all reviewed and signed off before development starts. Changing a wireframe costs an hour; changing shipped software costs a sprint.
What you get
- UI/UX designs and interactive prototype
- System architecture and data model
- API contracts and integration plan
- Test strategy
What we need from you
Review and sign-off on designs, plus a decision-maker available for the questions that block progress.
- 03Ongoing, 2-week sprints
Agile development
Two-week sprints, each ending in a demo of working software. Continuous integration and automated tests run on every commit. Progress is visible in the product, not just in a report about the product.
What you get
- Working software demoed every two weeks
- Automated test suite and CI pipeline
- Sprint notes and an open issue tracker
- Staging environment you can use at any time
What we need from you
Attendance at sprint demos and timely feedback. This is the single biggest factor in whether a project stays on schedule.
- 042 weeks, then ongoing
Launch & support
Rigorous QA, staged rollout, and training for the people who have to use it. We stay through go-live and beyond, because the first weeks of real usage always surface things testing did not.
What you get
- QA and user acceptance testing
- Staged production deployment
- Role-based training and documentation
- Support plan and handover
What we need from you
Availability of your team for training, and a nominated owner on your side for the system going forward.
Being straight about it
Where projects usually go wrong
Not a sales page section. These are the failure modes we watch for, and what we do about each one.
Scope grows quietly
Every change is raised as a change, with a cost and a schedule impact, before it is built. Nothing gets absorbed silently and then explained at the end.
Feedback arrives too late
Two-week demos exist to catch misunderstandings while they are cheap. If demo feedback stops coming, we flag it as a project risk rather than carrying on and hoping.
The data is worse than anyone admitted
We profile the real data during discovery, not during migration. It is the most common reason ERP and analytics timelines slip, and it is entirely findable up front.
Nobody owns it after launch
We require a named owner on your side before go-live, and train them specifically. Software without an owner degrades no matter how well it was built.
Ready to start at phase one?
Discovery is where we work out whether there is a project here at all. Tell us what you're facing and we'll take it from there.