Vibe Coding vs. SaaS: You Can Build It — But That's Not the Point

There's a lot of noise right now about "vibe coding" your own tools instead of paying for SaaS.

Some of it is real. AI has dropped the cost of "make a thing that kind of works" to near zero. A solo engineer can sketch an MVP in an afternoon that would've been a small team's weekend a few years ago.

But the conversation often collapses into a lazy binary: build = write code, SaaS = write code and put it on the internet and charge money. That's not what businesses pay for. They pay for the unsexy parts. The operational parts. The parts that don't fit into a demo.

And if you're a technical founder, internalizing the difference is one of those lessons that quietly separates people who ship hobby projects from people who build enduring businesses.

"You can build DocSend in a weekend." No, you can't.

This reminds me of the classic founder trope: "DocSend is just file hosting + view tracking. I could build that in a weekend."

Sure. You can build a thing: upload a PDF, generate a link, store a view event. That's a sliver of the features you need right now—likely insecure, untested, and running on vibes and localhost.

But that is not equivalent to what people pay DocSend for.

What's missing isn't "a few extra endpoints." It's the iceberg below the waterline: permissions models that don't leak data; auditing, alerts, and revocation that work under pressure; reliable delivery, uptime, and performance; UX details that remove friction from real workflows; support, billing, security reviews, compliance questionnaires; backups, migrations, and incident response; and the long tail of weird edge cases you only learn by getting punched in production.

People don't buy "static code." They buy a service. Services are living things.

SaaS is mostly not code

"Product = tech" is a common misunderstanding among technical folks. It's also the root of a lot of founder conflict. CTOs think the company is the codebase; CEOs think the codebase is one piece of a bigger organism.

Both views are rational from the inside. Only one is accurate.

In most SaaS businesses, the code is a minority of the work over time. Not because code doesn't matter—of course it does—but because the value is delivered through operating the software reliably, keeping customer data safe and correct, handling integrations and external dependencies, navigating procurement and trust, and iterating based on real usage. The painful work is often the "last 90%": polish, resilience, and doing the boring things consistently for years.

If you're a technical founder, learning that your job is to build the service, not just the software, is a career fork. It's one of those "you can't unsee it" lessons.

Software is crystallized experience

There's another angle that doesn't get talked about enough: software is a manifestation of someone's knowledge, experience, and opinions about how a thing should work.

We learn from the tools we use. My workflow is better because of incremental improvements made by developer after developer, year after year. We all stand on the obsession of people who cared deeply about details we didn't even know to care about.

Would we have Claude Code if generations of foredevelopers hadn't spent thousands of hours designing compilers, editors, version control, package managers, terminal UX, debugging workflows, interface conventions, and all the rest?

Building every tool yourself—whether by hand or with "vibes"—can cut you off from that world. I have no philosophical objection to vibe coding personal tools. I do it too. But I also don't think I'd be one-tenth the engineer I am if I wasn't constantly exposed to the craft of other builders. Using great software is like reading great writing: it changes the way you think.

The last 90% is where products are made

Some engineers worry about this trend because it sounds like: "Who needs software engineers if anyone can vibe code their own apps?"

I'm more optimistic. AI makes it easier to get the first 80–90% done. That's real. But it also makes the difference between "a thing that runs" and "a product people trust" more obvious.

Claude Code can deliver the first 90%. We all know it's the last 90% that differentiates: reliability work, security work, UX sharp edges, integrations, performance, documentation, migration paths, and operational excellence. Vibe coding doesn't eliminate those. It just makes it more tempting to pretend they don't exist.

Different demographics: DIY builders vs. SaaS buyers

A lot of "SaaS is dead" takes assume the same people who buy SaaS are the ones about to stop buying SaaS. They're not.

The people who vibe code their own solutions are usually technical, tolerant of rough edges, happy to self-support, and willing to trade reliability for control. The people who pay for SaaS are often optimizing for trust, time saved, reduced risk, fewer moving parts, and predictable outcomes.

Linux is free. Most people still pay the Windows/macOS tax without thinking twice. Not because they can't install Linux, but because operating the thing is part of the cost—and most people don't want that job. Same story here.

AI lowers the barrier to MVP—and raises the bar for MRR

AI lowers the barrier to making a prototype. That means more experiments, more niche tools, and more workflows getting served. But it also raises the bar for what feels worth paying for every month.

That's not a contradiction. It's a market expanding in both directions.

I can hire a contractor to build a carport, or I can whack one together with supplies from a big box store. More roofs get built. More price points exist. More people learn what they actually want. Rising tides.

If you're selling SaaS, the implication isn't "panic." It's that you shouldn't sell "features." You should sell "I will take this problem off your plate."

Value isn't in the code. It's in the running system.

One thought I keep coming back to: software itself is not inherently valuable. The value is in running it—safely, reliably—and maintaining its data and integrations over time.

That's also why my bar to pay $10/month is high before I buy, and then pretty low afterward. Because once I decide something is valuable, the money is rarely the real cost. The real cost is switching, trusting it with my data, learning it, integrating it into my workflow, and betting that it will still work next month.

If a tool clears that bar, $10/month is rounding error compared to the mental overhead it removes.

Vibe coding a replacement rarely approaches the quality of a product someone has spent years turning into a service. And even if it did, I still have limited time to run and maintain a zoo of custom apps and datasets. So where do I vibe code? When it's truly custom, when it's personal glue, when I'm the only "customer," and the real value is speed and specificity—not polish and durability. AI is a force multiplier for exactly that.

But it's not going to cannibalize the SaaS I'm already willing to pay for—because the reason I pay isn't "I can't write code." It's "I don't want this to become my job."

For younger engineers, the math is different—and that's fine

If you're a younger software engineer with more time than money, the equation changes. It can be rational to build a janky tool and live with it.

But that demographic was never the make-or-break buyer for most SaaS anyway. In many categories, the buyer is a team, a business, or a person with accountability and risk—someone whose time is more expensive than the subscription.

The baseline expectation for quality has been rising for two decades: UX expectations, market saturation, limited human attention, and complexity tolerance. AI accelerates that trend. It doesn't invalidate the model.

The differentiated take

If you strip away the hype, vibe coding mostly means DIY gets cheaper, experimentation increases, the definition of "good enough" for personal tools shifts, and the definition of "worth paying for" shifts upward.

That's not "SaaS is dead."

That's "SaaS has to be more honest about what it really is."

A SaaS isn't a repo. It's trust, operations, continuity, and responsibility.

So yes: vibe code your throwaway tools. It's fun. It's empowering. It's also a great way to learn.

Just don't confuse "I built a sliver of the features I need right now" with "I built the product." And if you're building SaaS yourself, don't mistake your company for your codebase.

Build the service.