Building vs. Buying: Making Smart Technology Decisions
The build-or-buy question answers itself more often than people think. Where it genuinely does not, and how to tell the difference before you commit.
Part 6 of 12 in From Manual to Digital.
One of the most consequential decisions any technology leader faces isn’t about which programming language to use or which framework is trending. It’s far more fundamental: should we build this ourselves, or should we buy an existing solution?
Get this decision wrong, and you’re looking at months of wasted effort, blown budgets, and frustrated teams. Get it right, and you’ve positioned your organisation for sustainable growth and competitive advantage.
Over two decades in software development, from architecting enterprise solutions in financial services to managing cloud infrastructure serving over a billion monthly users, I’ve been on both sides of this decision countless times. I’ve seen custom builds that became strategic assets, and I’ve seen them become expensive albatrosses. I’ve seen off-the-shelf purchases that transformed operations, and I’ve seen them gather digital dust.
Here’s what I’ve learned about making this decision well.
The Real Question Behind Build vs. Buy
Most organisations frame this as a cost question: “What’s cheaper, building or buying?” That’s the wrong starting point.
The real question is: “Where does our competitive advantage come from?”
Early in my career, I worked on a global trading platform integration for a major financial institution. The organisation needed to connect an external vendor’s application into their existing banking infrastructure. The smart decision wasn’t to build a competing trading platform from scratch that would have taken years and millions, competing against vendors who’d been perfecting their solutions for decades.
Instead, the strategic value lay in how we integrated that platform. We designed a scalable architecture that maintained consistent performance whether ten users or a thousand were on the system simultaneously. The vendor provided the trading capability; we created the seamless experience that differentiated the bank from its competitors.
That’s the build vs. buy sweet spot: buy what’s commoditized, build what differentiates.
A Framework for the Decision
After years of making these calls, I’ve developed a decision framework that cuts through the noise. Here are the five questions I ask:
1. Is this core to our competitive advantage?
If the capability directly impacts how you win in the market, lean toward building. If it’s necessary but doesn’t differentiate you, lean toward buying.
When I led a team through an eighteen-month console migration for cloud infrastructure serving over a billion users, building was the only option. The user experience of that console was the product. Buying something off the shelf would have meant ceding control of the customer experience to a third party.
Contrast that with internal tools like project management or communication platforms. These need to work well, but they rarely differentiate your business. Buy them.
2. Does a mature solution already exist?
Sometimes the build vs. buy question answers itself. If there’s a well-established market of solutions that do exactly what you need, the burden of proof shifts heavily toward buying.
I’ve seen organisations spend eighteen months building internal tools that replicate functionality available for a few hundred dollars per month. The justification is usually “we need it customized to our specific needs.” But often, those customization requirements shrink dramatically when you actually evaluate what’s available.
Before committing to build, do genuine market research. Not a quick search, a proper evaluation. You might be surprised what exists.
3. Do we have the capability to build and maintain this?
Building something is only half the equation. You also need to maintain it indefinitely.
I’ve managed teams where we inherited custom-built systems that no longer had anyone who understood them. The original developers had moved on, documentation was sparse, and every change became an archaeological expedition. The “cheap” custom build became extraordinarily expensive over time.
If you’re going to build, you need committed, long-term ownership. That means documentation, knowledge transfer, and a maintenance roadmap that extends years into the future.
4. What’s our time horizon?
Buying is almost always faster. If you need something operational in weeks rather than months, buying wins.
But if you’re thinking in years, the calculus changes. A purchased solution that meets 80% of your needs today might meet only 60% in two years as your requirements evolve. Meanwhile, a custom build that takes longer initially might serve you better over a five-year horizon.
During my time leading a technology consultancy, we’d often have clients push for rapid custom development when an off-the-shelf solution would have served them better. The desire to have “exactly what we want” led to longer timelines and higher costs than simply adapting their processes to fit a proven solution.
5. What are the integration requirements?
This is where many decisions go sideways. A solution might look perfect in isolation but become a nightmare when you need to connect it to existing systems.
I spent years in financial services where integration complexity was paramount. Every new system needed to talk to legacy platforms, comply with regulatory requirements, and maintain audit trails. A vendor solution that couldn’t integrate cleanly was worse than useless it created data silos and operational friction.
Before committing to any path, map out the integration requirements in detail. What systems does this need to connect to? What data flows are required? What happens when the connection fails?
The Cloud Platform Question
One specific build vs. buy decision deserves special attention: cloud infrastructure.
The question isn’t really whether to use cloud platforms, for most organisations, that ship has sailed. The question is how deeply to embrace platform-specific services versus maintaining portability.
Major cloud providers offer incredible capabilities. Managed databases, serverless computing, machine learning services, global content delivery all available without building and maintaining the underlying infrastructure yourself. These services can dramatically accelerate development and reduce operational burden.
But they come with a trade-off: the deeper you go into platform-specific services, the harder it becomes to move to a different provider later.
From my experience managing cloud infrastructure at scale, here’s my guidance:
Embrace platform services for:
- Compute and storage fundamentals
- Managed databases for non-critical workloads
- Development and testing environments
- Services where the platform’s scale genuinely benefits you
Maintain portability for:
- Core business logic and proprietary algorithms
- Customer data and critical databases
- Integration layers between systems
- Anything that represents genuine competitive advantage
The goal isn’t to avoid platform services entirely, that’s leaving value on the table. It’s to be intentional about where you create dependencies.
Integration: The Hidden Complexity
Whether you build or buy, integration is where projects succeed or fail.
I’ve managed migrations that touched thirty-three commercial regions with zero downtime. The technical challenge wasn’t the new system, it was maintaining the legacy system while building the new one, then orchestrating the transition without interrupting service.
Every integration project I’ve led has reinforced the same lessons:
Plan for coexistence. You’ll almost never switch everything at once. Budget time and resources for running parallel systems during transition.
Define clear data ownership. When multiple systems touch the same data, someone needs to be the source of truth. Ambiguity here causes downstream chaos.
Build robust error handling. Integrations fail. Networks hiccup, APIs change, data formats drift. Design for graceful degradation, not just happy paths.
Document everything. Six months from now, someone will need to understand why a particular integration works the way it does. Make their life easier.
Making the Call
There’s no universal right answer to build vs. buy. Context matters enormously.
But I’ve found that organisations consistently err in one direction: they overbuild. The allure of “exactly what we need” leads to custom development that takes longer, costs more, and requires ongoing maintenance that wasn’t budgeted.
My default bias is toward buying, with building reserved for genuine differentiation. When I ran my own consultancy, this sometimes meant recommending against custom development even though that was how we made money. But the right answer for the client was to implement existing solutions, not create new ones.
The best technology leaders I know are ruthless about this distinction. They build where it matters and buy everywhere else. They resist the temptation to over-engineer and the ego satisfaction of “we built that ourselves.”
Your Decision Checklist
Before your next build vs. buy decision, work through these questions:
- Does this capability directly impact our competitive position?
- What mature solutions already exist in the market?
- Do we have the team and commitment for long-term maintenance?
- What’s our realistic timeline, and which path fits it?
- What integration complexity does each path create?
- Where are we creating vendor dependencies, and are we comfortable with them?
- What’s the total cost of ownership over five years, not just initial cost?
The organisations that make smart technology decisions aren’t necessarily the ones with the biggest budgets or the most talented engineers. They’re the ones who ask the right questions before committing resources.
Build what differentiates you. Buy what doesn’t. Integrate thoughtfully. And always, always plan for the maintenance burden that comes after the initial excitement fades.
This first appeared on LinkedIn in December 2025. This is the canonical version.