Every growing team eventually hits the same inflection point. The SaaS tools that got you here are starting to feel like ceilings. They don't quite fit your workflow. They're expensive at scale. They can't talk to each other without painful workarounds. And the thing you actually need doesn't seem to exist as a product you can just buy.
So you face the build vs. buy question: keep patching together tools, or invest in something custom?
It's one of the most consequential decisions an operations or technology leader can make — and it's often made badly, either out of habit (default to buying because it's faster) or out of ambition (default to building because it sounds better). Neither instinct is right. The right answer depends on four factors that most frameworks miss.
Why the Default Answer Is Usually Wrong
"Buy first, build later" is conventional wisdom in startup circles, and it's generally good advice in the early stages when speed matters more than fit and you don't yet know what you actually need. But it hardens into dogma for teams that should have moved on by now.
The problem with defaulting to buy as you scale:
- SaaS pricing rarely scales linearly with your usage — most tools get dramatically more expensive as you grow
- You accumulate technical debt in the form of integrations and workarounds that take engineering time to maintain
- Vendors get acquired, raise prices, sunset features, or pivot in directions that don't serve you
- Your competitors have access to the same tools — you can't differentiate on software you bought
- You own nothing — your data, your workflows, your institutional knowledge lives in someone else's system
On the other side, "build everything" is just as much a trap. Custom software takes time to build, time to maintain, and requires technical talent that might be better deployed elsewhere. A team that builds a custom CRM instead of using Salesforce hasn't saved money — it's created an infinite maintenance obligation and pulled engineers away from work that actually differentiates the business.
The real question isn't "build or buy" — it's "where does custom software create durable competitive advantage, and where is it just overhead?" Those two categories require completely different answers.
Four Questions to Guide the Decision
Is this workflow a differentiator or a commodity?
If your competitors do the exact same thing the same way, that workflow is a commodity. Buy commodity workflows — use Stripe for payments, use Salesforce for CRM, use Gusto for payroll. You're not going to out-compete anyone by building a better payroll system.
But if the way your team does something is genuinely different — faster, more precise, more integrated with your product — that workflow might be worth owning. Custom software compounds over time; SaaS tools are level playing fields.
What does this tool cost at 3× your current scale?
Most SaaS tools look cheap at small scale and become expensive surprises at growth. Model out what you'd pay at 3× your current seat count, data volume, or API calls. If the number is uncomfortable, that's information.
Custom software has a high upfront cost and low marginal cost at scale. SaaS has a low upfront cost and high marginal cost at scale. The crossover point is different for every tool — but it's worth calculating before you're locked in.
How many integration workarounds are you maintaining?
Every time you use Zapier to connect Tool A to Tool B, or hire an engineer to maintain a custom API integration, or export a CSV from one system to import it into another — you're paying a tax on having bought the wrong tools.
If you're maintaining more than two or three significant integrations to get data flowing the way you need it, that's often a sign that you need one custom tool, not five purchased ones. The integration overhead frequently costs more than the software would have.
What happens if this vendor disappears?
Every SaaS vendor can be acquired, sunset, or repriced. Some of those events are recoverable (you migrate to a competitor). Some are catastrophic (your core operations stop working while you scramble).
Ask yourself: if this tool went away tomorrow, what would happen? If the answer is "bad, but we'd recover quickly," that's fine. If the answer is "we'd be down for weeks and potentially lose clients," that's a concentration risk worth eliminating — either through redundancy or by building something you own.
The Hidden Costs of Buying
The direct cost of a SaaS subscription is the most visible number — but often not the biggest one. Teams that have been on a platform for a few years frequently discover that their actual total cost is 2-3× the subscription price when you account for:
- Integration maintenance — engineering time spent keeping your tools talking to each other
- Training and onboarding — every new hire needs to learn a tool that doesn't quite match your workflow
- Workarounds — the manual processes that exist because the tool doesn't do exactly what you need
- Data migration risk — the cost (in time and money) of switching tools when the current one stops serving you
- Feature creep overhead — the cognitive load of navigating software built for everyone, not for you
These costs are real but invisible until someone goes looking for them. A useful exercise: ask your team how many hours a week they spend working around your current tools rather than with them.
The Hidden Costs of Building
To be clear-eyed about this: custom software is not a free lunch either. The hidden costs here are different but equally significant.
- Ongoing maintenance — software doesn't stand still; dependencies update, browsers change, bugs emerge
- Feature requests never end — once a team has a custom tool, they want it to do more
- Bus factor risk — if the person who built it leaves, institutional knowledge goes with them
- Opportunity cost — every engineering hour spent on internal tools is an hour not spent on your product
This is why it's critical to build the right things and buy the rest — not to build everything or buy everything.
- It's a core workflow that differentiates you
- SaaS cost at scale is painful
- You're maintaining 3+ workarounds
- Your data needs to live in one place
- No tool on the market fits well
- Vendor risk is unacceptable
- It's a commodity workflow
- Speed to deploy matters more than fit
- The tool does 90%+ of what you need
- Vendor ecosystem is stable and competitive
- Your team lacks maintenance capacity
- Requirements are still changing rapidly
What Good Custom Software Actually Looks Like
When teams decide to build, they often over-scope it. They want the custom tool to do everything the SaaS tool did, plus the new things they needed. The result is an expensive, slow project that takes months and delivers something that needs to be rebuilt again in two years.
The best custom internal tools share a few characteristics:
They're narrow. They do one thing really well rather than trying to replace an entire product category. A custom dashboard that pulls data from your CRM, your database, and your analytics into one view is far more valuable than an attempt to build a custom CRM.
They're built around your actual workflow. The feature that makes a custom tool valuable is that it matches how your team actually works — not how a product manager at a SaaS company thinks you should work.
They're maintainable. They're built with technologies your team understands, documented well enough that someone new can pick them up, and scoped tightly enough that they don't become a full-time maintenance burden.
They integrate with your existing systems. The goal isn't to replace your entire stack — it's to fill the specific gap where no purchased tool works. Good custom software is a bridge, not a silo.
Build when the workflow is a competitive differentiator and you'll run it at scale for years. Buy when the workflow is a commodity and the vendor ecosystem is stable. And when you're not sure — start with buy, but track the hidden costs closely.
Making the Call
If you've worked through the four questions and the comparison above, you probably have a clearer sense of where you land. A few final considerations before you decide.
Don't let perfect be the enemy of good. A custom tool that does 80% of what you need and fits your workflow perfectly is often better than a SaaS tool that does 100% of what you need but requires workarounds to fit your process.
Consider phased approaches. You don't have to choose between "buy forever" and "build everything." Many teams successfully run hybrid approaches — buying for commodity workflows, building for differentiating ones, and gradually shifting the balance as the business scales.
Price in the build correctly. Custom software has real upfront cost, but the total cost calculation over three years often looks very different from the one-year calculation. Model it honestly before you conclude that buying is cheaper.
The build vs. buy question doesn't have a universal answer — but it has a framework. Teams that ask the right questions make better decisions, spend money where it creates durable value, and stop paying the silent tax of software that almost fits.
We build the tools your team actually needs.
MerryMango builds custom internal tools, workflow automation, and client portals for growing teams. Fixed-fee, senior-led, built to replace the SaaS stack that stopped fitting. Let's talk through your situation.
See our custom software work →