If your company stopped this weekend,
who would know what to do?

I founded DigitalDev and I am involved, as a partner, in projects at other companies — SingularVision and Codeboys. I issue invoices at half past eleven at night, I stay close to every client, and I pick up the phone on a Sunday when someone needs help. Not out of heroism, and not because I am addicted to work: when processes are disorganised, the week runs short for everything there is to solve, and whatever is left over gets pushed into the evening and the weekend. That is exactly what I help fix — so that there is time left over to live a little of what the effort was for. I am not saying this to sound approachable. I am saying it because I know what it is to start a business and try to reach the goals you set yourself.

For more than two decades I have worked inside a public institution deployed nationwide, and that is where I learned what optimising processes really means: processes serving thousands of people, integrations between national systems, platforms built from scratch and kept running for years. That experience is what gave me the view of what a real optimisation changes in the daily life of the people doing the work. The difference in scale from an SME is enormous; the nature of the problem is exactly the same.

Twenty-five years of building software taught me less about technology than about the way problems disguise themselves. The problem is rarely the one I am handed. Someone asks for a new report, and what is missing is the data being right on the way in. Someone wants to hire another person, and what they have is half a week of work nobody should be doing. So before I propose anything, I measure: how many times a week, how many minutes each time, how many people touch the same piece of paper. It is not glamorous, and it is the only way to know whether it is worth changing — and what it is worth.

It almost always is, because the arithmetic is unforgiving. One manual step of twenty minutes, three times a day, adds up to more than two hundred hours a year: the equivalent of six weeks of one person's work, paid for every year, and showing up in no line of the accounts because it is dissolved into salaries. But the cost recovered is the small part. The large part is what you stop losing — the quote that took three days and went to someone else, the customer who gave up waiting for an answer, the invoice nobody remembered to issue. And then comes capacity: the same team absorbing more work without hiring. That is where this stops being a saving and starts being margin.

None of these problems arrives as a request for software. They all arrive as a sentence said in passing — “this takes me the whole morning”, “I have to do this twice”, “only one person here knows how to do it”. Nobody calls that a problem; they call it Monday. And it is precisely because it has no name that it lasts for years. What you get back at the end is not a tool: it is the morning.

So when someone calls me in to “build something”, most of the time the answer is not to build anything. It is to change two steps, or to switch on a feature that was already paid for and left off. I say so even when it does not suit me — and that is exactly why it is worth listening to me when I say that this time you really do need to build.