AI lets a solo founder produce a product, but it can’t help them understand whether that product is actually good…yet. That expertise, the hard-won judgment underneath it, has always been what decides who wins and who quietly (or epically) fails.
There’s a movement in the startup world that currently claims if you can’t build your product by yourself, with AI, you shouldn’t be building it at all. The “advice” suggests that a solo founder should handle coding, design, and marketing with AI and should not hire a traditional team at all.
Hiring someone to design or engineer your product, whether it’s an agency, a contractor, or an early employee, is treated as proof you don’t really understand your own product and a growing number of investors won’t back a founder who would do that.
Most founders are doing exactly what they’ve been told works, and often they don’t know any better. The idea that needing help is a weakness sets a tone that will eventually backfire because most people are not unicorns, because unicorns do not exist.
Paul Graham, who founded Y Combinator, has said for years that he prefers founders who can build the thing themselves. Carles Reina, an early backer of ElevenLabs, told CNBC his first instant red flag is a founder who “literally cannot build products.” More than a third of new startups are now solo-founded, because AI made it possible to go from idea to working product without the people who used to be required.
Buried in that whole position is an assumption that’s dangerously misguided. It assumes that because you can now produce the thing, you have the expertise to know whether the thing is any good. Those have never been the same thing.
AI collapsed the cost of making something to almost nothing, but it did nothing to impact the cost of judgment, the years of studying how people behave, what makes a product feel trustworthy.
We got product creation for free, but forgot that expertise didn’t come with it.
Being able to vibe-code an app over a weekend makes you an expert in exactly one thing. Can you guess? It’s in vibe-coding an app over a weekend.
I lean on these tools as hard as anyone, on fast, super AI-heavy schedules that pressure test the technology every day. Even at that speed, it’s obvious how often what comes out is close but not right, and how often it takes real experience and hard-won knowledge to catch the difference and make the call.
None of this is a knock on the founders who build a product themselves. Seriously, kudos to them. A founder who vibe-codes their idea into something real is doing something genuinely good, they’re getting what’s in their head out into the world, fast, and that has always been the hard part.
The trouble starts when the people funding them treat that first draft as the finished product, and think asking for help is a weakness.
AI moves the thinking rather than removing it. The people cheering the death of the expert have confused two different things, making what you asked for, and knowing whether what got made is any good.
Where they’re right
Dario Amodei, the CEO of Anthropic, the company behind Claude, has said he thinks the first billion-dollar company run by a single person could arrive as soon as 2026, and he put the odds at something like seventy to eighty percent. He has an obvious stake in that being true and his company creates tools that would make it possible, but nevertheless, the prediction could be realistic.
Venture capitalist and Harvard Business School professor, Jeff Bussgang, has described the same shift from the investing side, right down to a betting pool among his tech-CEO friends over the year the first one-person billion-dollar company shows up.
The cost of producing software, a brand, a marketing campaign, a working prototype, has fallen through the floor. A founder with the right AI stack can now do in a weekend what used to take a team a quarter.
Andreessen Horowitz says that building has gotten so cheap that founders now skip the questions they used to have to answer first. Their Speedrun team’s perspective is that the interesting question is no longer “can you build it,” because the answer is now always yes. The interesting, and perhaps more important question is “should you,” which is what it’s always been. Marty Cagan has been telling product teams for decades that the job is to ask not just whether you can build the thing, but whether you should build it at all.
When making the thing is nearly free, the discipline shifts from execution to judgment about what deserves to exist at all.
The money has unsurprisingly moved accordingly. At TechCrunch Disrupt, seed investors including Elizabeth Yin urged early-stage founders to lean on AI coding leverage as much as they can, and Renata Quintini of Renegade Partners agreed it’s the right move for finding product-market fit, rather than spending early cash on headcount they don’t yet need.
Rebecca Lynn points out that it’s never been easier to stand up a company “in demo mode,” which is exactly why she’s careful about what she funds.
The thing these investors are reacting to is that a lot of the roles that used to be mandatory at the start of a company are now optional, or at least deferrable.
Startups have a long history of getting too big, too early. The Startup Genome Report, which analyzed more than 3,200 startups, found that premature scaling, hiring too many people too soon is the single most common reason startups fail.
Starting with a small team is generally smarter, but a founder who can build the first version themselves, who understands the problem because they live it, who doesn’t need to hire a translator to turn their idea into a thing, has a real and durable advantage.
The clearest case is the technical founder building for people exactly like themselves, the engineer making tools for engineers, who is both the builder and the user and genuinely doesn’t need anyone in between.
The trend is shifting to the founder building it alone, but the reality is they often shouldn’t.
Travis Howell and Todd Hall looked at whether solo founders can hold their own against co-founded teams, and found that they can, under one condition, when the solo founder has deep, broad experience to draw on.
It works when the founder’s real expertise is in building the thing, the craft, the risks, the details that make a product good, not just in the problem it solves. A technical founder building for engineers can do it, because what they know maps onto what the product needs.
Knowing an industry cold, or a market, or a customer, is valuable, but it is not the same as knowing how to build something people want to use.
Right now, the industry keeps confusing the two. Thinking a tool will fix it is just foolish.
Telling a founder that reaching out for help, from someone who could genuinely add qualified perspective or experience, is a red flag gets it backwards. It punishes a person for not personally holding every bit of knowledge a company needs, which is a bar no real human should be held to.
Eight people in a conference room
On a Saturday morning in 1999, five of us met at iXL’s offices in Manhattan’s Union Square to stage a quiet coup. We picked the day on purpose. The place was empty, no account directors, really nobody around to hear what we were about to do. Just us gathered around a table voluntarily sequestered in a conference room to discuss a project we thought we could save by making it smaller.
iXL was one of those agencies that got enormous by swallowing other agencies, which is what was common during dot-com 1.0. Agency size wasn’t a virtue or a sin, it was just the reality of the industry. The project we were on had at least forty people attached to it, with one of the largest budgets in the company, and it was sinking under its own weight.
There was too much process, too many people who had to be looped in before decisions could be made, a launch date that kept on sliding.
This wasn’t a new phenomenon (not that I knew that at the time). In 1975, computer scientist Fred Brooks watched IBM try to rescue a late software project by adding programmers, and watched it get later. He turned it into Brooks’s Law, which says that adding people late to a project just makes it even later.
It’s a brutal, mathematical reality. As you add people, each new person you add has to be brought up to speed, which pulls the people who already know what they’re doing away from the work. Every new person adds a communication line to every other person, so the coordination cost climbs faster than the output does.
Forty people don’t move four times faster than ten. They move slower, they cause blockers left and right, but they feel busier doing it.
We wanted to cut the team to eight, with severe focus. Eight specialists, each the best in the building at one specific thing. The cast list we wanted:
- A front-end developer
- A couple of back-end developers
- A project manager
- An information architect (which is what you called a UX designer back then)
- An art director
- A creative director
- A designer
The premise wasn’t to fire the other forty members of the team. They’d have plenty of work to do on what was next on the roadmap, but to actually ship this thing, we needed the smallest possible group of people who each could use their expertise to collaborate and move this forward smarter and faster.
Years later, Amazon would make this famous as the two-pizza team, Jeff Bezos’s rule that no team should be bigger than two pizzas can feed, somewhere around ten people, because that’s the size that stays fast.
I was twenty-three. I was nowhere near the most senior person in that room, though I was somehow the most senior information architect on the project in all of New York, which should tell you how little a title and actual expertise have to do with each other.
I was also, for the record, a bit of a troublemaker, which is how you end up in an empty office on a Saturday trying to shrink your own project by eighty percent. We wrote the plan, we walked our account director through it, and somehow he said yes.
Then we had to go do it, and we did.
That little team became a precision instrument the company reached for whenever something hard had to get built fast, and I’m confident it made them a lot of money.
As for the giants that were busy getting bigger, most of them did not make it. iXL shrank drastically. MarchFirst, the largest of these roll-ups, a nine-thousand-person, six-billion-dollar web consultancy, burned through a billion and a half dollars in fourteen months and filed the biggest bankruptcy in the industry’s history.
The whole sector contracted by seventy to eighty percent. Being huge turned out to be the most expensive way to be fragile.
That is all to say, the idea of small, nimble teams is rarely a bad idea, so when a venture capitalist says a founder doesn’t need forty people, I can’t argue with that.
The thing to understand is the strategy of what we did in that room, because that is not the argument for the solo founder show being encouraged today.
We cut forty people down to eight experts. The pitch today is to cut it down to one founder and a tool. Those may sound similar, but one of them concentrates expertise, while the other removes it and hopes the software quietly fills the hole where it used to be.
Patrick Neeman argues that in the age of AI, when anyone can stand up the same model and the same features, the thing that sets your product apart is the experience and the judgment built around it. You own what differentiates you, the workflows, the design, the taste, the deep understanding of your user, and you buy or borrow the commodity underneath.
The mistake in the solo-founder pitch is assuming the tool handed you the part that differentiates. All it really handed you was a commodity.
Ethan Mollick, who is about as bullish on AI at work as anyone, insists that AI rewards expertise. It lets the people who already know what good looks like judge the output, catch the confident mistakes, and push the tool past its defaults, while everyone else takes whatever the machine hands them.
The AI builds you a slick dashboard and never thinks to ask what it looks like before there’s any data in it, or when something breaks. It gives you a clean screen with light gray text on white, and someone who knows catches that a lot of your users can’t read it. That stuff only gets caught when someone with real experience is deciding whether it’s actually done or even takes the time to ask the AI to review it.
Tao An, a researcher at Hawaii Pacific University, lays out the split cleanly, saying that on routine work, AI lifts a beginner up to a competent floor, which is real and useful. On the hard, judgment-heavy work, however, the kind that decides whether a product is actually good, it does the opposite. It widens the gap between the person who knows what they’re doing and the person who doesn’t, because only one of them can tell when the confident-looking answer is wrong.
The tool amplifies the expertise in the room. It does not supply it.
At the end of the day, this comes down to one thing: the expertise has to be in the room. An employee, a contractor, a cofounder, a partner, or you, if you genuinely have it. Assemble it however you want, and keep the team as small as the work allows. The tool will make almost anything you ask it to. What it cannot do is tell you whether the thing is any good. That part has always belonged to the people who know, and it still does.
The thing you can’t prompt
In 1986, Steve Jobs needed a logo for NeXT, the company he started after being pushed out of Apple. He hired Paul Rand, probably the most famous graphic designer alive, and asked him for a few options to choose from. Rand said no. He would solve the problem, he told Jobs, hand back a single answer and Jobs could take it or leave it.
He charged a hundred thousand dollars. He came back with one design, a black cube tilted at twenty-eight degrees, presented in a bound book that walked Jobs through every decision, why the word, why the lowercase “e,” why the angle, until the logo felt less like a choice and more like the only possible conclusion.
Jobs, who genuinely had plenty of taste himself, paid six figures for something he couldn’t produce on his own. Whatever was in his head, he could have generated a thousand tilted cubes before lunch, but the reasoning underneath that piece of design derived from years of accumulated judgment that let Rand know, with total confidence, which single answer was right and why.
This is the gap the whole “just build it yourself” argument ignores. Producing the deliverable (whatever it may be) and knowing whether the deliverable is good are completely different skills.
Right now, you can easily generate a logo, a landing page, an entire app, in an afternoon. What you cannot necessarily do is hold the judgment to look at what came out and know that the hierarchy is off, that the flow asks too much of a tired person, that the tone is wrong for the people you’re trying to reach, that the confident, finished-looking thing on your screen is quietly, expensively broken or costing you customers.
Christian Holst found that the average checkout asks for around eleven form fields when most need eight, and that nearly one in five people abandon a purchase simply because the process felt too long. In testing, cutting a form from eleven fields to four lifted completions by 120 percent. The tool that built you that form has no idea it’s costing you customers.
AI makes everything it spits out look “good.” It can be clean, modern, professional, but that’s not always a perk. It’s also pulling from the same places everyone else is pulling from. When everyone builds with the same tools, trained on the same examples, everything starts to look the same.
Aurelie Radom suggests that AI may not have democratized design judgment, but it did democratize output, and when the models are all trained on the same stuff, the output space compresses and products that have nothing to do with each other start converging on the same shapes and the same layouts.
Alwin de Rooij and Michael Mose Biskjaer compared nineteen studies around this and found the effect is real and very measurable. The more people lean on the same AI, the more their work converges, which means looking finished and modern is fast becoming the least distinctive thing a product can be.
Looking finished used to mean something, odds were decent that someone who knew what they were doing added a contextual lens. That’s not true anymore. AI gives you the finished look in seconds, whether or not a single smart decision went into it.
Humans, it turns out, are built to fall for this distraction. In 1995, Masaaki Kurosu and Kaori Kashimura put a set of interface layouts in front of people and found the better-looking ones got rated as easier to use, even when they flat-out weren’t. They called it the aesthetic-usability effect.
We see something attractive and our brain quietly decides it works.
AI produces attractive by default, which means it produces trust it hasn’t earned because the thing it created looks great, you believe it’s good, but there’s no proof it actually will work.
Fabrizio Dell’Acqua, Ethan Mollick, and their colleagues studied 758 consultants and found that on the tasks AI is bad at, the ones who relied on it did worse than the ones who didn’t. The AI gave them wrong answers that looked right, and the people who couldn’t tell the difference used them anyway.
Separately, Yue Liu and colleagues studied a large batch of AI-written code and found it full of quality and maintainability problems hiding under a finished surface.
This isn’t a secret in our field. Nicole Alexandra Michaelis calls it the “taste paradox,” where we all agree that knowing what’s good is the skill that matters most now, and we’ve built a way of working that keeps people from ever learning it. The more you lean on AI to tell you what works, the less you ever figure out how to tell on your own.
Ruiqi Zhou adds a business lens to this, saying that if everyone can make the same thing, making it isn’t an advantage anymore. The only thing still worth anything is the judgment to know what’s worth making.
The receipts
This isn’t an emotional argument about how things look. The numbers back it up. The business value of expertise is one of the most heavily documented things in product, and the data got sharper once AI showed up.
Hyunso Kim, Hyo Kang, and Jaeyong Song studied more than 160,000 product launches on Product Hunt, before and after ChatGPT arrived, and found that after AI showed up, solo launches spiked, especially in categories that used to require a team, but when they looked at quality, at which products actually reached the top tier, teams still dominated, as much as ever.
AI widened the door for solo entry and did nothing to close the quality gap. More things got made. The good things still came from the people with the expertise to make them good.
The money follows the same pattern. First Round Capital studied a decade of its own portfolio and found that companies with more than one founder outperformed solo founders by 163 percent, raised more, and grew faster, an advantage they tie directly to complementary skill and the sharper decisions it produces. Their data says the opposite of their advice.
That’s not a nostalgia story about the pre-AI days. Boston Consulting Group found that the companies leading in AI, the ones it calls “future-built,” are outgrowing their competitors by 1.7 times in revenue and 3.6 times in shareholder return.
These winners used real expertise to aim the new tools and didn’t just buy the tools to replace the expertise.
Benedict Sheppard, Hugo Sarrazin, Garen Kouyoumjian, and Fabricio Dore scored hundreds of companies on how seriously they treat design, then tracked their results over five years. The ones that took design most seriously grew revenue about a third faster than the ones that didn’t, and returned more than half again as much to their shareholders.
The same research shows why those winners are so rare. More than forty percent of companies still don’t talk to their users while they’re building, and over half have no real way to tell whether their own team’s work is any good.
Taking design seriously is what separates the winners from everyone else. Taking design seriously means being able to judge whether your design is actually working. Most companies can’t or just don’t.
If most companies can’t tell good design from bad in the first place, then of course they’ll believe AI made them something good. They have no way to know it didn’t.
Judgment is not the same as one powerful person’s gut, and the answer to “the tool can’t decide for you” is not “so let the loudest opinion in the room decide instead.” In 2009, Google’s lead designer Doug Bowman quit and explained why in a post called “Goodbye, Google.” The company, he wrote, couldn’t choose between two shades of blue, so it tested forty-one.
He’d been asked to prove, with data, whether a border should be three, four, or five pixels wide. That’s the opposite mistake, and it’s just as bad. When no one on the team can just say “four,” you test everything, because nobody has the expertise, trust or standing to make the call.
Real expertise is knowing which decisions you can settle and move on from in a second and which ones actually need testing.
Build small. Just bring the expertise.
Rick Rubin has produced some of the most important records of the last forty years, across rock, rap, country, and pop, with artists such as Johnny Cash, Jay-Z, the Red Hot Chili Peppers, and Adele.
When Anderson Cooper asked him, on 60 Minutes, whether he could play instruments or work a soundboard, Rubin said no. “I have no technical ability,” he said. “And I know nothing about music.”
Cooper, reasonably, asked what he was being paid for. Rubin’s answer sums up why an expert lens matters. He said, “The confidence that I have in my taste and my ability to express what I feel has proven helpful for artists.”
He can’t compose the tracks himself, but he is one of the most sought-after people in music anyway, because composition isn’t always the point. Judgment is.
The ability to sit with a thing and know, with conviction, what it needs and what’s getting in the way is the rarest and most valuable thing in any creative endeavor. It is exactly the thing that does not reside in a tool, no matter how good the tool gets.
The people telling founders they don’t need anyone but themselves and AI are half right in a way that matters. You certainly don’t need forty people. You may not even need ten. It’s fair to say that the bloat they’re concerned about is real, and killing that is good, but they’ve taken a true thing about team size and turned it into a false thing about expertise.
Fewer people, yes. Less expertise, no.
Right now, AI gives you the output of expertise without the expertise. It hands you the artifact a skilled person would have made, without the judgment that skilled person would use to know whether the artifact is any good.
That gap is real today, and it is real for the foreseeable future, though I won’t pretend to know how long “foreseeable” lasts. Maybe the models close it, maybe judgment turns out to be the last thing to automate.
Either way, you have to build in the world you’re actually in, and in this one, AI can make the thing, but it cannot tell you if the thing is good.
Founders actually doing this are the first to admit where it breaks. Anik Devaughn, who built an AI-native commerce platform largely by himself, said that founders who understand their business deeply can move faster and stay smaller, but the ones who can’t evaluate the work will just automate bad decisions.
Basically, if you’re a founder talking to an investor who says they won’t back anyone who hires help, the investor is missing the point.
A founder who can tell the difference between what’s working and what isn’t is a far safer bet than one who can only tell you the demo they put together looks great.
This is not an argument for hiring an agency, or hiring anyone in particular. It’s an argument for embracing the expertise that has to be there to create success. It can be an employee or a contractor, a cofounder or a partner, or you, if you’ve genuinely put in the years.
NYU Professor J.P. Eggers ran an experiment where MBA students used AI agents to build startups from scratch. The AI was good at discrete tasks and fast brainstorming, he found, but it couldn’t replace the judgment that comes from having real specialists in the room.
His line for what happens without them sums up a lot, saying “You’re kind of taking it on faith that what the AI is producing is pretty good.”
Assemble the smallest team you can. Keep it lean enough to move fast, and make sure someone on it can tell what’s right from what’s broken. AI can build anything. Knowing if it’s right takes a human.
AI or not, it all falls apart without someone who actually knows what they’re doing.
Anyone who treats a founder’s willingness to bring in that person as weakness has it backwards. A founder who knows what they don’t know, and goes and gets the help, is the one worth betting on.
References and further reading
The belief that you should build it yourself
- Diana Bocco, AI Is Letting Solo Founders Build Startups Without Hiring (Inc.). The solo-founder-with-AI movement in the founders’ own words, including the line that founders who can’t evaluate the work just automate bad decisions.
- Paul Graham, How to Start a Startup. The Y Combinator view that the best ideas are the ones founders can build themselves.
- Carles Reina (CNBC). The ElevenLabs backer on why a founder who “literally cannot build products” is an instant red flag.
- The State of Solo Founding (Carta data). More than a third of new startups are now solo-founded.
Where they’re right
- Dario Amodei (Inc.). The Anthropic CEO’s prediction of the first one-person billion-dollar company by 2026.
- Jeff Bussgang, AI and the Dawn of the 10x Founder. A VC and HBS professor on the same shift, and on AI multiplying expertise rather than replacing it.
- a16z Speedrun, The Idiot Index for Code. Building got so cheap that the real question moved from “can you?” to “should you?”
- Elizabeth Yin and Renata Quintini (TechCrunch). Seed investors on leaning into AI coding leverage at the earliest stage.
- Rebecca Lynn (via MLnotes). On how easy it is to stand up a company “in demo mode,” and why that makes her cautious.
- Startup Genome, Premature Scaling. Across 3,200+ startups, scaling too fast, hiring too many too soon, is the most common reason startups fail.
- Travis Howell and Todd Hall, Lone Genius or Lonely Fool? (Strategic Management Journal). Solo founders can hold their own, but only when they personally carry deep, broad expertise.
- Marty Cagan, Product Management: Start Here (SVPG). Decades of arguing that the job is to ask not just whether you can build it, but whether you should.
Small teams and the strategy of focus
- iXL and MarchFirst (Unicorn Burn). The dot-com roll-up giants that grew huge and collapsed; MarchFirst burned through $1.5 billion in fourteen months.
- Fred Brooks, Brooks’s Law. Adding people to a late project makes it later, because coordination cost climbs faster than output.
- The Two-Pizza Team. Jeff Bezos’s rule that the fastest teams are small enough to feed with two pizzas.
- Patrick Neeman, Buy Versus Build Is Now a UX Decision. Own the experience and judgment that set your product apart; buy or borrow the commodity underneath.
- Ethan Mollick, The Cybernetic Teammate. AI rewards expertise: the people who know what good looks like get the most out of it.
- Tao An (arXiv). On routine work AI lifts beginners up; on hard, judgment-heavy work it widens the gap between those who know and those who don’t.
Why output is not expertise
- Christian Holst, Baymard Institute. The average checkout asks for more form fields than it needs; trimming them can lift completions by 120 percent.
- Masaaki Kurosu and Kaori Kashimura, the aesthetic-usability effect. People rate better-looking interfaces as more usable, even when they aren’t.
- Aurelie Radom, AI Made Everyone a Creator, Not a Designer. AI democratized output, not design judgment, so products that have nothing to do with each other keep converging on the same shapes and layouts.
- Alwin de Rooij and Michael Mose Biskjaer, Does Generative AI Make Us Think Alike? A review of nineteen studies finding a real, measurable homogenization effect: the more people lean on the same AI, the more their work converges.
- Fabrizio Dell’Acqua, Ethan Mollick, and colleagues (Harvard Business School). On tasks AI is bad at, consultants who leaned on it did worse, because it produced wrong answers that looked right.
- Yue Liu and colleagues (arXiv). A large study of AI-written code found it full of quality and maintainability problems beneath a finished surface.
- Nicole Alexandra Michaelis, The Taste Paradox. Everyone agrees judgment is the skill that matters most, and the current way of working keeps people from ever building it.
- Ruiqi Zhou, Taste Is the New Moat, and That’s the Problem. If everyone can produce the output, the only thing left with value is the judgment to direct it.
The receipts
- Hyunso Kim, Hyo Kang, and Jaeyong Song (arXiv). Across 160,000+ Product Hunt launches, AI boosted solo entry but quality still concentrated in teams.
- First Round Capital, The 10-Year Project. Companies with more than one founder outperformed solo founders by 163 percent.
- Boston Consulting Group, Build for the Future. Companies leading in AI outgrow competitors by 1.7x in revenue and 3.6x in shareholder return.
- Benedict Sheppard, Hugo Sarrazin, Garen Kouyoumjian, and Fabricio Dore, The Business Value of Design (McKinsey). Companies that take design seriously grow faster, and most companies have no objective way to judge their own work.
- Doug Bowman, Goodbye, Google. The designer who left after being asked to prove, with data, which of forty-one shades of blue to use, the opposite failure: measurement used to avoid judgment.
The close
- Rick Rubin (60 Minutes). The producer who can’t play an instrument, and whose entire value is the confidence of his taste.
- J.P. Eggers (Fortune). The NYU experiment where AI agents built startups, and the judgment that was missing without real specialists.
A founder with a tool is not a founder with a clue was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
