September 2026

Code got cheap.
Judgment didn’t.

Coding agents gave solo founders the ability to build almost anything. We think the harder question is now what deserves to be built.

Guillaume SimonNicolas Martin

In March 2014 a Dutch developer announced that he would launch twelve startups in twelve months, alone.1 It read as a stunt.

Twelve years later he still works alone, from a laptop, on a handful of products. One of them brings in more than a hundred thousand dollars a month out of a single very long PHP file. For the past year a coding agent has been editing that product directly on its production server, and, in his words, it keeps going all night while he sleeps.2

What looked like a stunt turned out to be a preview. The interesting part is not the twelve startups. It is that one person can now run several live products and find that the building is the easy half.

A wide valley at dusk, dozens of small cabins scattered to the mountains, each with one lit window.

What became cheap

Until recently, turning an idea into a product took real resources: engineers, money, time, or enough technical skill to do it all yourself. That constraint has loosened quickly. In October 2024 Google said a quarter of its new code was written by AI; by April 2026 it was three quarters.3 A quarter of Y Combinator’s winter 2025 batch had codebases that were 95 percent machine-written.4 For someone building alone, the amount of software you can produce in a week has changed by an order of magnitude.

Not every measurement agrees, and that is worth saying. A careful trial in mid-2025 found experienced developers were slower with AI on large codebases they already knew well, while believing they had been faster.5 We take that seriously. It also describes a different situation from the one we care about, which is a person with more product ideas than hours.

The change is visible in who starts companies. Solo founders were 63 percent of the companies formed on Stripe Atlas in the second quarter of 2026, an all-time high,6 and more than twice as many solopreneurs earned over a million dollars in 2025 as in 2023.7 That is exciting. It also creates a new problem.

Ten small wooden boats pulled up on a beach at dusk, a few more drifting out, a lantern at the end of a pier.

The bottleneck moved

A live product produces signals all day. Some users sign up and disappear. Others become surprisingly active. The same complaint turns up three times in support. A feature gets used far more than you expected. Conversion moves. Someone asks for something you had never considered.

None of those signals are hard to find on their own. The hard part is holding them together, working out which ones matter, and deciding what deserves your attention this week. In a product team that is a large part of what good product people do: they spend time with users, look at the data, challenge assumptions, connect signals that don’t obviously belong together, and slowly build a point of view about what to work on next.

A solo founder has to do the same work, except they are also writing the code, fixing the bugs, answering support, thinking about distribution and keeping the whole thing alive. So product decisions become reactive. You build the feature someone asked for yesterday. You fix whichever metric looks worrying. You follow the idea that felt promising this morning. Sometimes that works, but increasingly the limiting factor is not your ability to build. It is your ability to decide where to point it.

An empty bench on a cliff over a vast sea at dusk, ten sailing ships adrift far out in the haze.

III

A PM, not another product tool

Most product software helps you organise work you have already decided to do: a roadmap, a backlog, specs, dashboards, a feedback inbox. Those tools make sense when a group of people needs to coordinate. They are much less useful when you are alone and the real question is simply what to work on next.

There is a related trap in bringing traditional product management into very small companies. You end up recreating the artefacts of a large organisation without having any of the organisational problems they were designed to solve. A founder of one does not need a groomed backlog or a quarterly roadmap deck; those exist so that groups can agree with each other, and there is nobody here to agree with. What is actually scarce is attention. You have dozens of things you could improve and very little time to work out which one is worth doing.

So the idea behind Nano is to connect it to the places where your product already leaves traces — analytics, support conversations, payments, feedback, your codebase — and let it build an ongoing understanding of what is happening, instead of waiting for you to open a dashboard and ask the right question. It should work from the raw data you already have, and it should never begin by asking you to instrument your product first.

The empty wheel of a sailing ship at dusk, the open sea ahead, the compass lamp lit.

What a recommendation looks like

Say Nano notices that users who complete one particular step during onboarding are much more likely to come back. From there it can look at where other users drop out, read the support conversations that touch on it, check what changed in the product recently, and come back with something to do.

Not “activation is down 8 percent”, but “I think onboarding is the most important thing to work on right now — here is what seems to be going wrong, here is the evidence, and here is what I would try first.”

The second half of that matters as much as the first. A recommendation you cannot interrogate is worth very little, so every one should carry its reasoning, its sources and its date, and should be easy to argue with. Sometimes the answer will be a feature. Sometimes a small change to a screen. Sometimes it will be to fix reliability, interview five users, or do nothing yet because the evidence isn’t strong enough. The point is not to generate more work. It is to make better decisions about the work.

We also don’t think founders will hand an AI full control of their product, and we don’t think they should. Nano starts by observing and proposing. As it proves useful, some of that can become more autonomous: looking into a drop in conversion without being asked, running interviews around a specific question, briefing your coding agent on a small, well-defined change for you to review. Different people will draw that line in different places, product by product and action by action. It should be earned through useful decisions rather than assumed on day one.

A lighthouse sweeping its light over a calm harbour at dusk, boats moored in rows below.

A different kind of software company

What makes us most interested in this is not really product management. It is what happens when one person has access to capabilities that used to require a team.

Coding agents have already changed the economics of building. Design, research, support and marketing will follow in their own ways. That doesn’t mean every company becomes a one-person company, but it does mean one person can go much further before they have to become an organisation. A founder might run several products instead of one. A niche too small to justify hiring a team becomes a perfectly good business. Someone with deep knowledge of an industry and no engineering background can build software for it.

In that world, writing the code is only part of the job. The harder part is deciding where to point all that new capacity. And the product you are not looking at this week is usually the one that needs you.

The whole point is that you get to look away.

That is why we are building Nano. It is steering its first product now. If you build alone, or nearly alone, and this sounds like your week, we would like to hear from you.