There is an old habit in web development that still feels attractive: build everything yourself.
Custom boilerplate. Custom admin panels. Custom authentication. Custom deployment scripts. Custom validation layers. Custom logging. Custom everything.
It feels professional. It feels like engineering. It feels like control.
But in many modern web projects, I think this approach is becoming a utopia.
Not because developers became worse. Not because writing code is bad. But because the web became too complex, too fast-moving, and too expensive to maintain when every team keeps reinventing the same basic building blocks.
The real cost of “just writing it ourselves”
When a team writes its own boilerplate, the first version often looks reasonable.
A few helpers here. A small internal framework there. Some custom conventions. Some glue code. Some shared base classes. A small wrapper around an API. A custom permission system because “our case is different.”
At the beginning, it works.
The problem appears later.
Six months later, nobody remembers why the abstraction was designed that way. One year later, the project has edge cases nobody wants to touch. Three years later, the system becomes “legacy,” not because the programming language is old, but because the decisions inside the codebase are hard to change.
This is how many old systems become almost impossible to support.
Not always because they were badly written. Often because they were over-customized, under-documented, and built around assumptions that stopped being true.
Orchestration is becoming more important than boilerplate
Modern web development is less about writing every part from scratch and more about choosing, combining, and controlling existing systems.
Authentication can be handled by mature providers.
Payments can be handled by Stripe, Paddle, Lemon Squeezy, or other platforms.
Email delivery can be delegated.
Analytics can be delegated.
Background jobs, queues, observability, file storage, search, feature flags, error tracking, deployment, monitoring — almost every common problem already has strong solutions on the market.
The developer’s job is changing.
It is not only “write more code.”
It is:
- choose the right components;
- understand tradeoffs;
- design clean boundaries;
- keep the system replaceable;
- avoid unnecessary coupling;
- document decisions;
- keep the architecture understandable.
That is engineering too.
Sometimes it is harder than writing code.
Less code usually means less liability
Every line of code you own is a line you may need to debug, test, secure, migrate, document, and explain to another developer.
A smaller codebase is not automatically better, but unnecessary code is almost always expensive.
When you use a mature external solution, you reduce some maintenance burden. You let another team solve a generic problem so your team can focus on the specific business problem.
Of course, this is not free.
The flip side is dependencies.
Every dependency is a risk:
- vendor lock-in;
- pricing changes;
- API changes;
- security issues;
- service downtime;
- migration cost;
- loss of control.
So the answer is not “use dependencies everywhere.”
The answer is to be intentional.
Do not build everything yourself by default. Do not install everything by default either. Think in tradeoffs.
The question should be:
Is this code part of our real advantage, or are we just rebuilding infrastructure that already exists?
Architecture matters more than clever boilerplate
A lot of developers still spend too much energy on implementation details that tools can already handle.
Formatting. Indents. Whitespace. Import sorting. Small style preferences.
These things matter for consistency, but they should not consume expensive human review time.
Use linters. Use formatters. Use static analysis. Use code analyzers. Use CI checks. Let tools fight about spaces and semicolons.
Human review should focus on things tools cannot fully understand:
- Is this design maintainable?
- Is the boundary clear?
- Will this scale?
- Is this abstraction necessary?
- Is this decision documented?
- Can another developer understand this six months later?
- Are we creating future migration pain?
In 2026, arguing manually about indentation in pull requests is too expensive.
Documentation is not optional anymore
In old projects, the biggest problem is often not the code itself.
The problem is missing context.
Why was this service created?
Why does this table have this strange structure?
Why is this module not using the same pattern as the rest of the system?
Why are we afraid to refactor this part?
Without documentation, every new developer has to reverse-engineer history from code, Git commits, Slack messages, and tribal knowledge.
That is slow. That is expensive. That is risky.
Good project documentation does not need to be huge. But every serious project should have clear notes about:
- architecture decisions;
- coding conventions;
- deployment flow;
- domain rules;
- external dependencies;
- known limitations;
- reasons behind important tradeoffs.
This is more valuable than another custom boilerplate generator.
“Inventing the bicycle” is not always innovation
There are cases where custom code makes sense.
If your business depends on a unique workflow, a unique algorithm, a unique user experience, or a unique integration model, then yes, build it carefully.
But many teams invent the bicycle in places where the bicycle is already good enough.
Custom auth is not usually innovation.
Custom billing is not usually innovation.
Custom logging is not usually innovation.
Custom admin CRUD is not usually innovation.
Custom formatting rules are not usually innovation.
Most of the time, these things are just future maintenance.
The best code is sometimes the code you decided not to write.
The modern developer should think like an architect
I do not think web developers should stop coding. That would be absurd.
But I do think the center of gravity is moving.
The valuable developer is not the one who writes the most boilerplate. The valuable developer is the one who knows what should exist in the codebase and what should not.
That means understanding architecture, systems, documentation, team workflows, automation, deployment, testing, observability, and long-term maintenance.
It means asking better questions before writing code:
Should we build this?
Should we buy this?
Should we integrate this?
Should we remove this?
Will this decision still make sense in two years?
Good software is not only created by writing code. It is also created by avoiding the wrong code.
Final thought
Modern web development is not about proving that we can build everything ourselves.
Most experienced developers can build almost anything given enough time.
The real question is whether we should.
In many projects, the better strategy is orchestration: using existing tools, keeping the codebase smaller, documenting decisions, enforcing style automatically, and spending human attention on architecture instead of boilerplate.
Because in the long run, the most expensive part of software is not writing the first version.
It is living with it.
Top comments (0)