You see the scope and the price before anything gets built.
Four stages, whether the job is a two-week automation or a platform migration. The sequence exists so that the expensive decisions happen on paper, while they are still cheap to change.
Four stages.
- 01
Understand
We spend the first stretch on how the work happens today: what runs where, what people do by hand, what breaks, and what it costs to keep running. You do not need to arrive with a technical brief.
- 02
Scope
You get a written scope covering what we will build, how it fits what you already run, the sequence, the timeline and the price. If the job turns out smaller than you assumed, this is where we say so.
- 03
Build
Short cycles with something you can look at each time. Code and infrastructure definitions land in your repositories from the first commit, reviewed and documented while the reasoning is still fresh.
- 04
Run
We put it live, watch it under real load, and fix the things that only appear in production. From there it is either handed over with runbooks or kept under a managed retainer.
What you are holding at the end of each one.
A stage that produces nothing you can read, run or point at has not finished.
- After understanding
- A written picture of how the work happens now, what it costs in hours and money, and where we think the leverage is. If the honest answer is that the problem is not worth solving with software, you get that instead.
- After scoping
- A scope document: what gets built, in what order, how it connects to what you already run, who is responsible for what, the timeline and the price. This is the thing you sign.
- During the build
- Something running that you can open, at the end of every cycle. Access to the repositories from the first commit, so progress is visible without waiting for a status call.
- After launch
- The system live, with monitoring, alerting, runbooks and documentation. Either a handover session and a support window, or a retainer where we keep running it.
What the first conversation covers.
Roughly forty minutes. You do not need a brief, a budget approved, or anything written down beforehand.
- What the business does and where the work piles up
- What software and infrastructure you run today, including the parts nobody likes
- What you have already tried, and why it did not hold
- Who inside the business would use or run the thing we build
- What would have to be true for this to have been worth doing
- A rough range for cost and time, given before the call ends
What we hold ourselves to.
These tend to go unsaid in this industry until the moment they become a problem, so we put them up front.
- Scope before code
- You see what we intend to build, what it will cost and when it lands, before we write any of it. Changes to that scope are a conversation, not an invoice you find later.
- Everything in version control
- Infrastructure and application code both live in your repositories, under your account. Nothing important exists only in a console someone configured by hand.
- Documented as we go
- Architecture decisions, runbooks and deployment steps are written down while they are fresh, so another engineer can pick the system up without us.
- You own it
- Accounts, code, credentials and documentation are yours from day one. If you want to take the work in-house, there is nothing to unpick.
Start with the first conversation.
Tell us what is slowing the business down. If we are the wrong people for it, we will say so on the call rather than three meetings later.