The build-vs-buy question gets answered wrong in both directions. Scrappy teams build things they should have bought, wasting six months reinventing Stripe. Enterprise teams buy things they should have built, ending up with a duct-taped stack of ten SaaS products that cost more than a full-stack engineer.
The real answer depends on five questions most decision frameworks don't ask. This guide is a practical walkthrough for anyone trying to figure out the right call for their own business.
The Myth That Distorts Every Build-vs-Buy Conversation
"Buying is cheaper."
This is the default assumption, and it's wrong often enough to be dangerous. Buying looks cheaper because the cost is monthly instead of upfront -- a psychological trick, not an economic one.
Run the numbers on any SaaS tool over 5 years and you'll usually find the cost lands within 2x of building custom. Sometimes below. The real cost difference is not price; it's time, flexibility, and ownership.
When you buy:
- You spend less today, more in year 3
- You get speed now, rigidity later
- You trade money for control
- You own none of the code
When you build:
- You spend more today, less per year
- You trade speed now for flexibility later
- You trade money for control
- You own the code and can change anything
Both are rational trades. The question is which one matches the stage and strategy of your business.
When Buying Wins
Start with the easy case. Buy off-the-shelf when:
1. The problem is generic and solved. Email hosting, payment processing, accounting, HR payroll, customer support tickets, video conferencing, file storage. These are solved problems. Building your own is nearly always the wrong call.
2. The space has mature competitive options. If there are 5 reputable companies competing on price and features, you benefit from that competition. Building custom takes you out of it.
3. Your process is standard. If you do exactly what every other company in your vertical does, a tool built for every company in your vertical will fit.
4. You need it this quarter. Speed matters. A SaaS you can launch in a week beats a custom tool you could have in six months when the deadline is in four.
5. You're still validating the underlying business. If you don't know whether customers want the thing yet, don't build infrastructure for it. Duct-tape with off-the-shelf tools until the business is proven.
6. The TCO over 3 years is under $30K. Below that, the cost of building rarely beats buying. Above that, it might.
When Building Wins
Build custom when:
1. The problem is specific to your business. Your workflow, your process, your data model, your terminology. Generic tools don't map to it, or only map with painful workarounds.
2. The tool is core to how you compete. If your edge is how you operate (your customer experience, your fulfillment process, your sales methodology), making that process run inside a generic tool erodes the edge. Custom encodes your advantage.
3. Per-seat or per-record pricing has become punitive. You're paying $80K/year and using 30% of the features. The pricing structure is now shaping your team decisions instead of serving them.
4. You need real-time integration with your own systems. Your billing, your inventory, your product usage, your custom data. Off-the-shelf tools can sync, but syncing has delays and failure modes. Native integration doesn't.
5. The space has only 1 or 2 real options and they're unsatisfying. If Salesforce and HubSpot are your only CRM choices and both require extensive customization, you're already paying the custom tax. Might as well get a product built for you.
6. You want it to last 10 years. Software you own doesn't get acquired, pivot into an unrelated product, triple its price, or sunset. Software you rent does all of these regularly.
7. The process is mission-critical. If the tool going down or getting acquired would break your business, ownership matters more than convenience.
The Five Questions That Actually Matter
Forget feature checklists. These are the questions that predict the right answer:
1. What's the real 5-year total cost of ownership?
Don't compare upfront cost. Compare:
- Buy TCO: (monthly subscription x 60) + onboarding + integrations + consultants + migration friction
- Build TCO: initial build + maintenance (usually 15 to 20% of build cost annually) + iteration + hosting
Teams almost always under-count the buy side (forgetting consultant fees, add-on modules, price increases) and over-count the build side (assuming maintenance is 50% of build).
2. How central is this workflow to your competitive advantage?
Score from 1 (generic utility) to 10 (this process IS our business).
- 1 to 3: Buy. No upside to owning it.
- 4 to 6: Buy + customize, or look at smaller/more flexible options.
- 7 to 10: Seriously consider building. This is where custom pays off.
3. How often does the process change?
- Rarely (payroll, invoicing): Buy. Stable processes don't need bespoke tools.
- Quarterly (your internal ops): Build or heavily customize. Off-the-shelf can't keep up.
- Constantly (still figuring out the business): Buy. Don't freeze a process you haven't settled on.
4. What happens if the tool disappears?
If your CRM vendor gets acquired tomorrow and shuts down in 18 months, what do you do? If the answer is "we lose 3 months rebuilding on another vendor," fine, buying is OK. If it's "we lose the business," own it.
5. Do you have (or can you hire) a technical partner you trust for the long haul?
Custom software without long-term technical ownership is worse than buying. You'll end up with expensive abandonware. Don't build custom unless you have either an in-house team or a trusted agency relationship that will be around in year 5.
The Hybrid Approaches Most Teams Miss
The build-vs-buy framing is a false binary. In practice, the best answer is usually a mix:
Buy + extend
Use an off-the-shelf tool as the core, build a custom layer on top. Common examples:
- HubSpot for marketing + custom quoting engine that pushes back into HubSpot
- Shopify for e-commerce + custom fulfillment + inventory logic on top
- Stripe for payments + custom billing/metering logic
You keep vendor speed on the commodity parts and get custom flexibility where it matters.
Buy the frontend, build the backend
Retool, Airtable, Zapier, or internal tool builders for the UI. Custom API and data model underneath. Cheap, fast, and surprisingly extensible.
Build the frontend, buy the backend
Your own UI and UX (because user experience is part of how you compete), but powered by Stripe, Twilio, Plaid, Supabase, etc. on the back end. You own the surface, rent the plumbing.
Buy early, build late
Run on off-the-shelf until you have real operational data about what you actually need. Then build the one or two tools that matter most. This is usually the right path for startups.
The Three Biggest Build-vs-Buy Mistakes
Mistake 1: Buying because it's "faster" without checking the 3-year cost
Teams sign up for a "$200/month" SaaS, add 5 seats, hit a usage tier, add a required integration, renew at a 20% price hike, and realize two years in they're paying $18,000/year. Then switching costs are high. The "faster" option was expensive after all.
Fix: Do the 3-year math before you buy anything over $500/month.
Mistake 2: Building because "we can, it'll be cheaper"
Without a clear reason the custom version is strategically important, building just because you have engineers available is almost always a waste. The engineers could be building something that actually differentiates the business.
Fix: Only build if it's on the "business-critical" list. Not because you can.
Mistake 3: Not accounting for the UX tax
Off-the-shelf tools accumulate UX debt. Every workaround, every custom field, every automation you built to make the generic tool fit your process is a cost. Your team spends minutes per task fighting the tool. Multiply by team size x tasks per day x working days.
A team of 10 losing 15 minutes/day to a bad tool is 625 hours/year of wasted time -- more than $30,000 in labor if your team costs $50/hour loaded. Most teams dramatically under-count this.
Fix: Before buying, spend a week pretending the tool is in place and track how many workarounds show up. That's your UX tax.
A Simple Decision Flowchart
- Is this process core to how you compete? No = Buy. Yes = Continue.
- Is your process standard for your industry? Yes = Buy or buy+extend. No = Continue.
- Is the 3-year TCO of buying under $100K? Yes = Buy. No = Continue.
- Do you have a trusted technical partner? No = Buy. Come back when you do. Yes = Continue.
- Will the process be stable for 3+ years? No = Buy until it stabilizes. Yes = Build custom.
The Short Version
Buy when the problem is generic, standard, and not central to your competitive advantage. Most problems qualify.
Build when the workflow is specific to your business, encodes your competitive edge, has TCO over $100K, and you have a long-term technical partner.
Do both: buy the commodity parts, build the part that's actually yours.
Whatever you decide: do the 3-year math, not the 3-month math.
I'm Joseph, founder of 0ARCH. We build custom software for businesses that have outgrown off-the-shelf tools. If you're stuck on a build-vs-buy decision, we'll scope it for free.