There are two reasons founders resist going out and recruiting users individually. One is a combination of shyness and laziness. They'd rather sit at home writing code than go out and talk to a bunch of strangers and probably be rejected by most of them. But for a startup to succeed, at least one founder (usually the CEO) will have to spend a lot of time on sales and marketing. The other reason founders ignore this path is that the absolute numbers seem so small at first. This can't be how the big, famous startups got started, they think. The mistake they make is to underestimate the power of compound growth.
Almost all startups are fragile initially. And that's one of the biggest things inexperienced founders and investors (and reporters and know-it-alls on forums) get wrong about them. They unconsciously judge larval startups by the standards of established ones. They're like someone looking at a newborn baby and concluding “there's no way this tiny creature could ever accomplish anything.”
The big danger is that you'll dismiss your startup yourself. I've seen it happen. I often have to encourage founders who don't see the full potential of what they're building.
I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.
Sometimes the right unscalable trick is to focus on a deliberately narrow market. It's like keeping a fire contained at first to get it really hot before adding more logs.
Any startup that could be described as a marketplace usually has to start in a subset of the market, but this can work for other startups as well. It's always worth asking if there's a subset of the market in which you can get a critical mass of users quickly.
Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be a little frightening to be solving users' problems in a way that wasn't yet automatic, but less frightening than the far more common case of having something automatic that doesn't yet solve anyone's problems.
But with GPT-assisted coding, I think we’re in an era where you can just stop after the first part. You can do something that doesn’t scale — and leave it that way. That might actually be the best version of it. I don’t feel the pressure anymore for every project to be “a business.” If it works for me — or a tiny circle of people I care about — that’s enough.
Some things work precisely because they’re small. See a need that matters to you. Build the smallest, simplest thing that solves it. Resist the urge to make it bigger. Enjoy it. Scaling used to be the point. Now, small can be the point. AI tools make it cheap to create software for an audience of one — and sometimes, that’s the best possible audience.
It’s the freedom to stop. To make something small, useful, and perfectly yours, and not feel obligated to grow it until it collapses under its own weight. In a world obsessed with scale, there’s a quiet satisfaction in leaving good enough alone.