Monday Myth: You Must Build Everything Yourself
There is a persistent myth in software organisations that real engineering means building everything in‑house. Infrastructure, authentication, payments, analytics, experimentation frameworks, internal tools, if it exists, some teams believe they should own it.
This belief sounds noble. It flatters engineering egos. It creates the illusion of control.
And it quietly sabotages strategy.
The Core Fallacy
The myth assumes that building equals value. It does not.
Value comes from delivering your core business outcomes faster, safer, and with less friction than alternatives. Anything that does not directly reinforce that advantage is, at best, a distraction. At worst, it becomes a long‑term liability.
Imagine if every e‑commerce company decided to build its own payment system.
Some actually do.
Not because it is strategically differentiating, but because they can. Or because “we do not want to depend on vendors.” Or because “it is an interesting engineering challenge.” None of these are business arguments. They are comfort arguments.
Strategy Dilution by Construction
At a strategic level, building everything bloats focus.
Time and talent are finite. Every week spent reinventing a solved problem is a week not spent improving conversion, reliability, fraud detection, supply chain efficiency, or customer trust, whatever your real advantage is supposed to be.
The result is predictable:
- Roadmaps grow horizontally instead of vertically
- Core products stagnate while internal systems expand
- Execution slows while complexity rises
This is not innovation. It is dispersion.
A company that tries to be excellent at everything usually ends up mediocre at the thing that matters.
Tactical Self‑Indulgence
On a tactical level, this myth reveals itself as self‑indulgence.
Building in‑house systems often leads to:
- Custom solutions with no clear exit strategy
- Over‑engineered abstractions with unclear ownership
- Systems maintained “by the person who built it”
That last point is critical.
You end up with one‑person software armies. Knowledge concentrates. Documentation lags. When that person leaves, the system becomes radioactive: nobody dares to touch it, yet everyone depends on it.
This is how legacy forms, not through age, but through isolation.
The Hidden Cost: Cognitive Load
Every internally built system adds cognitive load.
Engineers must understand it.
They must operate it.
They must debug it at 3 a.m.
They must evolve it while delivering product work.
Even excellent engineers burn out under this weight. Not because the work is hard, but because it is misaligned. They are solving infrastructure problems instead of customer problems.
This erosion of alignment is dangerous: it strips away sense of purpose, replaces impact with maintenance, and quietly pushes strong engineers towards disengagement and eventual attrition.
Delivery slows, change becomes risky, and experimentation fades not because teams lack skill, but because the work no longer feels meaningful. The silent exit begins long before the resignation letter. Organisations then optimise for safety rather than progress.
All because someone once said: “Let us build it ourselves.”
What This Says About Product Strategy
This myth also exposes weak product thinking.
A strong product strategy answers three questions clearly:
- What is our differentiating advantage?
- What must we excel at internally to protect it?
- What should we deliberately not build?
When everything becomes a candidate for in‑house development, it usually means these questions were never answered.
Engineers then fill the vacuum. They build because no one framed trade‑offs. No one articulated boundaries. No one said: this is not our fight.
That is not an engineering failure. It is a leadership failure. When no one has the courage to decide what truly matters, everything becomes fair game for in‑house construction, and strategy dissolves into activity.
Engineers Are Not the Problem
Engineers often get blamed for “over‑engineering.” That is lazy.
Engineers optimise for the constraints they are given. When building everything is framed as craftsmanship, heroism replaces judgement, and lone‑wolf systems quietly masquerade as excellence. If leadership rewards ownership without direction, engineers will own everything. If curiosity is praised but focus is not enforced, complexity will grow.
Awareness matters.
Senior engineers should be able to challenge: Why are we building this? What business risk does it mitigate? What opportunity cost does it introduce? What happens if we stop maintaining it?
But they can only do that if strategy exists and is visible.
Real‑World Proof: Build Everything and Lose, Delegate and Win
This is not theory. We have seen this pattern play out repeatedly.
When Companies Tried to Build Everything ... and Paid the Price
Nokia did not lose because it lacked engineering talent. It lost because it tried to own too much of the stack like custom operating systems, tooling, and platforms, while the market shifted toward ecosystems. Engineering effort was spread thin across internal complexity instead of focused on user experience and platform leverage. Strategy dissolved into internal optimisation.
BlackBerry doubled down on in‑house systems, proprietary platforms, and internal infrastructure long after the battle had moved to developer ecosystems and application velocity. Control was preserved. Relevance was not.
Yahoo famously rebuilt internal tools, ad platforms, and infrastructure repeatedly, often replacing perfectly serviceable external solutions. Execution energy went inward. Meanwhile, product coherence and market clarity eroded.
In all three cases, the failure mode was the same: engineering excellence without strategic restraint.
When Companies Delegated Commodity Work ... and Won
Stripe exists precisely because most companies should not build payment systems. The companies that adopted Stripe early shipped faster, expanded globally sooner, and focused their engineering talent on customer‑visible differentiation instead of compliance and edge cases.
Shopify deliberately did not rebuild everything. Payments, hosting, analytics, logistics partnerships, all delegated where possible. The result was relentless focus on merchant success, not internal plumbing.
Internally, Amazon learned to separate what was core from what was reusable. Teams stopped rebuilding undifferentiated infrastructure and consumed shared services. Speed increased because control was constrained.
The pattern is consistent: winners protect engineering focus by delegating the non‑essential.
Build Less. Decide More.
The alternative is not blind outsourcing. It is intentional construction.
Build internally when:
- It is core to your differentiation
- It materially impacts your business model
- External solutions constrain your strategy
Adopt or buy when:
- The problem is well‑understood and commoditised
- The cost of maintenance exceeds strategic value
- Reliability and compliance are table stakes
This requires discipline. Saying no is harder than building. It requires leaders to protect focus and engineers to accept boundaries.
The Real Engineering Maturity
Engineering maturity is not measured by how much you build. It is measured by how well you choose what not to build.
Mature organisations subtract with intent. Immature ones accumulate with pride.
Focus beats pride. Strategy beats curiosity. Outcomes beat elegance.
If your teams are drowning in internal systems while your core product stagnates, the problem is not technical debt.
It is a myth left unchallenged.
Monday Myth debunked.
Member discussion