A change in direction
This is my third or fourth attempt at a personal website, and to be honest, I’ve never been happy trying to maintain one.
When I have pressing projects that need a lot of work, I would much rather spend the time on them than on telling the world about them. I’d rather get the project out there first. That has very much been the case with my most recent project, Namagen, a real-time generative music environment that I’ve spent the last five or six years working on.
So what has changed? Quite a lot. Perhaps the biggest change for me has been easy-to-use, very accurate speech-to-text tools. I use Wispr Flow to write all my blog posts, and I’ll keep doing so. It means I can knock out a post in about 10 minutes while I’m walking around the park, waiting for something, or trying to get my baby to sleep.
In the past, I just wouldn’t have had time to sit down at the computer and type something out. Even if I had, I would rather have spent the time programming, even though I do want to get my thoughts out there.
Typing out a post and editing it meticulously would no doubt produce a better-written article. But I don’t have that luxury at this stage, so I’d rather get the information out there, even if it’s just a brain dump through Wispr Flow.
I want this post to mark an inflection point in my life and a change of direction. It has mostly come about because my first son was born five weeks ago, which has brought major lifestyle changes. Above all, it has meant less time in front of a computer and fewer long stretches for deeply focused work.
Up until now, Namagen has very much been a “handmade” project, and it still is, in that I used minimal libraries. Everything was written from scratch in C, and I understood every part of the application, from sample-level DSP to the overall architecture. I implemented things such as:
- my own programming language
- a virtual machine to run it
- serialisation
- multithreaded audio processing
- a 2D graphics renderer
- a UI library
In fact, the only external libraries I used are some of the stb libraries and a few other small single-header libraries for things I simply didn’t have time to write.
This has been an incredible learning experience, and I’ve produced something I’m very proud of, including things that five or six years ago I didn’t think I was technically capable of:
- a unison-capable, multi-voice 8-op FM synthesiser
- a beautiful-sounding reverb
- an entire audio graph
- the ability to manipulate that graph, write and modify sequences, and record, all in real time
But therein lies the biggest problem with working this way. I worked on it while I was employed, so there was no pressure to make any income from it. I always believed that people would want to use it because I was building something I wanted to use, and that I could make a nice living selling it honestly at a reasonable price.
I was in love with the work, perhaps even more than with the product itself, and nothing shows that better than my handmade approach. I loved having control over every detail: how data was stored and manipulated, right down to the sample, performance characteristics, SIMD implementations, every single thing. I spent more hours on it than I can count.
I now honestly believe this is completely the wrong approach if you want to build a product people will use. It’s become a bit of a Silicon Valley cliché, but I think it’s entirely true: you need to test your product, fail early, and figure out what people want and what problem you’re solving for them before you go all in and dedicate an insane amount of time to building something.
The problem with the handmade approach is that the initial decision about what to build carries a massive risk of sinking your time. Sure, you can prototype, and you can change course as you build. But if the first time you find out whether people want it is years down the track, you’re in for a shock.
I think that was very much the case with Namagen. It’s an app that contains a programming language, and programming languages, while very interesting to a developer like me, are not something most users want to use, especially in the age of AI and LLMs. People can just prompt in English and get what they want without ever looking at what the code is doing.
As someone who cares deeply about good code, that disturbs me on many levels, but it’s where we are. I think if Namagen had been released five to ten years ago, it would have been a different story. But the customers who once might have put up with learning a programming language to create generative music would now much rather use an LLM.
If anything, I think Namagen might eventually lean that way, with English prompts becoming the main interface for building generative sequences and systems, while the same programming language still powers the backend.
But that’s beside the point. This post is about the inflection point: realising that I’ve spent five or six years on an insanely complex, insanely deep programming passion project that has very low demand and not much potential as a product.
When I say not much potential, I mean it does have some, and I’m still going to chase it, but the return on the time invested is pretty low. Practically speaking, I want to live comfortably off my software and support my family with it. It’s just not good enough for me to work on a passion project with a massive upfront investment that still can’t pay my bills.
I’m not saying it never will. I’m still hopeful I can turn Namagen into a product that makes decent money, and I’ll pursue every avenue towards that, whether that means making it more game-like, more like middleware, or the substrate for an LLM interface I mentioned above. But now I want to talk about the inflection point.
A week, on my phone
About a week ago, I started work on a small app called Ultimate Kami. (Kami means god in Japanese.)
It’s a very simple fitness app that tracks the calories in the food you eat against your weight-loss targets. It also tracks your weightlifting in the gym, so you can see how you’ve performed in the past and where you’re trending. It’s a very simple data collection and visualisation app. But here’s the thing: I built the whole thing and released it on the App Store in a week, from start to finish. I did it while taking care of a four-week-old son and doing all the housework to support my wife while she looked after him too. I did almost all of it on my phone through a remote connection to Claude, often while cradling my son and trying to get him to sleep: prompting, building, checking, and repeating.
This is such a wild contrast to the approach I took with Namagen that my brain can barely fathom it. Granted, they are very different apps, and Ultimate Kami is very simple in comparison, so I’m not suggesting they’re the same thing or even close.
But the fact that I could build it on my phone in plain English, without typing anything, is pretty damn unreal. And given how hard it’s been to find a place in the market for Namagen, and how easily I got Ultimate Kami into a shippable state, it has made me seriously question how I should approach things in the future.
Going back to my earlier point, the biggest difference with Ultimate Kami is that it’s not a passion project. At no point did I love working on it.
Sure, it was satisfying to see a little UI idea come to fruition from an English prompt and be tweaked until it fit my needs. But the primary goal was an app that would help me track my progress in the gym and in the kitchen. It was very much utilitarian, purpose-driven development.
It was built to solve a simple but concrete problem I’d been having, and it solved it so well that I was kind of shocked. If you know anything about fitness apps, you’ll know there are hundreds of them out there, all doing roughly the same thing. So why build my own? If you’ve tried one, you’ll know they’re full of bloat: social media bits, logins, monthly payments, news feeds, and a whole bunch of other crap that’s completely orthogonal to what I want from the app. I just wanted something minimal that was fast, responsive, easy to use in the gym, and gave me a great overview of where I was at.
Falling in love with the problem
So how would I sum up this change in direction? From now on, my passion won’t be the work itself. I’ll do my best to avoid falling in love with the work, and if I catch myself doing it, I’ll snap out of it. Instead, the obsession will be customers: finding problems valuable enough that people will pay to have them solved.
That’s what I want to be obsessed with and fall in love with. It’s a very different approach to making products, especially for someone who has been an engineer for most of his adult life.
Using LLMs and coding agents means taking off my engineer’s hat and putting on a manager’s hat. Agents are much more like a team of programmers at your bidding, and you’re now responsible for getting the most out of them.
You also have to resign yourself to the fact that you almost certainly won’t get as good a result as if you learned the frameworks and the technology, really got into it, and wrote the code properly yourself. But it all becomes worth it when you realise you can run these workers in parallel and reap the efficiency gains.
Being able to talk to these workers in plain English is also a win, because you no longer have to work in a terse, error-prone programming language. On the flip side, English is lossy and full of ambiguity, and you have to deal with the inaccuracy that comes with that.
So I can see why this is a hard pill to swallow for many engineers: you’re basically changing jobs.
That said, intimate engineering knowledge of your domain (or even a general understanding of the architecture and data) is a massive advantage when working with agents. It’s much like having a manager who used to be an engineer and can understand what’s going on at that level, and direct how things should be built.
But back to the main point before this rambles on too long.
Minimum viable startups
From now on, I’m setting myself the challenge of creating minimum viable startups. Yes, this is very much taken from Pieter Levels’ 12 startups in 12 months, but that challenge was well before agents were a thing. I believe that with agents, much more ambitious startups can now be built in much less time.
Depending on the domain, I think you can get something off the ground within a couple of weeks, test it, see if it has some tailwind, and if it does, lean into it and push to make it more successful. Ultimate Kami is the first iteration of this challenge. The challenge is ultimately about making money online, and I know that may sound shallow compared with “trying to change the world”. But as long as it’s not shady or illegal, making money online is really about solving customers’ problems, which leads back to changing the world for the better.
I have no qualms about chasing money as I build products. The real challenge is keeping it up and accepting that most of these products will probably fail.
Perhaps the most revealing thing on Pieter’s website is that around 70% of his projects “failed”, in the sense that they made no money. But you could easily argue that they succeeded, because they led to projects that did make money, or at the very least taught Pieter how to be a more effective entrepreneur. So the old Scott Adams adage of “aiming to fail” is very apt here, and I think it’s a much better approach: a very short iteration time, trying out an idea, testing the water, seeing if it leads anywhere, and if it fails, no big deal, on to the next.
Compare that with Namagen: six years building something you absolutely love, where the sunk cost is so stupidly high that you can’t bear the thought of giving up on it, or of it never becoming what you expected. The contrast is black and white to me, and perhaps 100 times more so in the age of agents and LLMs.
One thing I want to emphasise is that I’m not going to shy away from big projects. In the age of agents that can control other agents, I firmly believe it’s possible to chase problems that only a few short years ago would have needed a team of at least 100 people.
As a one-man startup, I really do think it’s still worth taking on these big ideas. My fitness app arose out of personal need, and it may or may not be financially successful, but I honestly don’t see why it should be any different for a project with a much larger scope, whether that’s a complex game, nuclear reactors, power generation, or even AI itself. I really do think anything is within reach nowadays, and that will only become more true over the next few years.