"Do things that don't scale" is outdated

Just build it. The trade-off was always the cost to build against the cost of being wrong: building used to be expensive, which made being wrong expensive, which is why you validated by hand first. Build cost is now about a tenth of what it was, so being wrong is cheap. You build it, you test it live in market, the signal is higher confidence because it is a real product, and if it wins you already have it built.

Just build it.

I hear founders quote the YC line every other week, usually to justify a manual slog. Too bad it's outdated.

Not the instinct behind it. The instinct is still right, and I'll come back to it. It's the default that's wrong, because the thing the advice quietly depended on isn't true anymore.

The equation the advice was built on

There is one trade-off underneath all of this, and almost nobody writes it down.

The cost to build it, against the cost of being wrong.

That is the whole decision. Every version of "should we validate this first or just make it" is that ratio, and the reason the answer flipped is that one side of it moved by an order of magnitude while the other stayed where it was.

I would go further than "the advice is outdated." I would argue it inverts.

Why the rule was right: building was expensive, so being wrong was expensive

Manual processes genuinely were faster for learning, and the equation is why.

Shipping code took weeks. Prototyping meant engineering resources you did not have as a small team, and every hour of eng time spent on a test was an hour not spent on the product. Build cost was high. Which meant the cost of being wrong was high, because being wrong meant burning weeks of the scarcest thing you had on something you then threw away.

When the cost of being wrong is that high, you buy insurance against it. That is what the manual work was: a ton of user research and hand-run processes, concierging the service, faking the backend, running it out of a spreadsheet, all so you could avoid paying the build cost until you were sure. You learned the problem while you did it, and you learned it faster than a build would have taught you.

That was good advice. It fit its era exactly, because it was the right answer to the equation as it stood.

What changed: build cost fell by about a tenth, and took the other side with it

You can build the real thing now, in an afternoon.

With Lovable, Framer, and AI in the loop, I can stand up a real product experience in hours. Not a fake manual stand-in. The actual thing, with a real interface, real flows, and real data moving through it. The cost to build is roughly a tenth of what it was.

And because the cost of being wrong was always downstream of the cost to build, it collapsed too. That is the part that actually changes your behavior. Being wrong is now cheap. So you just build it, and you are fine with being wrong, because you test it.

That also flips the economics the rule was built on. The scalable path used to be the slow one, which is the entire reason the rule existed. Now it's often the fast one.

So the question changed

It isn't "manual or scalable" anymore. It's this: what's the fastest route to a learning you'd actually bet on?

That second half is the part people skip, and it's the part that does the work. Fast is easy. Fast to a learning you'd act on is the real bar. I've watched teams run a manual test in two days, get a clean-looking result, and then change nothing, because deep down nobody believed the signal. That isn't a fast learning. That's two days.

So before you pick the method, say out loud what would have to be true for you to actually move. If the answer is "I'd need to see people use it with me out of the room," a manual workaround can't get you there no matter how quick it is.

Building the real thing usually wins now

Three reasons, roughly in the order that decides it for me.

1. Higher-fidelity signal. People react to a real product. They perform for a fake one. When someone knows you're walking them through a mockup, they're being polite and helpful, and polite and helpful is not a buying signal.
2. It compounds. You keep iterating on what you built instead of binning it. A manual test ends with a slide. A real build ends with something you can change on Monday.
3. You're not burning founder weeks on work that evaporates. Concierge tests are expensive in the one currency you have least of.

Your team's time is your scarcest asset. A bit more effort upfront for a learning you'd actually act on is a trade worth taking.

And then there is the outcome nobody counts when they run this decision, which is what happens after the test resolves.

If it's a winner, you already have it built. You are not writing a spec off the back of a concierge result and starting the build you avoided; you are shipping the thing that just worked. If it isn't a winner, you change it, and changing something that already exists is easy in a way that starting over is not.

Both branches come out ahead. That is what "the cost of being wrong is low" actually means in practice: not that you mind being wrong less, but that neither outcome leaves you holding nothing.

Where this goes wrong

Now of course there's a failure mode, and it's the obvious one. "Build the real thing" turns into building for two months.

That is not this. The whole argument rests on the build being an afternoon or a few days. If your version of building the real thing is a full sprint, the old math comes straight back and the manual test wins again. What the tools changed is how much you can get standing up in a day, not whether build time costs you anything.

So scope it like a test, not like a launch. One flow. The narrowest slice that produces the signal you named a minute ago. If you can't get it standing up in a couple of days, that's information too: either the slice is too big, or this is genuinely one of the cases where manual is still faster.

Honest answer: I get this wrong sometimes and end up two days into something I was sure was four hours.

What's still worth doing by hand

Keep the manual effort where the doing is the point.

Talking to your users. Closing your first customers yourself. Onboarding the first handful personally. In those cases the manual act isn't standing in for a product, it is the thing you're trying to learn, and the relationship you build doing it is half the value. Nobody has automated their way to understanding why someone churned.

That half of the YC advice hasn't aged at all. It's the fake-the-product half that has.

The takeaway

Just build it.

"Do things that don't scale" was built for a world where building was slow, so being wrong was expensive, so you bought insurance against it by hand. Build cost is about a tenth of what it was, which took the cost of being wrong down with it. Test live in market, trust the signal because it came off a real product, keep the winner because it is already built.

Don't default to manual. Default to fast, and fast now usually means building the real thing, scoped small.

Common questions

Is "do things that don't scale" still good advice?

The instinct is right, the default is outdated, and the reason is one equation: the cost to build against the cost of being wrong. The rule assumed building took weeks, which made being wrong expensive, which made manual validation the cheap insurance. Build cost is now about a tenth of what it was, so being wrong is cheap, so the scalable path is often the fastest one. That is the opposite of what the rule assumed.

When should you still do the manual, unscalable thing?

When the manual act is the point: talking to users, closing early customers, the hands-on work that teaches you the problem or builds the relationship. Also any time a quick manual test genuinely is the fastest route to a learning you'd bet on. Sometimes it still is.

What should you reach for instead of a manual workaround?

Build the real thing with AI and no-code tools, scoped to one flow. You get higher-fidelity signal, the work compounds because you keep iterating on it, and you stop spending scarce founder time on tasks that vanish the moment you finish them. If it can't stand up in a couple of days, cut the slice down or go manual.