How we work
Six steps, from the first call to handover.
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.
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.
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.
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.
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.
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.
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.