How we work
One plan, in writing, and a date on the wall.
The difference between software that ships and software that drifts is mostly method. Here is ours, step by step.
The method
Eight steps, the same on every engagement.
A working call
You bring the problem. We ask a lot of questions, and you leave with a one-page memo on how we’d approach it.
Agreed in writing
A written requirement: what it does, for whom, what’s out of scope and how we’ll know it works. You approve it before any build starts.
Decisions recorded
Every significant technical choice is written down with the options we turned down and why, so nobody has to guess later.
Designed in every state
Every screen drawn in every state — empty, loading, error, done — in English and French where you need both.
Tests first
Tests are written before the code. Then we deliberately break the code to prove the tests notice.
Small, reviewed changes
Work lands in small changes, each reviewed independently before it merges. Anything touching money, sign-in or personal data gets a reviewed design and your approval.
A weekly written update
What shipped, what’s next and what’s at risk — on one page, every week.
Released with a way back
Every release follows a checklist, with a rollback we have rehearsed. At handover: runbooks, alerts and documentation.
What you’ll always have
No surprises on the day.
One written plan you approved
Changes to it are written down, with their effect on dates and price, before anyone acts on them.
A date you can plan around
If a date is going to move, you hear why in advance — not on the day.
The weekly update
In writing, every week, whether the news is good or not.
Access as we go
To the working software, the code and the documentation, throughout.
A handover your team can run with
Documentation, runbooks and alerts — not a dependency on us.
Questions
Questions about the method
Is the scope fixed?
The scope is agreed in writing before the build. If it needs to change, we write down the change and what it does to dates and price, and you approve it before anyone acts on it.
What if a date slips?
You hear about it as soon as we see the risk, with the reason and the options — not on the day it was due.
How involved do we need to be?
Enough to answer questions, review designs and approve releases. We keep the asks small and scheduled, and the weekly update tells you what we need from you.
Is this only for large projects?
No. The method scales down: a small internal tool gets the same written scope, tests and release checklist — just shorter.
See the method on your problem.
The first call is where it starts. Bring the problem and we’ll show you what the written plan would look like.