I started building things when I got my first dev job at 19. Not because I was trying to be special, but because I wanted to understand. I wanted to experiment and break stuff safely. That path later turned into what became our stack - Grace Web (PHP framework), our CMS, and a set of JS classes (no HTML or CSS framework, those are usually the easy part anyway).
I was uncomfortable using other people’s stuff from day one, and I still am. At 19 it wasn’t about “shipping” anything - it was about learning. I learn by building, breaking, and understanding systems from the inside. Relying on tools I didn’t fully understand felt like skipping the lesson. Only a few years later I realized it also becomes part of what you ship to clients.
That discomfort aged well.
Before we dive
Sometimes it’s the right call to use existing stuff. But over time we moved from “small sharp tools” to “whole stacks you live inside”, and many people ship things they don’t really understand anymore.
I’m writing this now because AI makes that trend obvious. AI is a power user, not a creator. It can generate output without understanding the system behind it - and that’s the same failure mode you get when you build on top of huge frameworks you can’t reason about.
We’re not at “AI replaces engineers”. But if replacement happens, it starts with tool users decades before it touches expert creators.
The “Use This, It’s Faster” Trap
Early in web dev I was told the usual stuff: wrap everything into jQuery objects, chain .find() everywhere, use whatever plugins you can find. It looked productive. It also felt like programming with oven mitts on.
Later, the same pattern kept repeating: the website starts lagging, UI stutters, mobile gets weird, and suddenly the fix isn’t “optimize a line” - it’s “unwind a whole approach”.
Meanwhile, native browser APIs like querySelector and querySelectorAll are fast, predictable, and implemented in highly optimized native code. The browser is already your engine. If you keep stacking engines on top of engines, you get overhead, complexity, and mystery bugs as a bonus prize.
Performance is one part of it. But the bigger problem is this: people keep adopting abstraction without understanding what it abstracts.
To be fair, jQuery existed for real reasons: browsers were a mess and APIs weren’t consistent (hello Internet Explorer 6). But that doesn’t justify turning the whole front-end into a dependency pile, especially when the platform eventually grew up.
You Can’t Guarantee What You Don’t Understand
This is the part that actually matters in business.
How can a developer guarantee quality if they don’t know the system they’re shipping?
And I don’t mean “they didn’t read React source code”. I mean basic stuff like:
- What exactly happens on the client vs the server
- What runs on every request vs what’s cached
- What code executes on scroll, resize, input, render
- What you can safely change without collapsing the whole thing
If you don’t understand your own stack, you can’t confidently promise:
- “Yes, we can fix that quickly.”
- “Yes, we can make it faster.”
- “Yes, we can make it secure.”
- “Yes, we can adapt it when your business changes.”
You can only promise “we’ll try, unless the tool says no”.
That’s not engineering. That’s renting complexity.
Big Frameworks Make It Easy To Ship Blind
Something weird happened over time.
At first (before my career started), small libraries popped up and that was great. A tiny focused tool that does one thing well can genuinely save time and reduce risk. OpenSSL is a perfect example. You do not want to DIY cryptography. FFmpeg is another. Use them if you need crypto or video. They’re obsessively optimized and everywhere.
But then the industry drifted from “small sharp tools” into “entire castles you move into”.
And castles come with:
- hidden rooms (behavior you didn’t expect)
- fragile walls (one upgrade breaks four things)
- and a landlord (you wait for someone else to fix critical bugs)
So now we get people shipping products where they don’t really know what happens under the hood. Some don’t even properly understand client-server anymore, which is… wild. That’s like being a mechanic who doesn’t know what an engine does, but has strong opinions about paint color.
Security Isn’t A Checkbox, It’s A Relationship
If you build it, you can inspect it. You can reason about it. You can patch it right now.
If you download it, you inherit:
- unknown code quality
- unknown security posture
- unknown update discipline
- unknown long-term compatibility
And even if the third-party project is good, the real risk is the ecosystem around it: dependencies, plugins, integrations, random abandoned packages that are still installed because “it works”.
A lot of attacks don’t happen because someone wrote genius malware. They happen because your stack is a Jenga tower and someone removed a block.
Creating Teaches You The Stuff You Can’t Fake
The most underrated part of building your own things is learning and life lasting effect.
When you replace libraries piece by piece, class by class, function by function - you’re forced to understand:
- how the platform actually behaves
- how networks and systems fail
- what “slow” really means (and where it comes from)
- what matters to users (and what doesn’t)
That knowledge sticks. It becomes an imprinted understanding, your nature, you will see the Matrix.
And in a post-AI age, that imprint is the real value. AI can output code. It can’t give you judgement for free. The people who stay relevant are the ones who can look at AI output and instantly spot:
- what’s unnecessary
- what’s risky
- what will break under load
- what will become unmaintainable in 6 months
You only get that by building and owning systems.
Ownership: Mental, Legal, Practical
Ownership isn’t just “we have the source”.
It’s also mental ownership - you know how the system works, so you can confidently change it without fear.
And it’s practical ownership - when something breaks, you don’t wait for “next patch”. You fix it. You ship. You’re in control.
This is also why I love custom stacks for client work. With our approach, I basically never had to tell a client:
“No, we can’t do this, the software doesn’t allow it.”
We talk about needs. Then we talk about cost and viability. That’s it. No artificial limitations imposed by someone else’s design decisions.
“But Maintenance…”
This is the classic objection and honestly, it’s overstated.
With your own code, maintenance is usually:
- fix what’s buggy
- expand what you actually need
- improve what you want to improve
That’s it. It’s incremental. It follows reality. It’s very rarely as time consuming as people imagine.
Yes, it’s work. But it’s also compounding value, because every improvement becomes part of your permanent toolset - in technical sense and understanding.
A Simple Rule That Actually Works
I’m not saying “never use anything”.
I’m saying: be intentional.
Use external tools when they are:
- proven and battle-tested
- narrow in scope
- hard to do correctly yourself
- stable in behavior (not opinionated magic)
OpenSSL, FFmpeg, maybe a database engine, some image codecs, sure.
But if the “tool” is basically a whole worldview that replaces your understanding of the platform… that’s where you start losing things.
And eventually you lose the ability to say “yes” to a client with confidence.
That’s a brutal trade.
So yeah - creating is slower at the start. But it buys you something most developers don’t have anymore: control.
And control is the foundation of quality.
If you keep building, even gradually, you don’t just ship software. You become the kind of person who can stand behind it.
Final words
I’m not saying “people who use tools are bad”. Some developers go deep in whatever they use. They understand trade-offs, strip what they don’t need, and treat a framework as a starting point, not a religion. That’s great engineering.
What worries me is cargo-cult development: copying stacks because they’re popular, shipping black boxes, and hoping performance and security will magically work out, or not thinking about them at all.
For us, building our own stack has been the opposite: high performance, predictable behavior, and the ability to say “yes” to client needs without being blocked by someone else’s constraints. That’s the approach I’m sticking with, because it’s the only one I can actually stand behind.
Top comments (1)
What are your experiences?