Why I built my first app for myself

I had my own development team, but it was up to its ears in client work. When I needed a tool that would help me regain a grip on what was happening in the company, I had no one to assign to build it. So I sat down and did it myself.

On the surface it was a choice made out of necessity. Deeper down it was the best thing that could have happened to me as a future developer. Because it taught me something you cannot learn from any requirements document.

I was the customer and the builder at once

When you build software for yourself, the feedback loop is instant and merciless. Every bad design decision hit me the next morning, at my own desk. I built a screen awkwardly - I lost my own time on it. I left out a field that turned out to matter - I felt the gap myself. There was no “client” to raise a point two weeks later in a status meeting. I was the client, and the status meeting took place every morning in my head.

That system had four functions, and each answered a specific pain I knew from the inside: to know what the salespeople were really working on; to foresee when a machine at a customer's site would start causing trouble; to measure whether anyone even opened our emails; to keep budgets and schedules in check. There was not a single function “just in case”, because no one was paying me to add features. I was paying myself - with time I could ill afford.

Software written by someone who uses it is different

A program built by a person who works with it themselves has a different density. It contains no features added to look better in a sales pitch. It does not have two hundred settings of which you use five. It is the answer to a real process, battle-tested by someone who knows that process inside out.

That is the difference owners sense immediately, even if they cannot name it. Between software someone adapted to you after two conversations, and software that grew from an understanding of your pain from the inside.

Why that changed the way I work today

I now have more than a decade of building systems for other companies behind me. But I still begin every project the same way: I sit down on the owner's side and try to feel their process as if it were mine. Before I propose anything, I want to understand what hurts them in the morning at their desk - because I have not forgotten that pain from 2008.

I build for clients the way I built for myself: exactly as much as is needed, with code and data that stay with them. The largest of them have been with me continuously for many years, and all began with one operational problem that genuinely pressed on them.

What this means for you

If you are looking for someone to build you a system, watch for one thing. Whether that person asks about your process before they talk about the solution. Whether they want to understand what hurts before they sketch a screen. A good system starts with someone who truly understands what you are trying to achieve, and can feel it like a problem of their own.

I built my first system to save my own company. Ever since, I have built other people's with the same care. If you like, tell me about your process for thirty minutes - I will start by understanding it.