/How we work
Six steps, from the first call to handover.
- 01
Discovery
First we work out what the system has to do, and just as often, what it must not do. You end up with that in writing: the scope, the constraints we ran into, and the things that worry us. Better to know them before anyone signs.
- 02
Architecture and stack
We start with the data model, because it is the decision hardest to undo later. Code gets rewritten; a database rarely does. Technology is picked against two things: the load it has to carry, and who will look after it once we are gone.
- 03
Planning
We cut the work into pieces that each end in something you can open and look at. The most uncertain part gets built first, not last. If there is bad news in this project, you want it early.
- 04
Build and test
Short cycles, and at the end of each there is something to show. Tests go where things break quietly: sign-in, permissions, money, dates, background jobs. Those are the failures nobody notices for a week.
- 05
Deployment
The system ships in containers, releases are automated, and the way back is written down before anyone needs it. After deployment we check it from the outside: the certificate, the security headers, whether the real client IP arrives, whether a backup actually restores. None of that can be taken on trust.
- 06
Support and handover
After that there are two paths: we keep it running, or your team does. If it is your team, handover is not just the repository. It is the runbook, how credentials are handled, and sitting down to go through the system together. Tong Yulduzi was handed over this way and has been run by their own people since.
/Engagement
Three ways to work with us.
Fixed scope
An agreed piece of work for an agreed price. Discovery comes first, though: if the scope is not specific, the price cannot be honest.
/Best for
Best for a well-defined piece of work: a specific integration, a migration, a first version with a clear boundary.
Time and materials
You pay for time actually worked, with a log you can check. You set the ceiling, and the scope can change between cycles without renegotiating the contract every time.
/Best for
Best when the requirements will genuinely change as you learn: product work, or a system whose current behaviour is not fully known.
Dedicated capacity
A share of the week reserved for you, every week, working inside your process and on your board. The cost is predictable, and nobody has to rebuild the context each time.
/Best for
Best for ongoing work: a product with a roadmap, or a platform that needs someone who already knows it.
/Questions
Questions we get asked
How much will this cost?
There is no price list, because two projects with the same name are rarely the same work. We start with a short discovery phase. It is paid, its length is agreed up front, and it ends in a written scope with a firm figure rather than a range. If that figure does not work for you, the scope document is yours to take elsewhere.
How long does it take?
A single well-defined task, say an integration, a set of reports or a deployment pipeline, is usually weeks. A whole system is months. The honest answer for your case arrives with the estimate, broken into stages with dates, so you watch the work move rather than wait for one delivery at the end.
I do not have a technical specification. Is that a problem?
No, and it is the usual situation. Most people arrive with a problem rather than a document. Writing the specification is part of the discovery phase and you get it in writing. It is yours whether or not we go on to build the thing.
What is included in the price?
Design, development, testing, deployment, and the documentation needed to run the system, plus a handover so your side knows how it works. What is not included is named before you sign, not after: domain and hosting fees, paid third-party services, and anything requested once the scope is agreed. Those are quoted separately rather than absorbed quietly.
What happens after launch?
Either a support arrangement with an agreed response time, or a full handover with the documentation and access your own team needs. We do not build systems that depend on us being reachable. That is a defect, not a business model.