Build vs. Buy Tools
Lessons from the Nightmare of Homegrown Tools
👋 Hi, it’s CJ Gustafson and welcome to Mostly Metrics, my weekly newsletter where I unpack how the world’s best CFOs and business experts use metrics to make better decisions.
Some nights, I wake up in a cold sweat, haunted by flashbacks of the homegrown tech solutions we built at various companies. The recurring nightmare goes like this:
…I log into the system, scrambling before a board meeting to pull together data, but someone moved all the controls around.
I can’t figure out how to export to Excel.
It’s the FP&A person’s equivalent of the classic “test you didn’t study for” dream.
One company I worked at had a beast of a system called MBAT. Everybody knew MBAT. Everybody hated MBAT. It stood for “Marketing Budget Automation Tool,” though there was nothing automated about it. Engineers built it for the field marketing teams to track spend across multiple geographies in our channel sales model. It was supposed to help us allocate budgets and track ROI across suppliers and resellers.
In theory, it was a noble goal.
But here’s the kicker: we sold backup and recovery software. Nothing in our DNA screamed “MarTech expertise.” And yet, MBAT was so ingrained in our processes that nobody dared rip it out. Instead, we just shifted everything else we did to cater to its clunkiness.
Sound familiar?
Every company has its own version of MBAT—some internal billing mechanism for rev rec, a proprietary CRM, or a one-off tool patched together to solve a short-term problem (that never gets killed off). These Franken-systems persist because they work just enough to avoid getting replaced. But one day, you step back and ask,
“How the hell did we get here?”
The Build vs. Buy Conundrum
Reflecting on MBAT now, I see how easy it is to fall into the trap of building something in-house instead of buying off-the-shelf tools. I recently spoke with Adam Berg, CFO of ZeroHash, about this.
He summed it up perfectly:
“It takes real introspection to admit what you’re good at—and what you’re not. Whenever we face a build vs. buy decision, we ask:
What do we do really well?
What could we do really well?
What should we do really well?
If those three don’t align, it’s time to partner, not build.”
MBAT was a case study in misalignment. It didn’t integrate with our FP&A planning tool, so we relied on endless vlookup’s to sync it with NetSuite data. It didn’t save us money either—since it wasn’t part of a broader tech suite, we missed out on pricing leverage and had to pay extra for workaround integrations.
When you build internally, you often lock yourself into a siloed solution that’s harder to scale, more expensive to maintain, and a nightmare to replace.
You don’t get style points
Take Klarna. They recently made headlines for ripping out Salesforce as their CRM and Workday as their HRIS. That’s a bold move for a fintech company, and it makes you wonder: how many homegrown CRMs have gone to the graveyard? Spoiler alert: probably a lot.
Very bold move.
Adam agreed:
No, you don't get a higher multiple for that for sure.
There are no style points for doing something on “hard mode” when you could have put your efforts to something more accretive to shareholder value.
The Hidden Cost of Homegrown Tools
Beyond integration headaches and financial inefficiencies, homegrown tools hurt your employees on both ends.
Onboarding suffers. Imagine hiring a sales rep who’s a Salesforce wizard, only to throw them into a clunky, bespoke CRM. Instead of hitting the ground running, they’re stuck learning your proprietary system—time better spent closing deals.
Career growth stalls. Companies have an implicit promise to upskill employees, making them more valuable in the market. But living inside a homegrown tool for years doesn’t help anyone’s resume.
Take MBAT again. One colleague, Katherine, was known as the “MBAT Queen.” She wore the title like a badge of honor. But I saw it differently: her entire professional reputation revolved around a tool that didn’t exist outside our company. That’s not a career booster; it’s a liability.
Final Thoughts
At the end of the day, homegrown tools like MBAT aren’t just clunky—they’re costly. They hurt your tech stack, your pricing leverage, and your employees.
I realize people get attached to things they build, and feel a sense of accomplishment. But that’s better served when they build something for your company’s core competency, using capital and resources for things that result in true innovation and hard return on investment.
The decision to build vs. buy comes down to focus. Build when it’s core to your business. Partner when it’s not. And always think about the ROI—for your company and your team.
(Unless you’re Slack… that worked out pretty well, I guess.)
Apple | Spotify | YouTube
I recently spoke with Erica Gessert, CFO of Upwork. Previously she was PayPal’s SVP of Finance and Analytics. We discuss:
Erica's experience with forecasting models at PayPal
Upwork’s approach to customer acquisition costs
The significance of network effects in marketplace businesses
And Upwork’s take rate strategies
This was one for the books. I highly encourage you to check it out if you are business model nerd like myself.
Quote I’ve Been Pondering
“The danger is greatest when the finish line is in sight. At this point, Resistance knows we’re about to beat it. It hits the panic button. It marshals one last assault and slams us with everything it’s got. The professional must be alert for this counterattack. Be wary at the end. Don’t open that bag of wind.”
-The War of Art by Steven Pressfield & Shawn Coyne
I love the comment about Slack at the end. It doesn't refute your point at all, but I am curious of what other examples readers can think of where internal tools were eventually marketplace offerings, often being spun out into their own company?
DeepSeek is an interesting example, where as I understand it the original models were developed internally to support a quant based hedge fund, then eventually became its own org.
In the industry I work in, there is a company that originated as internal tooling for General Electric, and was eventually spun off into its own software company.
Any others readers can think of?
Really interesting perspective!
I think there are a few dimensions worth expanding on that feel incomplete to me.
1. For CRMs its worth noting that whether you build or buy (Salesforce for example) you always need to do a lot of customization to make it fit a global sales force - this scales with the complexity of the business - you need to build it out and own it regardless.
2. For certain product verticals (like OPEX cost management solutions, FinOps tooling) at the Enterprise level you are always fighting the companies themselves. Often the buy decision wins because it brings documentation, rollout, and process opinion with it (which is dangerous). Regardless of what tool you have (internal or off the shelf) you need sharp ownership of process and rollout to get your desired outcome.
4. AI changes build/buy decisions massively. It would be worth noting that the level of startup investment to prove build ideas is lower. Additionally, it means newer incumbents will have more disruptive innovation to offer.