Doing the right thing, fast

This morning, I said to Mike, my co-founder at Trackberry: now that you can go so fast at doing anything, the real challenge is doing the right thing fast. It’s easy to do useless things, fast.

I said it half as a joke. The more I think about it, the less it sounds like one.

Speed used to be the filter

For most of my career, building something took time. When I started WebTranslateIt in 2008, a new feature could take me weeks. That cost was annoying, but it did a job: it forced me to think before I started.

If a feature was going to eat two weeks of my evenings, I wanted to be sure someone needed it. I’d wait. I’d see if the same request came back from a second customer, then a third. Many ideas died quietly in that waiting time, and most of them deserved to.

The slowness was a filter. I didn’t choose it, but I relied on it.

Useless things, fast

That filter is gone. With AI writing most of my code, a feature that took two weeks now takes an afternoon. Sometimes an hour. I can have an idea at breakfast and ship it before lunch.

It feels great. It’s also a trap.

When building is cheap, the expensive part moves somewhere else. Every feature still has to be explained to customers, supported, kept working, and carried in your head. A product with fifty half-useful features is harder to use than one with ten good ones. The code is cheap now. The complexity isn’t.

And there’s a quieter cost: attention. A day spent shipping three things nobody asked for is a day not spent talking to the one customer who’s about to leave, or fixing the thing everyone trips over. Going fast in the wrong direction just gets you lost quicker.

The upside: doing it better

There’s a better way to use the speed. Instead of building more things, build the same things better.

For years, the parts I cared about most were the first to be cut. Usability, polish, security. I studied design and usability in Sweden and it shaped how I think about software, but with limited time the feature always came first. The empty state stayed ugly. The confusing screen stayed confusing. The security review waited for a quiet month that never came.

Now I have the time. I can redo a screen three times until it feels obvious. I can run security checks on every change and have an AI review the code before it goes live. I can fix the small annoyances that customers stopped mentioning because they gave up.

If we do it right, we don’t just go faster. We do the same work, faster and better than before.

What I try to do instead

I don’t have this figured out. But a few habits help me.

• Put the waiting back on purpose. Before I build something, I write it down and leave it for a day or two. If I still care about it after that, and I can say who it’s for, it gets built.
• Start from a real person. At Trackberry, the best features came from watching importers work: someone retyping the same container number into three spreadsheets, someone chasing a missing document by email. If I can’t name the customer and the problem, I’m probably building for myself.
• Count what I remove, too. Fast building makes it tempting to keep adding. Deleting a feature nobody uses is now just as cheap, and often more useful.
• Spend the saved time on the slow parts. AI gave me back hours. The best use of them isn’t more code. It’s more conversations, more thinking, and more sleep.

The skill that matters has shifted. It used to be: can you build it? Now it’s: should you?

Fast is not the point

Speed is a gift. I wouldn’t go back. But speed only multiplies whatever direction you’re already going in.

So the question I try to ask myself each morning isn’t “what can I build today?” It’s “what’s the one thing that actually matters?” Then I do that, fast, and as well as I can.

Málaga, 11 November 2026.