When AI Builds Almost Everything, How Does SaaS Survive?

When code gets cheap to produce, what protects a SaaS product is data, trust, and distribution rather than features, and anyone building a new one may spend more money and time on getting found than on building.

SaaS (software you pay a subscription for and use over the internet) is still around. But will people keep paying for it when AI writes most of the code? I keep asking myself that. This post is my opinion, not a news report.

Tools like Claude Code have pushed the speed of building software to an almost absurd level. Work that used to take weeks or months now takes days. If you can describe an idea out loud, wire up a few APIs, and have a working product by Sunday night, nothing stops someone else from building the same thing.

Take a simple SaaS that costs $29 a month. If its core feature can be rebuilt with a good prompt and a few hours of work, who keeps paying?

One thing made that worry worse: REA, an open-source project that has been getting attention on GitHub.

REA (Reverse Engineer Anything) is an MIT-licensed tool that connects AI coding agents such as Claude Code, Codex, and Cursor to reverse-engineering tools. Reverse engineering means taking apart a program without its source code to work out how it behaves. REA lets the agent use analysis tools like Ghidra, Hopper, and IDA (programs that turn an executable into something readable) and explain how an app or executable behaves, with evidence. The output is not the original source code. It is pseudocode (a plain-language rewrite that looks like code) and assembly (low-level machine instructions). It also only looks at what sits on the user’s side: desktop or mobile apps, the front-end code of websites, firmware, and the like. The back-end code of a SaaS that runs only on a company’s servers is out of its reach.

Some reports say the project passed 100,000 GitHub stars within a week, but the counts differ depending on the source, so I could not confirm the real number. Some developers reacted with “so you can copy an app from its binary now?” and “the software moat (the barrier that keeps competitors out) is gone.”

What struck me was not the tool’s performance but the shift in perception. “Coding is hard” used to be the defense. Then “just build it” lost its edge, and now “you can peek at the behavior without the source” has joined the conversation. The gap between a demo and a real product is still wide. Even so, if you ship something to users’ devices, such as a desktop or mobile app or a browser extension, it is hard to keep assuming “my logic is secret.” Code that lives only on a server cannot be read with this tool, but the screens and behavior users can see are as easy to copy as ever. The value of being able to build and of being able to hide are both shrinking. I still can’t say what takes their place.

Will existing SaaS keep growing?

A well-established SaaS will not die any time soon. Customers have already put their data and workflows inside it, and inside a company the phrase “let’s switch to something else” is a cost in itself. Integrations, permissions, audits, and support are things a weekend clone (a copycat version) cannot replace overnight.

What changes is where growth attaches. Products that stood out only on features will feel price pressure first. Per-seat subscriptions, which charge for each user, may also run less smoothly once automation shrinks the number of seats. On the other hand, a product that takes over one industry’s work end to end can get stronger. As data piles up and integrations deepen, a monthly fee becomes less about buying features and more about not having to carry the problem yourself. What REA shook is the belief that “no one can see the code, so it’s safe.” It did not shake “our company’s data lives here and we do our daily work on this screen.”

If you build something new, what risks come with it?

Cheap building also means the cost of piling in with the same idea is cheap. I see four risks.

Copying and price.
A product built over a weekend can be rebuilt over a weekend. The shelf life of “I built it first” has gotten short. I still think $29 to $99 a month is possible. But if the reason for that price is “this is hard to code” or “the source is closed,” I would worry. The moment a customer feels they could build something similar, the subscription becomes a luxury. You need a case that says you take on the cost of building, fixing, and protecting it for them.

Maintenance.
Demos are easy and operations are still hard. Outages, security, payments, support requests, and model or API changes do not answer “who is responsible?” no matter how fast AI writes code. Run it alone and all of that lands on one person.

Choosing a market.
Sell a thin feature in a wide market and you run straight into bigger tools and cheaper copies. Go deep on a narrow problem and the market shrinks, you have to know the field, and building trust takes time. The urge to see revenue fast and the urge to pick a spot that is hard to copy often pull in opposite directions.

Distribution.
The easier it is to build, the more products no one ever finds. Today, a product that is built but unseen might as well not exist. Without a channel, even a well-made finished product ends up as unsold stock.

Products are pouring out. Will marketing costs rise?

I think so, at least if you want the same level of attention. The supply of products has grown, but people’s attention, search results, and feed space have not grown to match. When similar landing pages (the first page that introduces a product) and similar “AI-made ___” products pile up, it costs customers more to choose and costs sellers more to be remembered.

When building gets cheap, a solo developer who could not afford marketing may now afford ads, and so can more people competing for the same bids. The bottleneck moves from development to customer acquisition cost (CAC, the money it takes to bring in one new customer). For a $29 product, a small rise in CAC stretches the time to break even. Building takes a weekend, and marketing can take months.

A narrow field, an existing customer network, word of mouth, and expertise that stays findable in search are less exposed to rising ad prices. But that does not mean marketing is cheap. It means you already own distribution or you are building it yourself.

Should you stay on good terms with whoever owns the traffic?

If marketing costs rise, the next question is whether to line up at the platforms that already hold the crowd. Search, app stores, social networks, marketplaces, plug-in stores of big SaaS companies, and soon the spots where AI assistants make recommendations: traffic gathers behind a few doors. To pass through, you have to follow their rules, fees, and recommendation logic. “Looking good to them” is not flattery. It is closer to asking whether your product is aligned with that company’s incentives.

There is a price. If rankings or API policies change, or the platform adds a similar feature itself, your exposure can vanish overnight. Still, it is hard to ignore them. Gathering subscribers through your own distribution alone is a bigger job than building the product. So I think if you leave your traffic to one door, that door becomes your business. Build on a platform but keep part of your customer relationships, data, and exit routes in your own hands, and that is a compromise. Hand over all of your exposure, and that is renting.

Do you need money to build?

On building alone, the answer is the opposite. AI coding tools, the cloud, payments, and templates have lowered the bar for getting something made and online. In 2026, at the prototype stage, “you need funding to build” fits less and less.

What remains is a different kind of money: money to be seen, to wait, and to handle outages and customers. Once CAC rises, platform fees stack up, and price competition starts, you need cash to last until you turn a profit. The use of money shifts from buying code to buying time. Bootstrapping (growing on your own earnings, with no outside investment) is not impossible. The stretch you have to get through has moved from development to distribution and survival. With plenty of money you can buy that stretch with ads and hires. With little, you have to pick cheaper forms of distribution earlier: a narrow market, existing relationships, or content.

Summing up

I still don’t have an answer. The direction is a little clearer, though. The risk for anyone building something new is less technical failure than ending up on the side that is easy to build, easy to copy, and easy to bury. What others cannot catch up with over a weekend is an understanding of the customer’s problem, integrations and data, trust, and distribution. Those four were outside the code all along. So I think a product has to answer three questions from day one: “Why is this subscription hard to cancel?”, “How will people find it?”, and “Who will I not rent that discovery to?” Building got cheap, and what comes after got expensive.

What could change for developers

What follows is our estimate and advice, based on the author’s own view.

• Check the reason your price is justified. See whether data storage, integrations, accountability, and trust, rather than “coding is hard” or “the source is closed,” are what the price rests on.
• If you ship to users’ devices, as a desktop or mobile app or a browser extension, assume the core logic can be read from the outside and decide which parts to move to a server.
• Decide where you will meet customers before you build. Do not leave your exposure to a single platform; keep part of your customer list and data in your own hands.
• If money is tight, pick distribution that costs little in ads first: a narrow market, existing relationships, or content.

What to watch next

• How much reverse-engineering tools like REA are actually used to copy commercial products, and what policies product makers and platforms put in place in response.
• Whether the criteria AI assistants and app stores use to recommend tools become public.

Sources

• REA: Reverse Engineer Anything (GitHub)