How we work
You should be able to see the work while it is happening, not at the end.
Most software goes wrong quietly, in the months where everything is reported as on track. The practices below exist to make that impossible: short cycles with something runnable at the end of each, a single person who knows the answer, decisions written down where you can read them, and access to the repository from the first day rather than the last.
What's Included
Discovery before an estimate
We do not put a number on something we have not understood. Discovery is short, paid, and produces the specification everything afterwards is measured against. It is also the cheapest place to find out that the thing you asked for is not the thing you need.
One lead, one channel
A named engineer who knows your system, reachable in a shared channel rather than through an account manager. You ask a question and the person who wrote the code answers it. No triage layer, no ticket that goes quiet for two days.
You watch it being built
Access to the repository, the board, and a running environment from the first week. You can open the code at any point without asking, and the demo is of something you could already have opened yourself. Nobody has to trust a status report.
Every change reviewed before it merges
Another engineer reads every change, and the test suite runs on every one. This is not a formality: it is what stops one person's bad week becoming a production incident, and it is why an engineer leaving mid-project is inconvenient rather than fatal.
Decisions written down
Why a database was chosen, why a queue is in the middle, why an obvious approach was rejected. Short notes kept in the repository next to the code. Six months later this is the difference between changing a system and guessing at one.
A handover written for the team after us
Documentation, environment setup, and runbooks maintained throughout rather than assembled at the end. The test is whether an engineer who has never met us could deploy it on their first day, and we check it by having somebody try.
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
What You Get
Tangible outcomes delivered to your business from day one.
