For more than a year, I put a great deal of energy into learning how to build a product well, and I never tired of it. How a feature should be designed, what was still wrong with the experience, which details could be adjusted next. There is always somewhere further to take a product, so it is easy to keep sinking in.

Only after the product launched and I actually faced promotion and users did I realize I might have been studying the wrong question from the start. I kept thinking about how to make a better product, and almost never seriously asked the question in front of it: why can independent development be a business at all?

I had my own answer, of course. For a long time I even thought it was fairly complete. The problem is that things didn’t happen the way I imagined. The absurd part is that this should have been the mistake I was best at avoiding.

Before going independent, I was a programmer for many years, working my way up from junior developer to architect. I was never quite able to stay quietly in the engineer’s lane, though. At every company, beyond doing my own work, I kept drifting over to the product managers to ask: why is this product being made? How does the company make money? What are all these problems everyone is busy solving actually improving? Not because I enjoy snooping. It’s that if I stayed somewhere long enough and still couldn’t understand what the company was trying to become, or why its business could hold up over the long run, I found it harder and harder to keep investing myself. It even shaped my choices: I did leave companies over exactly this, knowing the life I’d just settled into would have to start over.

So for a long time I thought of myself as someone who didn’t only look at the local problem. Writing code, I’d think about why the product was designed that way; a step further back, what the business rested on.

Then it was my turn, and I fell in anyway—into precisely the mistake I’d always been quickest to spot in others.

I started working independently right as AI began rapidly changing how software gets made. I was among the earlier developers to use it deeply. At first, obviously, for writing code, but I soon found the change went well beyond speed. Work that used to be handed across roles—design, copy, data analysis, operations—could now be carried, in large part, by one person, plus some tools I wrote myself. The range a single person could cover grew a lot at once.

This appealed to me, because I’d always believed traditional organizations carry heavy coordination costs. A requirement passes through many hands on its way from idea to product; each added role brings expertise, and also another layer of communication, handoffs, and lost information. If AI lets one person do what several used to, a lot of that coordination never needs to happen at all.

That’s what made me take the One Person Company seriously: for the first time, one person could carry a production process that used to need a small team, end to end. AI supplies the production capacity, the organization shrinks to its minimum, and coordination costs fall with it. At least for software, this was getting realistic.

Up to that point, I don’t think my judgment was wrong. The problem is the extra step I took without noticing: since one person can now build a good enough product, then as long as the product is truly good enough, users will eventually find it, and the business will slowly appear.

For a long time I genuinely believed that. On Christmas Eve 2025, at a dinner with a few peers, I was still enthusiastically explaining this “insight.”

Then the product was finished. The business did not appear.

At first I filed it under promotion. The product exists, there are no users, so go figure out how more people can see it: distribution channels, social media, content, store optimization, where the first users should come from. After a while, though, it felt increasingly like more than “promotion wasn’t done well.”

I was seeing a scene I knew well from my years inside companies: everyone earnestly doing their own part, often doing it well, while the whole thing quietly failed to hold.

I’d assumed that problem would disappear once I went independent. There was only me—no boundaries between engineer, product manager, and designer. I wrote the code, made the design, set the direction. Nobody was confining me to a local view anymore. It took me a while to see that a local view doesn’t need an org chart. I had simply handed myself a new role. As an engineer I’d been absorbed in writing code well; as a “product creator” I became absorbed in building the product well. Could the feature be simpler, the interaction smoother, the visuals more complete, should the user’s complaint be fixed today—each reasonable on its own, and genuinely enjoyable to do.

But why would a stranger ever see this product? Why trust it? Why stay after trying it? And once the first users came, where would the next ones come from? I hadn’t really worked any of that out, and it wasn’t going to fill itself in as the product improved.

What I had actually proven was that one person can increasingly build what used to take a team. “Being able to build the product” and “being able to run the business” are different things, and I’d taken the first as evidence of the second.

Looking back, that’s probably because “getting things built” sat in too important a place in my working life for too many years. It was the ability I leaned on hardest. Whether an idea can land is full of practical questions—can this be implemented, how should the system be designed, what do you do when it breaks, how do you tell which things aren’t as simple as they look—and being the person who reliably worked through them was real professional capital. I was proud of it.

It’s getting less scarce, though. At least for the kind of products I build, many problems that used to stop me don’t anymore. Unfamiliar technology can be picked up quickly; work that needed a specialist can now be done by me to a good-enough level.

To put it a little dramatically: a craftsman watching his craft lose value, unwilling to admit it, keeping telling himself the craft still matters.

It still matters, of course. It just looks less and less like the thing that decides the outcome first. The question is moving earlier: what to make, why make it, which of my judgments merely sound convincing to me, which are worth testing against reality. Those matter far more than they used to.

And AI makes these questions look especially easy to answer. Throw one in and you get a well-structured analysis back within minutes; press further and it supplies counterexamples, risks, cases, until the question appears thoroughly discussed. That feeling is dangerous, because it looks so much like having understood. I fall into it more and more easily myself.

But a complete explanation isn’t a true one by default. The context the model doesn’t know may be exactly the part that matters most; the industry’s usual playbook may not apply to you. Worse, if the question you started with was wrong, then the more complete the analysis, the more beautifully it explains the error.

Which leaves me caring about one distinction: answers have become very cheap. Understanding hasn’t.

And I don’t mean “AI doesn’t understand, humans do.” Humans run the same trap. My old picture of independent development was entirely homemade—coherent, well-supplied with reasons from experience—and so I stopped questioning it early. I took an explanation that sounded reasonable for something I understood.

Now, with questions like these, I want my judgments to bump into actual results sooner. If I believe a piece of copy makes the product clearer, change it and see if anything moves. If I believe a kind of content will bring users, publish it and see what happens. The results are often less tidy than the version in my head. That turns out to be more useful. Once you’re there, no amount of extra reasons can keep the judgment rounded off: nobody came means nobody came; users didn’t stay means they didn’t stay. At minimum you have to ask again where you went wrong earlier.

So I ask myself more and more often: does it really have to work this way? Not to argue with answers people already accept; defaults that survived until today usually survived for reasons. But it has started to feel wrong to skip the step of understanding why an answer holds just because it’s common. Under what conditions does it hold? Do those conditions still exist? If the conditions changed, should the answer change too?

I don’t know where this way of working leads. For now I’m a bit more watchful than before: the more complete an answer sounds, the less reason I have to stop early.

The OPC in Will.OPC currently stands for One Person Company. When I chose the name, I did believe the one-person company was an organizational form worth trying long-term in the AI era, and I still think it’s worth testing. I’m just no longer willing to treat it as an identity I have to defend. If it turns out working alone isn’t the best shape for me, then I won’t run a one-person company, and OPC can get a new explanation when that day comes. A name shouldn’t turn around and demand to be maintained.

This site will probably become something similar. It will hold the products I make, and also the parts that didn’t become products: why I started believing a judgment, what I did, what happened, why I changed my mind. The topics may be far apart. As long as each comes from something I genuinely want to figure out.

Looking back later, I’ll probably find a good number of these judgments were wrong. It took me more than a year to notice I’d taken a reasonable-sounding explanation for an understanding, and I’ll likely do it again. I just hope I notice a little sooner next time.

Answers change. The questions stay.