Back in 2015, I joined a product company whose platform had been evolving since late 90's. Coming from a startup background, I was overwhelmed by the number of in-house tools, and platforms that existed alongside the core product.
Over time and after leaving the organization in 2023 — I began to appreciate the trade-offs behind those build decisions. Some became strategic assets, while some introduced years of ownership and maintenance overhead.
This article shares some of the lessons I learned about one of the most important engineering decisions teams make: build or buy.
Over the years, I've come to believe that some of the most expensive engineering mistakes have very little to do with technology itself.
They start with a much simpler question:
Should we build this ourselves?
Or should we buy it?
At first glance, the answer often feels obvious. A team identifies a need.
Maybe it's:
- authentication,
- workflow orchestration,
- internal developer portals,
- database migration tool, or
- some internal framework.
Someone says:
"We can build this in a few weeks."
Often, they're right. The first version usually isn't that difficult. The real challenge comes later. Because every build decision eventually becomes an ownership decision.
And ownership tends to last much longer than implementation.
Over the years, I've seen teams successfully build internal platforms that became strategic assets. I've also seen teams accidentally become software vendors to themselves.
The interesting question isn't whether we can build something. Modern engineering teams can build almost anything.
The more important question is:
Do we want to own it for the next five years?
1. Why This Decision Matters
A decade ago, many engineering teams had fewer choices. But today, the situation is completely different.
Almost every technical capability has mature products available.
Say, you need:
- authentication?
- observability?
- workflow orchestration?
- developer portals?
There is probably a vendor already solving that problem, that's what makes the decision difficult.
Because modern engineering teams are no longer choosing between having a capability, or not having one.
They're choosing between:
- building it,
- extending it,
- buying it, or
- integrating it.
The number of options has increased. At the same time, engineering capacity remains limited. Teams hit decision paralysis.
Every sprint spent building internal tooling is a sprint not spent building customer-facing capabilities.
This trade-off becomes increasingly important as organizations grow. Especially when platform investments start competing with product investments.
2. The Hidden Cost Teams Ignore
One pattern I've noticed is that teams are usually good at estimating development effort. They're much less effective at estimating ownership effort.
A discussion might sound like this:
This looks straightforward. We can probably build it in three weeks.
Probably they're right. The problem is that the three-week estimate usually covers only Version 1.
It rarely includes:
- upgrades,
- support,
- operational maintenance,
- bug fixes,
- security reviews,
- documentation,
- on-boarding,
- scalability improvements, and
- future requirements.
Those costs appear gradually which makes them easy to underestimate.
- Building Is Easy. Owning Is Hard
Many internal systems begin life as small engineering utilities. Gradually adoption grows. Soon other teams depend on them.
Now expectations change.
The platform suddenly needs:
- up-time guarantees,
- backward compatibility,
- support processes, and
- clear ownership.
What started as an engineering project slowly becomes a product except now the customers are internal teams.
I've seen this happen with:
- internal frameworks,
- workflow engines,
- authentication services, and
- developer portals.
The implementation wasn't the difficult part but the long-term ownership was.
- The Internal SaaS Trap
One of the most interesting things about platform engineering is that organizations sometimes become software vendors without realizing it.
Imagine a team builds an internal feature flag platform.
Version 1.0 supports simple enable/disable toggles. Seems pretty straightforward.
Then adopted teams raise feature requests like percentage roll-outs, audit logs, experimentation, approval workflows.
Now the platform team is effectively running a software product. Except instead of external customers, they're supporting internal engineering teams.
The complexity didn't disappear. It simply became your responsibility.
- Opportunity Cost Is Real
This is probably the most overlooked factor in build-versus-buy discussions.
Suppose five engineers spend six months building an internal platform.
The direct cost is obvious but another question is often ignored:
What didn't get built during those six months?
Perhaps:
- product features were delayed,
- customer requests remained unresolved,
- roadmap commitments slipped.
These costs rarely appear in dashboards. Yet they often have a larger business impact than infrastructure costs.
3. Why Engineering Teams Choose To Build
Despite the risks, engineering teams continue to build internal solutions. There are good reasons for that, not every build decision is a mistake.
Some become enormous competitive advantages.
The challenge is understanding why we are choosing to build in the first place.
- Engineers Like Solving Problems
This shouldn't surprise anyone.
Most engineers enjoy creating systems, and building software feels productive and empowering. It provides a level of control that third-party products cannot. When requirements are unique, building can absolutely make sense.
The problem appears when technical enthusiasm replaces strategic evaluation.
Just because something is technically interesting doesn't automatically mean it should be owned long-term.
- Vendor Skepticism
Many teams have legitimate concerns about vendors.
Questions such as:
- What if pricing changes?
- What if the company gets acquired?
- What if we're locked in?
- What if customization becomes difficult?
These concerns are real. Sometimes they justify building.
But I've also seen teams dramatically overestimate vendor risks while underestimating ownership risks.
Both sides deserve equal scrutiny.
- The "It Looks Simple" Fallacy
Some capabilities appear deceptively simple.
Authentication is a classic example.
At first glance:
- users log in,
- users log out,
- passwords are stored.
Simple, until requirements expand:
- OAuth
- SAML
- MFA
- SSO
- compliance
- account recovery
- security reviews
Suddenly the original problem looks very different.
Version 1 is usually easy. Version 10 is where the complexity appears.
4. Where Companies Successfully Build
It might sound like buying is always the safer option, No. Many of the most successful technology companies built substantial internal platforms.
The difference is that they usually built capabilities closely tied to their competitive advantage.
Build What Makes You Different
One repeated pattern among successful engineering organizations is that they build things that are core to their business. Not things that are merely useful.
This distinction matters.
- Netflix Didn't Win By Building Authentication
Netflix became successful because of:
- streaming infrastructure,
- recommendation systems,
- content delivery,
- personalization.
Those capabilities directly influenced the business.
Investing heavily in them made strategic sense. Authentication was necessary. Recommendation systems were differentiating.
The difference is important.
- Uber Didn't Buy Dispatching
Dispatching is central to Uber's business.
The way drivers and riders are matched directly affects customer experience, efficiency, profitability.
That capability is core business logic.
Owning it provides competitive advantage. Buying it would have limited differentiation.
- LinkedIn Built Kafka
Kafka began as an internal project at LinkedIn to solve large-scale event streaming challenges. At the time, existing messaging systems struggled to handle the volume, durability, and scalability requirements of LinkedIn's growing platform.
Building Kafka made sense because reliable event streaming was becoming a foundational capability for the business. What started as an internal solution eventually evolved into one of the most widely adopted distributed systems in the industry.
The lesson isn't that every company should build its own messaging platform. The lesson is that LinkedIn built a capability that directly addressed a strategic problem at its scale.
- Google Built Kubernetes
Kubernetes originated from Google's experience running massive distributed systems over many years. Google had already developed internal container orchestration platforms and operational practices long before containers became mainstream.
Rather than adapting existing solutions, Google built Kubernetes based on lessons learned from operating infrastructure at enormous scale.
For most organizations, building a container orchestration platform would be a terrible investment. For Google, infrastructure management was a core competency and strategic advantage.
The takeaway is simple:
Build when the capability is closely tied to your unique scale, business model, or competitive advantage.
The Common Pattern
The most successful build decisions usually share a characteristic:
The capability directly contributes to competitive advantage.
When that's true, ownership often makes sense. When it doesn't, the equation changes dramatically.
5. The Platform Engineering Perspective
Over the last few years, platform engineering has become a major focus area for many organizations. The goal is to make developers more productive.
Provide:
- self-service capabilities,
- deployment automation,
- observability,
- infrastructure provisioning, and
- standardized workflows.
The challenge is deciding how much of that platform should be built internally.
This is where build-versus-buy decisions become particularly interesting.
- The Internal Developer Platform Dilemma
Imagine a growing engineering organization.
Developers complain about:
- inconsistent environments,
- deployment complexity,
- on-boarding difficulties.
The organization decides to build an Internal Developer Platform. The initial vision sounds reasonable.
A central portal where developers can create services, access documentation, provision resources, monitor deployments. But soon new requirements emerge:
- RBAC
- audit logs
- integrations
- workflow automation
- plugin ecosystems
Before long, the platform itself becomes a product.
- The Backstage Lesson
Many organizations faced this exact challenge.
Instead of building an entire developer portal from scratch, they adopted existing platforms and customized them.
This approach is interesting because it reflects a broader engineering principle:
Buy the foundation. Build the differentiation.
The organization still owns the developer experience. It avoids spending years recreating foundational capabilities.
- Build The Last 20%
One of the most useful heuristics I've encountered is this:
Buy the first 80%. Build the last 20%.
The first 80% usually consists of commodity functionality. The last 20% often contains:
- business-specific workflows,
- domain integrations,
- unique operational requirements.
That final layer is often where competitive advantage exists. It's usually a better place to invest engineering effort.
6. A Practical Decision Framework
Over time, I've found that build-versus-buy discussions become much easier when evaluated through a consistent framework.
Rather than debating technologies, the conversation shifts toward business and ownership.
Here are some of the questions help to make decision.
Question 1: Does This Differentiate The Business?
This is one of the most important question.
If the capability disappeared tomorrow, would customers notice?
Would it impact the company's competitive position?
For example:
Building recommendation engines, pricing algorithms, matching engines, or domain-specific workflows often creates differentiation.
The closer a capability is to competitive advantage, the stronger the case for building.
Question 2: Do We Want To Own This In Three Years?
Most build decisions focus on implementation.
Few focus on ownership.
A better question is:
Will we still want to maintain this three years from now?
Ownership includes:
- upgrades,
- security,
- operational support,
- bug fixes,
- documentation,
- compliance,
- training.
If the answer feels uncomfortable, that is valuable information.
Question 3: Can We Support It Operationally?
Every system eventually enters production and production changes everything.
A build decision also means committing to on-call support, incident response, monitoring, maintenance, and/or disaster recovery.
The engineering effort doesn't end when the code is deployed. In many cases, that's where the real work begins.
Question 4: Is The Market Mature?
Sometimes buying is difficult because the market is immature. The available products may not solve the problem adequately.
But in mature categories observability, authentication, feature management and workflow orchestration vendors have often spent years refining their solutions.
Ignoring that accumulated expertise can be expensive.
Question 5: What Is The Opportunity Cost?
This question is frequently overlooked.
Suppose a team spends six engineers, six months, building an internal capability.
The direct cost is obvious but opportunity cost is harder to measure.
What customer-facing work was delayed?
What revenue-generating features were postponed?
What strategic initiatives slowed down?
Sometimes the most expensive cost is the one that never appears in a budget report.
7. The Hybrid Model Usually Wins
One thing I've noticed is that the engineering organizations rarely choose a pure build or pure buy strategy.
Instead, they combine both.
- Buy The Foundation
Commodity capabilities are often purchased or adopted. These tools solve common problems that many organizations face.
Rebuilding them rarely creates differentiation.
- Build Business-Specific Layers
The organization's engineering effort is then focused on:
- business workflows,
- domain models,
- operational processes,
- customer-facing capabilities,
- proprietary integrations.
This is where engineering investment usually generates the highest return.
- Why This Works
The hybrid model captures the advantages of both approaches.
Organizations avoid:
- rebuilding mature capabilities,
- unnecessary ownership burden,
- platform reinvention.
At the same time, they retain flexibility where it matters most.
8. Common Mistakes Teams Make
Most build-versus-buy failures follow surprisingly similar patterns. The technology might change but the mistakes rarely do.
- Underestimating Maintenance
Teams usually estimate 'Initial Build Cost' while forgetting support, upgrades, security and operations. Over a multi-year horizon, ownership often exceeds implementation cost.
- Rebuilding Commodity Software
This is probably the most common mistake.
Engineering teams are highly capable. Given enough time, they can rebuild almost anything. The question is whether they should.
- Optimizing For Engineering Preference
This is a subtle trap.
Engineers naturally enjoy building systems. But engineering satisfaction and business value are not always aligned.
A technically elegant solution can still be a poor investment. The best technical decision is not always the best business decision.
- Assuming Vendors Never Improve
Many build decisions are based on current vendor limitations but products evolve. Markets mature gradually and capabilities improve. A solution that looked inadequate two years ago may look very different today.
Periodic re-evaluation is important.
9. AI Is Changing The Economics
It's impossible to discuss build-versus-buy decisions today without mentioning AI. AI-assisted development has significantly reduced implementation effort. Many teams can now prototype internal tools faster than ever.
Capabilities that once required months of development can sometimes be assembled in days.
- Building Is Cheaper Than Before
AI helps with:
- scaffolding
- code generation
- testing
- documentation
- integration
The barrier to building has unquestionably decreased.
- Ownership Has Not Become Cheaper
This is the important distinction.
AI can help create software. It does not eliminate:
- operational support
- on-call responsibility
- compliance
- security
- upgrades
- platform ownership
The cost of creation is decreasing. The cost of ownership remains surprisingly stable. That means ownership becomes even more important in future build-versus-buy discussions.
10. Final Thoughts
One of the biggest lessons I've learned is that build-versus-buy decisions are rarely technology decisions.
They're ownership decisions.
Modern engineering teams can build almost anything. Open-source ecosystems are thriving. Cloud platforms provide powerful building blocks.
AI accelerates development even further.
The question is no longer: Can we build it?
The more important question is: Do we want to own it?
Because every build decision creates a long-term commitment. A commitment to maintenance, operations, support, upgrades, and continuous evolution.
Sometimes that commitment is absolutely worth making especially when the capability creates competitive advantage. Other times, the smarter decision is to leverage what already exists and focus engineering effort where it matters most.
In the end, the most successful engineering organizations aren't the ones that build everything. They're the ones that understand what is truly worth owning.
Assisted ChatGPT to rephrase.