We had a client last year who wanted to build their own CRM. “Nothing off-the-shelf fits our sales process,” they said. Fair point - their workflow was a little unusual. But we did the math anyway.
Building a CRM that even half-way replicated Salesforce would have cost them $200K+ in initial development, plus ongoing maintenance, support, and the engineering salary they’d burn keeping it running. Salesforce would have been $40K a year to start. They picked Salesforce, hired someone to run the integration, and spent maybe $60K getting their process into the platform. They saved money and got a product that someone else worries about updating.
That’s the story you need to hear first: buy almost everything. Default to it. The bias toward building is expensive and usually wrong.
But “almost everything” isn’t everything, and I’ve also seen companies waste hundreds of thousands customizing a vendor platform when they should have built a $80K tool from scratch. The difference between those two outcomes isn’t obvious at the start. It depends on a few concrete things.
Default to Buying
The economics are straightforward. Custom software costs what you build it for, plus everything after that. Maintenance as frameworks go out of date. Security patches as vulnerabilities get disclosed. Feature requests from stakeholders. Training new people on how it works. Answering 3 AM pages when it breaks.
You’re not paying for a feature set. You’re hiring a permanent employee that your company owns and operates.
Vendor software has dedicated teams working on that stuff. Thousands of customers using it in conditions you’ve never seen. Edge cases already discovered and fixed. When someone on your team says “we could build this in-house,” the response should be “show me the 10-year cost, including operational overhead.” That number gets large fast.
For commodity work - HR, payroll, project management, basic CRM - competing with vendors is almost never worth it. They’ve poured years into these products. You can’t.
When Custom Is Actually Right
There are situations where building makes sense. They share specific characteristics, and they’re worth recognizing before you spend money going the wrong direction.
The Capability Is Your Competitive Edge
If what makes your company different is a software capability, buying a vendor solution means your competitors can buy it too. The entire point of differentiated software is that it’s yours and they can’t replicate it instantly.
Your HR system isn’t a competitive differentiator. Your routing algorithm might be. Your care coordination platform might be. A healthcare company that builds proprietary tools for scheduling and risk stratification - that’s defensible. A healthcare company building their own expense reporting system - that’s waste.
The test is simple: if your competitor could license the same software tomorrow and your market position doesn’t change, you should be buying it, not building it.
Integration Gets So Complex That Custom Becomes Cheaper
We worked with a financial services firm stuck with three legacy systems - a mainframe from 1997, a custom-built portfolio tracker from 2008, a modern vendor platform they adopted in 2019. Getting any of them to talk to each other cleanly was impossible. The integration layer would have cost $150K and been fragile forever.
They ended up building a purpose-built reconciliation and routing system - a $120K tool designed specifically to sit between those three incompatible worlds. It’s simpler, more reliable, and cheaper than trying to force a vendor solution to bridge systems it was never designed for.
When integration complexity is your main project, building a targeted tool that connects them often beats buying something bloated that half-works with all three.
Your Workflow Is Genuinely Unusual
Most vendors build for the 80%. If your requirements fall into the remaining 20% - weird regulatory constraints, non-standard data structures, approval logic that doesn’t fit any standard pattern - you’ll spend enormous energy fighting the vendor.
Red flags: the sales conversation keeps ending with “you could do that with a workaround” or “that’s on our roadmap.” Workarounds accumulate. Roadmap promises are made to everyone. You’ll end up with a system that’s neither the vendor’s product nor actually yours - it’s a Frankenstein of vendor features and custom hacks, and nobody owns it cleanly.
You Actually Know What You Need
This one’s critical and often skipped. Build custom software to solve a problem you fully understand. Build it against requirements that have already stopped changing.
If you’re still figuring out what your workflow should be, buy something and use it for six months. Learn how you actually work. Then, if building custom makes sense, build it against stable requirements. Building custom software to solve a problem that’s still undefined is reckless.
Where the Financial Analysis Goes Wrong
The standard build vs. buy comparison misses costs on both sides.
Customizing “customizable” platforms. Enterprise software vendors market themselves as highly configurable. In practice, heavy customization means hiring specialized consultants, relying on undocumented behavior, having upgrades break your changes, and ending up with a system that’s neither the vendor’s product nor truly custom - it’s a compromise that belongs to nobody. That customization cost is frequently 50% or more of what you’d spend building from scratch. And it’s slower, more fragile, and harder to fix.
Data portability and lock-in. What’s your cost if you need to switch vendors, or the vendor gets acquired, triples prices, or shuts down? For deeply integrated systems, the data migration and switching cost can be enormous. Most initial vendor evaluations ignore this entirely.
License scaling. Per-seat pricing looks fine at small scale. Model it when you’re three times bigger. Model it when you’re five times bigger. Some companies have been shocked to discover their vendor bill could fund their entire engineering team if they grew another 50% of headcount.
The friction tax. When vendor software is close but not quite right, organizations accept workarounds, manual steps, and operational friction. Employees spend 10 minutes a day working around a limitation that would take a vendor $50K to fix. That friction is a real cost - in wasted time, in morale, in errors - and it’s almost never quantified in the build vs. buy decision.
The Actual Decision
Treat this as a specific evaluation, not a binary choice.
Is this capability a competitive differentiator? If no, buy it. If yes, keep reading.
What’s the operational cost of “good enough”? Make it explicit. How much time do employees waste? What does a workaround cost? If those numbers are real, custom starts to make sense.
Model the full 5-year cost of each path. Not development cost - operational cost. Maintenance, support, integration, the productivity impact of vendor limitations, the cost of having someone own it.
Can you describe the requirements precisely without them changing in three months? If not, it’s too early to build. Buy provisionally, learn, then build.
How easily could you reverse the decision? Some bets are more recoverable than others. The easier it is to switch away from what you choose, the lower the bar for trying it.
The Hybrid Options
You don’t have to pick one or the other.
Buy the platform, build the integration. Use a vendor for what they’re good at. Build a clean integration layer that belongs to you. Vendor handles the commodity part. You maintain the glue and the logic that’s specific to your business.
Buy to learn, then build. Start with off-the-shelf. Run it for six months. Once you actually understand what you need and have evidence it matters, build custom against that evidence.
Open source plus custom code. You control the entire codebase and avoid starting from scratch. The tradeoff is you own the maintenance, but for infrastructure and specialized tools, it’s often the right balance.
The build vs. buy decision matters because you’re not just picking software. You’re deciding where to spend engineering time, whether a capability is defensible, and what kind of technical debt you’re willing to own for the next five years.
We’ve seen both paths taken successfully and both paths blow up spectacularly. The difference is making the decision with eyes open: clear-eyed about costs, honest about whether this thing is actually special, and willing to change your mind once you have operational evidence.
If you’re facing this decision, we can help you think through it before it becomes expensive.
TechRev Service
Platform & Software Engineering
From architecture through deployment, we design and build custom platforms and applications — with AI-accelerated workflows that deliver faster without cutting corners on quality.
See our engineering servicesAI helped write this. Our team made sure it was worth reading.
