I love
software.

I have been studying those moments for most of my life.

As a kid, I spent hours at the computer trying new software and exploring every corner of it. Beta testing was more exciting when a company mailed you a CD in elaborate packaging, but the impulse is still the same today: install the new thing, understand how it works, and notice the decisions its builders made. I wanted to know why some software felt magical while other software, even when it had all the right features, did not.

That curiosity shaped my life. I studied computer science. I wrote about technology as a journalist. I learned how software is positioned and sold at a web agency. Then I moved closer and closer to building products myself, spending more than a decade in marketing technology.

Looking back, the path feels remarkably consistent: I have always wanted to understand software, from how it is built to how it feels to use. I lost sight of that for a while, but the fascination remained — and eventually turned me from an observer into a builder.

Knowing how to implement a feature matters. Knowing which feature should exist, what shape it should take, and what can be left out matters just as much.

After decades of using, examining, explaining, and building software, I have developed a feel for those choices. I can often sense when a product is fighting its user, when complexity is leaking through the interface, or when an idea has not yet found its simplest form. That instinct is not magic. It is accumulated exposure: thousands of products, patterns, mistakes, elegant decisions, and conversations with the people who use what we build.

I bring that judgment to my work as a product lead at Mapp, where I lead a team of product managers and help turn difficult technical and business problems into products people can actually use. The work I enjoy most happens where technology, customer needs, and product craft meet — when the problem is still ambiguous and the right solution has to be discovered rather than merely delivered.

I bring the same perspective to the things I build on my own. Projects such as Mäuse, a local-first expense tracker for couples, give me a place to follow an idea all the way from a personal frustration to a working product. They let me make every decision, live with the consequences, and keep refining until the software feels right.

For a long time, ideas came with a heavy tax. Every new platform, framework, language, or discipline created another barrier between imagining something and making it real. I could learn any one of them, but not all of them deeply enough, quickly enough, while still having a life and a full-time job. Many ideas remained sketches because the cost of crossing every technical boundary was simply too high.

AI has not made craft irrelevant, and it has not replaced judgment. If anything, it makes judgment more important.

But it has dramatically shortened the distance between curiosity and creation. I can move across technologies, test ideas while they are still fresh, build several versions instead of committing to the first one, and spend more of my energy on the product itself: what it should do, how it should work, and whether it deserves to exist.

That feels liberating. The interests I have collected over a lifetime no longer sit in separate boxes — computer science, writing, design, product strategy, technology, and the study of how people use tools. I can bring them together and work more like the kind of builder I always wanted to become.

This is also why I write about the AI-enabled product builder. I am interested in more than generating code faster. I want to understand how AI changes the creative process of building products: how it makes exploration cheaper, iteration faster, and ambitious ideas more accessible to people with strong product instincts.