How we work
A predictable way through an unpredictable thing
Web projects go wrong in familiar ways: scope that was never written down, decisions nobody owned, and a handover that left the client dependent on whoever built it. The process below exists to remove those three failure modes.
- 01
Understand the constraint
Before anything is designed, we work out what is actually binding: a fixed launch date, a budget ceiling, a legacy system that cannot be switched off, or a team that has to own the result afterwards. Everything downstream is shaped by that answer.
- 02
Agree a scope in writing
You get a written scope with what is included, what is deliberately excluded, and where the genuine uncertainty is. Estimates come with the reasoning attached, so you can challenge the assumption rather than just the number.
- 03
Build in visible increments
Work is delivered in pieces you can look at and react to, rather than disappearing for two months and returning with a reveal. Changes are expected — they get priced and scheduled openly instead of quietly absorbed until the deadline slips.
- 04
Hand over something maintainable
Every engagement ends with documentation, access to every account and repository, and a walkthrough. If you decide never to work with us again, nothing about that should be difficult.
A few things we hold to
- Say when something is a bad idea, including when it is your idea.
- No lock-in: you own the domains, the accounts, the code and the content.
- An estimate with a caveat beats a confident number that turns out wrong.
- Prefer boring, well-understood technology unless there is a reason not to.