How does a custom software project actually run?

Four steps follow, and each one ends with something you can hold: a result, not a status report.

1. 01

   A conversation

   An hour about the process that eats the most time today: who does what by hand in it, where it stalls, when it turns out to have been wrong. It also settles whether there is a system problem behind it at all. Often enough there is not, and then that is what we say. We do not send a quote instead. We charge nothing for this step and it carries no obligation.

   at the end: one sentence on what is worth building, or that it is not

2. 02

   A joint read-through of your own material

   Two hours, on a schedule broken down to the minute: a quarter of an hour on the process as it runs today, three quarters reading ten to fifteen real e-mails together, half an hour on the failure modes we keep seeing, twenty minutes of timing and estimation, ten minutes to decide. Free, no obligation and not a demo: the estimate is built from your own figures, not ours. This form was worked out for e-mailed order intake, because there the material exists to be read; for another kind of work the second step looks different, and we do not pretend otherwise.

   at the end: a timing and savings estimate built from your own figures, and a yes or no on running a pilot

3. 03

   Survey and a written specification

   Mapping the existing system and the process around it. This is where the things that double an estimate come out: the undocumented integration, the hand-kept spreadsheet in the middle of the flow, the system nobody has the password to any more.

   at the end: a written specification, split into phases, priced per phase

4. 04

   Delivery, phase by phase

   Not one large delivery at the end, but working pieces one after another, each of them in the live system.

   at the end: one working piece per phase, usable in the day-to-day work

The first step is free precisely because its outcome can be a no. There are a few recurring situations where we are the wrong choice from the start. We have written those down separately.

Five situations where we are the wrong choice →

Working functionality, phase by phase: not a status report and not a demo environment.

At the end of every phase something runs in the live system and can be used in the day-to-day work. That has two consequences. One is that feedback comes from real use rather than imagined use: what surfaces is what is missing from something already in hand, not what looks appealing in a screenshot. The other is that the project can be stopped at any phase boundary with the work so far still functioning.

Two separate things happen, and we do not blur them: checking the code is machine work, accepting the result is human work.

The work runs on parallel threads, each in its own working directory and on its own branch, under a cap. No thread's output goes in automatically: it has to pass a row of checks first. Does it compile, do the tests pass, did the change stay inside the agreed scope, is there a test for it, does it match what was written down; on web work, end-to-end tests and a screenshot comparison of the rendered page as well.

Most of those are deterministic: the exit code of a run decides, not an opinion. Two of them (the code review and the match against the written spec) are judged by a model, and we say so, because that is not equally strong evidence. When a check fails, nobody starts investigating by hand: a machine-readable failure report is produced, and the work restarts from that, within a bounded retry budget.

Merging is deliberately one at a time. Each change gets a fresh main branch merged in first, the integration checks run on that, and only then does it go in. It costs throughput, and it buys the case nothing else catches: two threads that are each faultless on their own can still break together. And a change is not done until the written spec is updated with it: that is how this round's output becomes the next round's input.

What clears all that is accepted by a person. Not by reading the lines of code, but by trying the result: is the job solved.

This page is built the same way. Four machine checks run on every change to it: that every route has a place in the site map, that no component is left with nothing referencing it, that the colours in the figures are readable against the background, and that the same claim does not appear in too many places. The first run of the contrast check disproved two values our own knowledge base was carrying. Since then the measurement runs against our written material as well, not only against the code. This working method comes from our own development framework, and the same framework drives client projects; which checks ran on any given project is not broken out per project today.

The same method on one page: software development from a specification, with AI agents

Go-live is not an end point. The system keeps changing at a daily rhythm, and what ships gets a release note inside the application, so that the people using it do not learn what changed by word of mouth. On one of the systems we delivered, there was no week of downtime between 14 June and 3 August 2026.

Measurement happens in production too, not in a demo: accuracy is measured by replaying real traffic, against what the client's own colleague actually approved. Every figure we quote carries what it was measured on and when.

With an hour. We talk about what is done by hand today, and at the end we say whether there is a system problem behind it. If it turns out not to be worth it, we say so. That is an answer too, and it is cheaper now than after a specification.

Let's talk about it →