How I work · Software
From the first question to running in production.
My process has eight phases. We start by working out what your problem actually is: do you need what you think you need, or is there a more elegant solution? Then we work forward step by step, build prototypes where something is unclear, measure what helps us decide, and in the end build the thing that generates real value and gets used. When it is time to adapt and move on, we find a sensible handover without driving the day-to-day business into a wall.
1Requirements engineering2–5 days
Two or three sessions in which we turn your request into acceptance criteria we both sign. Most of the work is finding the constraints nobody thought to mention: the spreadsheet that has to keep working, the third-party API that rate-limits, the colleague who will operate this once it is live.
If skipped you get a half-considered wish list built, and find out afterwards that something else was needed.
2Prototyping1–2 weeks
A rough version you can click through and run against real data, inside two weeks. It is deliberately minimal and full of gaps. Its job is to turn “I imagined something different” into a specific sentence while changing it is still cheap.
If skipped the first realistic conversation about scope happens once the budget is gone.
3MVP2–6 weeks
The first version somebody can do their actual work in. The path most people take runs end to end: the data, the permissions, the error messages, the screen they sit in front of all day. What is used twice a year stays out until it is needed.
If skipped your users wait for the feature that matters until every nice-to-have has been built.
4System hardening (operational readiness)1–3 weeks
This step is about fault tolerance, self-healing and scale. Timeouts, retries, partial failures, and the states you hoped would not happen: the connection that drops mid-write, the job that runs twice, the upstream service that answers with yesterday’s data … or stops answering at all. A system that catches and repairs most of its own faults is one you sleep through.
If skipped customers, support, the department head and the sysadmin are all delighted when the core system does something at 03:00 that keeps them busy for the rest of the week.
5Observability & telemetry3–5 days
Logs, metrics and traces make the system transparent, trustworthy and accountable. Answering “what did it do at 14:32, and why” without guessing means the system has to leave traces. While it is being built that is quick to add; in a running system that quietly works through its core logic, the behaviour can barely be reconstructed afterwards.
If skipped every further step rests on guesswork instead of data.
6Live operation & measurable improvementongoing
Six weeks of real operation say more than any planning round: which paths are hot, which queries hurt, and what nobody touches. What gets used gets built out, along with the two or three variants worth comparing. Optimisation goes where the load actually is. Usually a third of the original nice-to-haves goes, and two things nobody asked for turn out to matter.
If skipped indispensable. Every feature added here makes the system measurably better.
7Maintenanceongoing
A standing few hours a month: dependency and security updates, third-party API changes, expired certificates, and the small repairs that stop being small if left alone.
If skipped maintenance arrives as an emergency exactly when nobody has room for it, and is billed accordingly.
8Replacementwhen it is time
The system keeps being developed, but at some point it reaches a technical limit, the last developer who can still maintain it moves on, or the law requires a more regulated system. Either it goes out with a bang, or it is replaced piece by piece, with adapters, bridges and surgical changes, without putting the day-to-day at risk. In a rebuild, critical modules can be translated, adapted or reused. What the old system learned over years — the edge cases, how it was really used, the numbers that mattered — is where the next one starts.
If skipped the system stagnates, falls behind what is now required of it, or becomes unmaintainable.