Why Custom Software Still Beats AI-Generated Apps

Short answer: AI has made it easy to build an app that works. It hasn't made it easy to build one that's safe, survives its second year, or has someone who can answer for it. The bigger risk may be a new kind of monoculture: thousands of applications ending up with similar code, libraries and configurations, without anyone having adopted a common product. A weakness in one widely used pattern could then affect businesses that have nothing else in common. Custom software built by experienced people avoids much of that. It isn't automatically secure, and for a prototype or a throwaway tool, AI on its own is often the right choice.

First, the fair version of this comparison. It isn't people against AI. Experienced developers use these tools every day, and so do we. The real difference is whether someone who understands the system decides what ships, and stays responsible for it afterwards.

1. Working is not the same as safe

A demo walks through the paths you planned. Most security problems sit elsewhere, for example when a customer changes a number in the address bar and sees someone else's invoice, or an ordinary user calls an admin function directly. Neither problem appears while you're clicking through your own app, and someone without experience doesn't know to ask about them.

The tools won't reliably ask for you. Veracode's testing of more than a hundred models found they chose the insecure way of writing code nearly half the time when both options were available, and its later update found little improvement. The failure also happens in the real world: in 2025 a published vulnerability described apps from one popular AI builder whose missing database rules let outsiders read and write their data.

2. Popular products get attacked in bulk

Custom software has long had an edge over off-the-shelf products for a simple reason. Attackers run on economics: a flaw is worth the effort of finding it multiplied by the number of places it works. When a widely installed product has a weakness, every customer becomes a target at once, whether or not anyone has heard of them.

The 2023 MOVEit attacks are the textbook case. One flaw in one file-transfer product led to data theft from thousands of organisations, most of which were simply running a normal business tool. A system built for one business is less likely to be exposed to the same mass exploitation. An attacker generally has to identify its particular weaknesses rather than reuse an exploit against thousands of identical installations.

WordPress shows this at everyday scale. In November 2026 it ran about two in five websites, and it's easy to recognise from the outside. Patchstack, a WordPress security company, reports that nearly all the flaws found in 2025 were in plugins and themes, and that the most heavily exploited ones were typically attacked within hours. Now compare that with a small Node.js service built for one specific job. It has no plugin system, no unnecessary features and no publicly exposed administration interface. If the vulnerable feature isn't there, that exploit has nowhere to land, and a smaller attack surface can make a real difference. It also has a price, which we'll come to.

3. AI is becoming a popular product nobody installed

AI-generated apps recreate that problem in a quieter form. A WordPress site is one more copy of a single product. An AI-generated app is new code, but it comes from only a few sources: models trained on overlapping public code, with a preference for popular tools. Similar requests produce similar answers, down to the libraries, the project structure, the way logins are handled and the hosted database with its settings left open. Nobody chose a shared product, but they may have ended up with one.

Models tend to reach for the tried and tested approach, and usually that's fine. A popular implementation isn't necessarily the right one for a particular application. If models keep favouring familiar approaches, that preference could reinforce itself over time: popular approaches get generated more often, that code gets published, and later models learn from it. Research published in Nature found that models trained repeatedly on generated content gradually lose the rarer parts of what they originally knew. That research wasn't about software and doesn't show that code will narrow in this way. If the loop does become significant, it could gradually reduce the range of approaches that developers and models consider. Whether it reaches that point remains to be seen.

Security researchers have warned about concentration like this for decades. A well-known 2003 report compared software monoculture to a single crop: efficient until one disease reaches the whole field.

The parallel with WordPress only goes so far. Three differences matter:

• Similar, not identical. A WordPress exploit runs unchanged on every vulnerable site. Generated apps share a kind of mistake rather than exact code, so an attack has to be adapted to each one, which is the sort of work AI tools are good at.
• No vendor. When a WordPress plugin has a flaw, someone can publish a fix and many sites can install it. A weak pattern in generated code has no owner, no advisory and no update.
• No list of who's affected. You know whether you run WordPress. You can't easily tell whether your generated app contains a pattern that was just found to be unsafe.

We can already see this predictability being exploited. Models sometimes recommend software packages that don't exist, and research presented at USENIX Security showed that the same invented names keep coming back. That predictability lets an attacker publish malicious code under one of those names and wait for the next generated app to install it.

The effect isn't limited to security. Spend time looking at AI-generated products and familiar layouts, components and even marketing language start to appear repeatedly. That might save development time, but it makes differentiation harder.

4. Where this is heading: attackers that know the patterns

This part is our own reading of the direction, not an established trend. AI is already good at probing live software. An autonomous system reached the top of a US bug-bounty leaderboard in 2025, and Anthropic reported an espionage campaign that used AI to carry out much of the work, though outside researchers have questioned how independently it really ran.

Put that next to a large population of apps with a shared structure and shared likely mistakes. An attacker doesn't need to understand each one. It can try a handful of known weaknesses everywhere, cheaply, and keep whatever opens. The more predictable an application's structure becomes, the easier it may be for automated tools to look for familiar weaknesses.

5. Where custom software doesn't protect you

It would be easy to stop there, but "nobody will bother with us" is not a security plan. Four things limit the argument:

• Being unique is getting cheaper to get past. Custom code was partly protected because studying one company's system took skilled people a long time. The same AI that sweeps for patterns can also read an unfamiliar app. You avoid the mass attack, not a targeted one.
• Your own code still stands on shared code. Log4Shell reached in-house applications as well as commercial ones, often through a library nobody knew they were using.
• Nobody tests it unless you arrange it. A major product has a security team and outside researchers looking for flaws. A custom system has whoever you pay, and the login, sessions and upload handling that WordPress has hardened over two decades are now yours to get right. If the agency is gone and nobody is updating it, you may be worse off than with either alternative.
• Sameness also has an upside. A safe default in a popular framework protects everyone who uses it, and better models could spread good habits as quickly as bad ones. Hand-written login or encryption is usually a mistake.

So the useful rule is to be unique where your business is unique, and boring everywhere else. Use proven frameworks and services for login, payments and encryption, and keep the custom work for the logic that's really yours.

6. What experience adds beyond security

The real difference often becomes apparent after launch, when actual customers start using the application in ways the first version was never designed to anticipate. These are the things that matter then:

• A data model that lasts. Early structural decisions are the most expensive ones to change once real customers depend on them.
• Production basics. Tested backups, monitoring, safe database changes and a way to roll back a bad release.
• Changes that don't break other things. Code nobody understands gets harder to change with every fix, until each repair causes a new fault.
• Judgment about what not to build. An experienced team will tell you when you're asking for the wrong thing, which a tool rarely does.
• Someone accountable. When a regulator, a client or an auditor asks how your data is handled, somebody has to be able to answer.

Already running an AI-built app?

You don't need to throw it away. If it has real users, have someone experienced check who can reach which data, whether any keys or passwords are exposed in the code sent to the browser, whether every package it installs is legitimate, and whether a backup has ever been restored. Those checks are quick compared with the problems they prevent, and many apps only need targeted fixes.

Which do you need? Six questions

1. Is this a prototype or an internal tool with no sensitive data? (If yes, build it with AI and move on.)
2. Does it hold customer data, payments or anything regulated? (If yes, someone experienced must review it.)
3. Is it a common need, like email, accounting or payments? (Buy it, and keep it updated.)
4. Is it the thing that sets your business apart? (That favours custom.)
5. Can someone explain exactly how it decides who sees what?
6. Who will update and fix it two years from now? (If nobody, don't build it at all.)

The same thinking runs through our guides to build vs. buy and adding AI to a product: use the fastest option that you can still stand behind when something goes wrong.