The Builders Already Building
Real stories of solopreneurs and small teams building million-dollar products.
The Builders Already Building
"The best time to plant a tree was twenty years ago. The second best time is now."
— Chinese proverb
I started paying close attention to solo founders about two years ago, not because I was looking for inspiration but because the pattern became impossible to ignore.
Danny Postma is the example I come back to because it's so clean. He's a designer from the Netherlands who noticed that people needed professional headshots but didn't want to pay a photographer or spend an afternoon in a studio. He built HeadshotPro — an AI tool that generates professional headshots from a few ordinary photos — alone. No co-founder. No employees. No investors. He reached a million dollars in annual recurring revenue in less than a year.
That story, by itself, could be an outlier. Except it's not. Seth Kramer built PDF.ai — a tool that lets you chat with PDF documents — following essentially the same pattern. One person. One specific problem. Real customers paying real money. Pieter Levels, who's been building in public for years, operates multiple profitable products simultaneously, all solo, generating well over a million dollars annually from tools like RemoteOK and NomadList and PhotoAI. Marc Lou ships a new product roughly every month, some of which work and some of which don't, and his aggregate revenue grows regardless because each attempt costs him almost nothing and each success compounds.
These are not venture-backed companies. They don't have pitch decks or boards of directors or Series A announcements. They have customers. They have revenue. They have an audience that watches them build and tries what they ship.
I've been looking for the thing they share — the common element across the builders who are actually making this work. It's not technical skill, though some of them are technical. It's not industry experience, though most of them have domain knowledge in whatever they're building for. It's not age, geography, or educational background. Danny is a designer. Seth is a product thinker. Pieter started as a digital nomad who learned to code. Marc ships so fast that his technical skill is almost secondary to his speed of iteration.
The thing they share is this: they found a specific group of people with a specific problem, and they built the specific thing that solves it.
That sounds obvious. It's not obvious. Most people who think about starting a business think about markets, not people. They think about industries, not problems. They think about scale before they think about utility. The builders who are working right now did it the other way around. They started with a person — sometimes literally a single person they knew who had a specific frustration — and built outward from there.
Danny's insight wasn't "the AI headshot market is large." His insight was "my friend needs a headshot and doesn't want to deal with a photographer." Seth's insight wasn't "the document AI market is growing." His insight was "I keep needing to find specific information in long PDFs and it's annoying." The market analysis came later, if it came at all. The starting point was a felt problem.
There's a number that keeps striking me: 29.8 million. That's how many businesses in the United States operate without a single employee. Eighty-four percent of all US businesses. Together, they generate $1.7 trillion in revenue — about 6.8% of total US economic output. And that was before the current generation of AI tools made it meaningfully easier to operate at that scale.
These aren't all tech companies. They're consultants, freelancers, creators, coaches, tutors, designers, photographers, writers, therapists, accountants, and a thousand other categories. What they share is that one person is producing enough value for enough other people to sustain a living. Often a good living. Sometimes an extraordinary one.
What I find revealing about this number is what it implies about the relationship between capability and organization. For most of the industrial era, producing at scale required organization — the coordination of multiple people doing specialized tasks. A software company needed engineers, designers, product managers, marketers, salespeople, customer support. The overhead of coordination was the price of capability.
The AI leverage shift is collapsing that relationship. A single person with the right tools and the right judgment can now perform functions that used to require five to eight people. Not every function. Not at the same quality level across all of them. But well enough to ship, well enough to serve customers, well enough to generate revenue that sustains and grows.
Dario Amodei — the CEO of Anthropic, which builds Claude — made a prediction in early 2026 that I think about often. He said the first solo AI-powered unicorn — a company worth a billion dollars built by a single person — could emerge by the end of 2026. A year ago, that prediction would have sounded absurd. Now it sounds like a timing question, not an if question.
Let me describe what a day looks like for someone building this way, because the abstraction hides something important.
I know a woman — I'll call her Sarah, though that's not her name, because she hasn't gone public yet — who left a product management role at a mid-size SaaS company eight months ago. She didn't leave because she was unhappy. She left because she noticed something that bothered her: the work she was doing to justify her salary was shrinking. Not because she was bad at her job. Because the tools her company was adopting were making chunks of her role unnecessary. She could see her own position being optimized away, and she decided she'd rather be on the building side of that optimization than the receiving side.
She spent two weeks talking to people she knew in the healthcare administration space — a domain she understood from a previous role. She asked them what frustrated them. Three of them described variations of the same problem: coordinating patient referrals across different electronic health record systems was tedious, error-prone, and consumed hours of manual work weekly.
She built a prototype in ten days using Claude Code and Cursor. Not a finished product — a prototype. A thing that worked well enough to show people. She showed it to the three people she'd talked to. Two of them said they'd pay for it immediately. One of them introduced her to four colleagues who had the same problem.
Eight months later, she has forty-two paying customers, $14,000 in monthly recurring revenue, and a product roadmap driven entirely by what her customers tell her they need next. She works alone. Her total investment to get here, not counting her time, was about $200 in software subscriptions.
That story is not exceptional. It's not even particularly dramatic. What makes it significant is how ordinary it's becoming.
The builders I keep watching share another trait that I think is underappreciated: they're comfortable with imperfection.
This might sound like a minor personality observation. It's not. It's structural. The old model of building a business — write a business plan, raise capital, spend months developing, launch big — required perfection because the cost of iteration was high. If your product didn't work when you launched, you'd burned through your runway. The new model — build fast, ship fast, learn fast — requires the opposite. It requires the willingness to put something imperfect in front of real people, because the feedback from those real people is worth more than any additional week of polishing.
Marc Lou talks about this openly. He ships products that aren't finished. Sometimes they have bugs. Sometimes the design is rough. But they work, and they solve a real problem, and the people who have that problem don't care about the rough edges — they care about the solution. The feedback from those first users tells Marc what to improve, what to add, and sometimes what to abandon. The imperfection isn't a flaw in the process. It's the process.
I've noticed that the people who struggle most with this are the ones who come from corporate environments where polish was expected before anything was shown. They've been trained to believe that shipping something unfinished is unprofessional. In the context of a large organization with a brand to protect, that instinct makes sense. In the context of a solo builder trying to find product-market fit, it's debilitating.
The market doesn't reward perfection. It rewards relevance. And relevance is something you can only discover by putting something real in front of real people.
There's one more thing the builders share, and it connects to something deeper than tactics or tooling. They think in terms of assets, not income.
When Sarah builds a feature for her referral coordination tool, she's not just serving her current forty-two customers. She's building an asset — a piece of software that will continue to serve customers tomorrow, and next month, and next year. When she writes a blog post about healthcare interoperability challenges, she's not just marketing. She's building another asset — a piece of content that will attract people who have the problem she solves, for as long as that problem exists.
This is a fundamentally different orientation than employment provides. In employment, you trade time for money. When you stop trading time, the money stops. There is no accumulation except in your skills, and your skills belong to a market that's being repriced.
Building means creating things that accumulate. Things that compound. Things that work while you're asleep, or learning, or building the next thing. The distinction isn't romantic — it's mathematical. And it leads somewhere worth exploring carefully.
Next: What You Own — the difference between income and assets, and why it matters more now than it ever has.