Paying forever or maintaining forever? Vibe-coded SaaS clones and the option in between

A LinkedIn post by the founder of DocsAutomator has been making the rounds this week. Its argument: replacing most SaaS products by vibe coding your own version is economically irrational, because the cost of software isn't in writing it. It's in the long tail of bugs and weird edge cases nobody thought of at the start, and in the endless changes that follow once software becomes easy to change.

The example attached to it is hard to argue with. A developer who posts as @hustle_fred cloned Airtable in five days for a client who refused to pay $500 a month. Four months later he's still maintaining it: "every two weeks it's another edge case, a UI tweak, or a 'quick 10-minute request'." By his estimate the client has spent ten times the $2,000 they would have paid Airtable, in headaches alone. His conclusion: "isn't it easier to just pay?"

We agree with almost all of it. But the conversation tends to frame the choice as having two options: rent the SaaS forever, or build a clone and maintain it forever. There's a third, and it's often the one the client actually wanted.

What the client was really refusing

The client didn't turn down Airtable because they wanted to own a codebase. They turned down a price: $500 every month, however much they used it, with no end date. The clone looked attractive because it promised a different pricing model. Pay once, and it's yours.

What they actually got was a different maintenance model. The one-time price came bundled with a vendor's job nobody had priced in: every bug, every browser quirk and every feature request now lands on one person. Fred didn't just build a tool. He became a one-person SaaS company with a single customer.

Build or buy is really about who owns the long tail

The long-tail point is the important one. Most of what software costs comes after launch, so the useful question isn't "build or buy?" but "who handles the edge cases, and how do I pay for that?"

• A subscription: the vendor owns the long tail, and you pay every month for as long as you use it. A good deal for software your team relies on all day.
• Your own clone: you own the long tail. You pay a vendor nothing and pay yourself in time, indefinitely.
• Pay-once, pay-per-use, free or open-source tools: someone else still owns the long tail, but you pay for it differently: once, by usage, or by running it yourself.

What the option in between looks like

Open source, self-hosted. For the Airtable case specifically, projects like Baserow, Grist and NocoDB give you tables, views and forms that you can run on your own server. That isn't zero work: someone has to apply updates, take backups and keep a server running. But running software and maintaining software are different jobs. When an edge case turns up in the grid view, it's an issue on a project with a large user base, not a ticket on your desk. Several of these projects also sell hosted plans, which brings back a monthly bill, though often a smaller one.

Pay per use. More and more tools charge for what you do rather than for seats: per API call, per booking, per gigabyte stored, per minute transcribed. If your usage is uneven, quiet months cost close to nothing, and fixing bugs is still the vendor's problem.

Pay once. Desktop apps, self-hosted licences and lifetime plans let you pay once for a version and keep using it. The trade-off is real: the vendor needs a steady flow of new customers to keep funding updates, so it's worth checking how long they've been around and what happens when the next major version ships.

Free. Sometimes the free plan of the very product you were about to clone covers what you need. Airtable has one, with limits. It's worth checking before anyone writes a line of code.

None of these is free of trade-offs

Self-hosting moves some work onto you, even if it's far less than maintaining a clone. Pay-per-use can surprise you when usage spikes, so set limits. Pay-once products can stall. And for software at the core of a business, used all day by a whole team, a subscription is often exactly the right deal: you're paying professionals to keep improving something you depend on. That's the original post's point, and it holds.

The trouble is the cases in between: the tool three people open twice a week, or the client who balks at a monthly bill for something they barely use. Those are the cases where people now reach for vibe coding, and they're mostly the cases where a better-fitting pricing model already exists.

Before you clone, check

1. Is there an open-source project that already does most of it? Running it is cheaper than maintaining your own.
2. Is there a tool in the same space you can pay for by usage, or buy once?
3. Does the free plan of the original cover what you actually need?
4. Only if all three answers are no, and the tool is small and low-stakes, build it. And budget for maintaining it from day one.

Vibe coding is great for small, disposable tools; we wrote about where it fits, and what it's doing to SaaS prices, in an earlier post. For everything else, the choice isn't only between paying forever and maintaining forever.

We run unsubs.org, a catalog of pay-once, pay-per-use, free and open-source alternatives to subscription software, which is how we ended up thinking about this.