What our delivery process actually looks like
A look inside the kitchen: how work moves from a first call to running in production, and where projects usually stall.
- Delivery
- Process
Delivery processes sound the same on every agency website. Discovery, design, build, launch. The interesting part is what happens between those words. Here is how a project actually moves through our shop, including the parts that are awkward to admit.
Week zero: we try to talk you out of things
The first working session is mostly subtraction. We take the feature list and sort it into three buckets: needed to launch, needed eventually, and probably never. Most lists lose a third of their weight here. This is uncomfortable because everything felt important when you wrote it down. It is also where the budget is really decided.
We build a thin slice end to end first
Before we build breadth, we build one feature all the way through — database, API, UI, deploy pipeline, monitoring. A single vertical slice running in production tells us more than a month of planning:
- Are the integrations real or theoretical?
- Does the deploy actually work from a clean environment?
- Where is the latency hiding?
If the slice is hard, the project is hard, and we would rather learn that in week one.
Short cycles, visible board
Work runs in one-week cycles. Every ticket is on a board you can see, and every Friday there is a running deploy you can click, not a slide. If a week produced no demoable change, that is a flag we raise ourselves.
Where projects stall — and it is usually not code
Honest list of what actually blocks delivery:
- Decisions. A question waiting on your side for two weeks costs two weeks.
- Access. Missing credentials to a third-party system stop everything.
- Scope that quietly regrew. The bucket of "eventually" leaking back into "now."
We surface these fast because a stalled week is expensive for both of us.
Handover is a feature
At the end you get the repository, the infrastructure, runbooks for the common failures, and a recorded walkthrough. The goal is that your team could run this without us. If you choose to keep us on for maintenance, that should be because it is convenient, not because you are locked in.
More writing
Have a project that needs this kind of thinking?