Should You Build Your Own Software Now That AI Can Clone It?

Why this question keeps coming up

Whenever AI-assisted reverse-engineering makes headlines, such as the recent projects that rebuilt Adobe applications and gathered tens of thousands of GitHub stars within days (such as storytold/artcraft), the same conclusion follows: software vendors are finished.

For a freelancer or a hobbyist, that may be partly true. For a company with customers, auditors, and a roadmap, the real question is different. It is not “can we build it?” but “should we own it?”

The first-version fallacy

The first-version fallacy is judging build-versus-buy by the speed and cost of version one. Version one is the cheapest, most exciting part of a software product’s life. Everything that decides whether it was a good decision comes later.

A thought experiment shows how this plays out:

A cybersecurity company has a team fully capable of building a CRM. They sell a security platform. Should they redirect some of the team to build their own CRM, or double down on the security platform?

• Month 1. A vibe-coded first version of the CRM is working in two days. It feels like a win.
• Month 3. The tool is now in daily use, so someone has to own it. Either the team that built it is retained to maintain it, or it becomes unowned software that people depend on.
• Month 9. The established CRM vendors the clone was modelled on have shipped new features in the meantime. Sales asks for them. Either the team keeps pace, or the internal tool falls behind the market it was copied from.
• Month 18. The internal CRM now costs more than the subscription it replaced. The team has quietly stopped working on the security platform’s harder problems, and smaller competitors have entered the market while the company was distracted. The core product kept shipping, but it stopped getting deeper.

Nothing here required anyone to make a bad decision. Each step was reasonable. That is what makes the fallacy easy to fall into.

The seller-side costs

For a company building tools it does not sell, four costs tend to be hidden:

• Ownership. Every internal tool needs a named owner for as long as it is used. Their time is taken from the product customers pay for.
• The parity treadmill. Vendors improve continuously, and users compare your internal tool with them. Staying competitive means keeping up with a team whose whole business is that product.
• Running costs that move. Model prices, APIs, and dependencies change under what you built. A tool that was cheap to build can become expensive to keep running.
• Focus. A team’s attention is the scarcest resource. Time spent on a side project is time not spent on roadmap speed, customer depth, and defending the core product.

The temptation to resell the internal tool as a product usually makes things worse. A CRM and a cybersecurity platform have different buyers, channels, events, and sales cycles. Entering a second market means paying the cost of entering a second market.

The buyer-side costs

Buyers think about this differently from builders, and for good reasons:

• Risk transfer. A mature company buys products outside its core to move accountability. When a vendor owns the infrastructure, security, compliance, and roadmap, the risk sits with the vendor. An internal build puts all of it back on you.
• Attack surface. An internal tool that did not get the same security scrutiny as the company’s main product is a new way in. For a security company, being breached through its own side project is the worst possible story.
• Reversibility. A subscription that disappoints can be cancelled, and the cost of switching is small. An internal build is the opposite. Features, architecture, and infrastructure are decided upfront, and the sunk cost makes it hard to walk away.
• Procurement discipline. Buying forces a comparison of fit, reviews, budget, and contract terms. Building skips that process, and the discipline it provides goes with it.

Open-source and free alternatives have been available for nearly every category of software for years. Mature organisations have still mostly chosen to pay vendors, not always because of price, but for capability, maintenance, and risk transfer.

When building is the right call

This is not an argument against ever building. Building is usually right when:

1. The tool is part of your differentiation. It is something customers pay you for, or it directly shapes how you win.
2. No vendor fits. You have actually evaluated the market, and the gap is real.
3. You need control a vendor cannot give, for example for data residency, regulation, or integration depth.
4. The scope is narrow and stable, and there is a named owner with time budgeted for maintenance.

A small internal automation that connects two tools you already use often passes this test. A full replacement for a mature product category rarely does.

A five-question test

Before building something you could buy, answer these five questions:

1. Does this tool make customers choose us, or is it a back-office function?
2. Who owns it in 18 months, and what are they not doing instead?
3. What will it cost to keep up with the best vendors, not just to match them today?
4. Who carries the security and compliance burden, and has it been assessed?
5. If it disappoints, how easily can we walk away?

If you cannot answer two or more of these, you are probably still in the first-version fallacy.

A dated prediction

Prediction (17 October 2026): By the end of 2027, a visible share of companies that replaced commercial tools with AI-built internal versions will have either returned to a vendor or formally assigned an owner and budget to the internal build. The common reason will be maintenance and security, not that the tool could not be built.

What would prove this wrong: Evidence that most of these internal replacements are still running unowned, with no rising maintenance burden and no security incidents, after two years.