The Missing Third Option
Every engineering team has a version of this conversation: should we build this ourselves or buy a solution? The problem is this question frame is incomplete. There's a third option that no one names explicitly, and it usually is the right answer. The option is tolerate. Tolerate the imperfection, ship with a manual process, accept the slightly-broken workflow, build what you have time for and stop.
Engineering organizations that make this distinction clear end up shipping faster and spending less on things that don't matter. Organizations that don't end up with sprawling internal tools, half-built custom solutions, and endless maintenance debt on systems nobody uses.
Which Decisions Compound?
The key is understanding what compounds and what doesn't. A decision compounds when each iteration builds on the previous one, when making it once influences the next hundred times you face a similar decision, and when the infrastructure you build enables future capability that wouldn't exist otherwise.
Decisions that compound
- API design. Get it wrong the first time, and every consumer carries that cost forever. You'll retrofit, deprecate, manage versions. It compounds for years.
- Batch processing infrastructure. Once you have good batch systems, every new data workflow is faster and cheaper to build.
- Deployment pipelines. Better tooling reduces friction on every single deployment. The investment pays back continuously.
- Logging and observability. The better your foundation, the faster you debug every production issue. The value increases over time.
Decisions that don't compound
Your project management system doesn't compound much. Lots of tools work, you'll likely switch eventually, and the productivity difference between two competent tools is often smaller than teams imagine. Building a "perfect" internal replacement is usually waste. Your internal sales deck template doesn't compound. Your expense reporting process doesn't compound. Your internal wiki that nobody reads doesn't compound.
The Hidden Cost of Building
Teams consistently underestimate what it costs to build something custom.
- Engineering time. A senior engineer is typically a six-figure annual cost once salary, benefits, and overhead are included. A system that takes 3 months to build can easily cost tens of thousands in direct labor alone, before maintenance.
- Maintenance. The initial build is rarely the full cost. That "simple tool" you built in 2024 still needs fixes, upgrades, and ownership in 2025, 2026, and beyond.
- Knowledge concentration. The person who built it knows how it works. If they leave, someone else has to learn it. That's context switching, slow debugging, and misunderstood assumptions.
- Opportunity cost. Every hour on internal tooling is an hour not on product, not on features that ship to customers, not on the work that matters to your business. This cost is invisible but real.
The Hidden Cost of Buying
Buying sounds simpler until you operate it.
- Integration overhead. Your new tool doesn't connect perfectly. You write custom ETL. You hire someone to maintain it.
- Vendor lock-in. You adopt a tool deeply, then the vendor raises prices sharply, deprecates a feature, or gets acquired and the product dies. You're stuck migrating at painful cost.
- Feature gap. The tool does 80% of what you need. That last 20% requires custom extensions that now need maintenance.
- Ongoing cost. $10k/month for a tool that 50 people use is $200/person/month. That adds up.
- Flexibility loss. You're locked into someone else's roadmap. When your needs change, you're blocked by a vendor release cycle.
The Framework
When you face a build vs buy decision, ask this in order:
1. Does this compound?
Will investing here enable future capability that wouldn't exist otherwise? If no, don't build.
2. Is this core to our strategy?
Is it a source of competitive advantage, or does getting it wrong directly lose customers? If no, buy or tolerate.
3. What do we lose with an 80% solution?
If we tolerate an imperfect solution, how much revenue, reliability, or speed do we actually lose? If the answer is "not much," tolerate.
Applying the framework
Build when the problem is core to your product: authentication, core data pipelines, your deployment system, recommendation engines that differentiate you. Ask: if we owned this and optimized it, would we be measurably faster, cheaper, or more reliable?
Buy when the problem is solved generically and 80%+ good enough: project management, payment processing, HR systems, communication tools, analytics infrastructure (unless analytics is your product).
Tolerate when the problem is small and the imperfect solution is acceptable: a project management tool that's 70% good, slightly broken support workflows affecting few customers, manual processes for operations that happen once a month, imperfect data that doesn't change your decisions.
The Takeaway
Most teams would ship faster, spend less, and focus better if they tolerated more problems instead of solving everything with custom infrastructure. Perfect is the enemy of shipped. Tolerate what doesn't matter. Build what does. Buy everything else.