Build vs. Buy: The Framework We Use to Decide What to Build In-House
Direct answer: We build in-house when the capability is a customer-facing differentiator or encodes our unique business rules; we buy (or adopt first-party packages) when the problem is commodity infrastructure — payments, auth primitives, email delivery — because the maintenance tax of owning commodity code is usually higher than the license or SaaS fee.
This is how we decide at MarginTop Solutions, whether the product is ours or a client's. And the framework has saved us from some genuinely expensive mistakes.
Why the wrong call is so expensive
Marc Andreessen's observation that "software is eating the world" gets quoted a lot. Less quoted is the corollary that applies to product teams: building software you don't need to is eating your engineering capacity.
A 2019 McKinsey study found that software projects that attempt to build differentiated capabilities and commodity infrastructure simultaneously take 40–60% longer and deliver fewer business outcomes per dollar spent. The problem isn't that engineers are slow — it's that context-switching between domain problems (complex, valuable) and infrastructure problems (complex, commodity) destroys focus and creates systems that are mediocre at both.
The two-question filter
We apply two questions to every "should we build this?" conversation:
- Differentiator or commodity? Would a client or customer choose us specifically because of this capability? Would losing it differentiate us negatively? If the answer is no — if any of our competitors can access the same thing for $X/month — it's a commodity.
- Who feels the maintenance tax? Security patches, PCI surface area, edge cases, on-call paging, version upgrades — if that maintenance is related to our unique value, it's worth owning. If it's incidental to our value, it's a tax we're choosing to pay unnecessarily.
Decision matrix with real examples
| Capability | Differentiator? | Our call | What we actually own |
|---|---|---|---|
| Payment processing mechanics | No | Buy: Stripe + Cashier | Pricing packages, entitlement rules, upgrade logic |
| Auth token/session primitives | No | Buy: Sanctum | Permission matrices, tenant isolation, role inheritance |
| Email/SMS delivery | No | Buy: Postmark / Twilio | Notification content, trigger logic, audit trails |
| Search indexing | Sometimes | Buy: Meilisearch/Scout | Schema design, ranking rules, domain-specific filters |
| Domain workflow engine | Yes | Build | State machines, approval flows, business rule enforcement |
| Reporting / analytics for customers | Yes | Build (query layer) + Buy (charts) | Metric definitions, access control, data models |
| Internal admin tooling | No | Buy: Filament / Retool | Custom actions, business-specific workflows on top |
The maintenance tax nobody budgets for
The honest cost of building commodity infrastructure is rarely calculated upfront. Here's what gets forgotten:
- Custom auth that almost passes SOC-ish checklists — until an edge case exposes a session management bug six months later, and the "security audit" becomes a crisis instead of a checkbox.
- Homegrown payment state machines — built by an engineer who understood Stripe at the time, and now diverging from Stripe's actual behavior on refunds, disputes, and SCA because nobody was watching those changelogs.
- Internal "platform" libraries with one maintainer and twelve dependents — a single bus factor that blocks every team when that engineer takes a long weekend.
- The upgrade tax. Every library you own needs to track security advisories. For commodity infrastructure like auth, that's full-time work at a security-competent company. You probably don't have a full-time auth security engineer. Proven open-source packages have hundreds of contributors watching for issues.
When the calculus flips
The buy default has limits. Cases where we build despite commodity-ish territory:
- The vendor doesn't actually solve our problem. Off-the-shelf multi-tenancy solutions often make assumptions that don't match our specific tenant-isolation model. Custom is cheaper than fighting abstractions.
- The SaaS cost exceeds build cost at our scale. Some tools that are cheap at launch become expensive at scale. We model the crossover point before committing.
- Strategic differentiation emerges from a previously-commodity capability. The framework is not static — if a capability that was commodity becomes a differentiator, we reconsider.
That tax shows up in hiring too — see what I look for when hiring. We want engineers owning product outcomes, not babysitting commodity plumbing.
Key takeaways
- The decision is differentiator vs. commodity — not "is this technically possible to build."
- The full maintenance tax (security patches, upgrade cycles, on-call, bus factors) is rarely calculated upfront. Do the math.
- Proven packages and SaaS tools for commodity concerns free engineering focus for domain problems that actually compound into competitive advantage.
- The framework is not a one-time call — revisit when vendor costs scale, when SaaS abstractions fight your domain, or when a capability genuinely becomes a differentiator.
Trying to figure out what to build vs. buy on your product? Get in touch — this is a conversation we have with every client engagement at MarginTop.