Artificially generatedBuild it yourself
For decades, standard software was the sensible choice: ready-made, proven, cheaper than anything custom. That calculation has reversed. Not because standard software has gotten worse, but because custom building has become orders of magnitude cheaper. What remains are the costs you always bought along with the standard and previously had to accept.
The reason you chose standard has disappeared
The decision for a ready-made system was never a declaration of love. It was a cost calculation: custom building meant developer-years, and developer-years were the most expensive thing in the house. Against that, any license was cheap, and any free framework unbeatable.
This one variable has changed. What used to be a quarter is now an afternoon. With that, the argument that carried the entire construction falls away.
What remains is the other side of the calculation, which previously interested no one because there was no alternative: adapting to foreign ideas, waiting for foreign schedules, dragging along foreign legacy baggage, and an attack surface you didn't choose.
These items were always on the balance sheet. They just were never the problem because the alternative was more expensive. Now it isn't anymore.
You're not buying a piece of software, you're buying a family tree
The 79 is the most important number in this series. A team decides on a package and thereby inherits the decisions of dozens of people it has never met, about code it has never read. In September 2025, a single compromised developer access credential was enough to inject malicious code into eighteen packages that together get 2.6 billion downloads per week. None of these packages was disreputable. They were just everywhere.
Not worse. Discoverable.
This is where most texts on this topic take a wrong turn. They claim custom building is more secure. That's not true. Your self-built system very likely has more bugs than an established project that thousands of people have been checking for years.
The difference lies elsewhere, and it's more important than the bug count: monocultureThe term comes from agriculture. A field with a single variety can be farmed efficiently, but a pest that fits that variety takes the entire field. Diversity is inefficient and survives. makes attacks reusable.
A custom system isn't on any of these lists. It's not more secure, it's not searchable. Anyone who wants to attack it must first understand it, and that's manual work on a single target, instead of a loop over a hundred thousand. This doesn't shift the quality of your code, but the economics of the attack, and these economics determine whether you even appear on the radar.
The second part of this is visibility itself. A standard system reveals from the outside what it is. Paths, headers, filenames and error pages are fingerprints. Anyone who looks at your site knows your blueprint before making the first attempt.
Where standard still wins, and clearly so
A thesis that knows no boundary is an ideology. So here's the boundary, and it follows a single question: Does exchange with the outside world take place at this point?
Where something leaves or enters your system, the standard is not just permitted but mandatory. A custom date format, a custom image format or a custom transmission protocol doesn't make you independent, it makes you unreachable.
The hardest case is encryption. Writing your own cryptography is a well-known, well-documented way to harm yourself. Not because custom building is fundamentally bad, but because here the errors are invisible: a broken encryption method works flawlessly in testing and still protects nothing. The same applies to authentication procedures, time zones, character encoding and payment processing.
So the rule isn't "never take anything ready-made". It is: standard at the edges, custom at the core.
The dividing line runs not between large and small, but between exchange and core.
| Area | Choice | Rationale |
|---|---|---|
| Protocols, formats, character sets | Standard | Pure exchange surface. Custom means isolation here. |
| Encryption, authentication, payment | Standard | Errors remain invisible and are not testable. |
| Database, runtime, web server | Standard | Mature, replaceable, not a differentiator. |
| Your processes and rules | Custom | This is precisely where you differentiate. A foreign system forces you into its conception of it. |
| Your interfaces and tools | Custom | The adaptation effort for a ready-made system now exceeds the building effort. |
| Your data and its structure | Custom | Foreign schemas otherwise determine which questions you can even ask. |
What's transferable is the knowledge, not the component
The advice "build it yourself" is often misunderstood as "start from zero". The opposite is meant.
Forty years of software building have produced insights that are valid: separate state, make errors visible early, keep interfaces narrow, don't duplicate anything. These principles are what's valuable. They cost nothing, they create no dependency, and they don't become obsolete.
The component, on the other hand, doesn't bring the principles with it. It brings the interpretation of the principles by foreign people, plus their compromises, their legacy baggage and their roadmap.
This is also why existing systems remain valuable, just differently than thought: as a template, not as a foundation. You read how a mature project solved a problem, understand why, and then build it the way it fits your own case. The blueprint is the yield, not the building.
Adopting a standard system is a cloning process. You get an exact copy of something that was created for a different purpose, and every further copy is identical. That's efficient and it's a standstill: a copy can do nothing that the original couldn't already do.
Building yourself means your system carries your own construction instructions. Every adaptation is a small deviation, and most of them are worthless. But some are valuable, and those remain.
Mutation is the engine of evolution. A system that only copies doesn't have this engine. It can improve by waiting until someone else improves something. Nothing more.
The question has turned
It is no longer "can we afford to build our own?", but "can we afford to let external decisions determine our business?".
Not everything at once
The path is not the big replacement. It is the piece that hurts the most today, then the next one.
Standard remains at the edges
Protocols, encryption, databases. Anyone building their own here has missed the point.
The litmus test
Ask for every component: does it determine how your business works? If yes, it belongs to you. If it only transports data, take the standard and be glad.
- Sonatype, State of the Software Supply Chain 2026. Malicious packages 2025, cumulative volume, share per package registry. sonatype.com
- Socket, CVE analysis 2025. Total volume of vulnerability reports and share of the WordPress ecosystem. socket.dev
- Unit 42, Palo Alto Networks. Attack surface of the npm registry, cascade from September 2025. unit42.paloaltonetworks.com
Figures on vulnerabilities and exploitation times refer to 2025 and the first half of 2026. They describe reports and observed incidents, not the total number of existing vulnerabilities.
