Build vs Buy: When SMBs should build custom internal tools

I get asked this on every discovery call. The answer depends on specific things that are easy to check, and most companies get the decision wrong in the same predictable ways.

They buy when they should build. They build when they should buy. They compare the sticker price of off-the-shelf software to the quote for custom development without accounting for the cost of making a bad-fit tool work.

There’s also a timing problem. Companies consider building too late. They’ve already bought three tools, configured them halfway, and built workarounds for the gaps. Now they’re so invested in the current setup that starting over feels wasteful. So they keep patching.

What the build vs buy decision actually looks like

PrepLadder is a good case because they tried buying first. They’re an edtech company helping medical students prepare for exams, with over 5 million users on their app. As their internal team grew, they needed tools to coordinate across sales, marketing, support, and content. So they bought separate tools for each function.

One tool for meetings. Another for task tracking. A third for performance monitoring. A fourth for something I genuinely can’t remember because by the time we got involved, even their team couldn’t keep track of what lived where.

Four tools, none connected, data scattered across all of them.

Deadlines got missed because the task tracker didn’t sync with the meeting tool, so action items from Monday’s meeting never became tasks. Sales wanted instant lead updates, but had to wait for someone to pull the numbers from a different system manually. Support needed customer history alongside open tickets, but those lived in separate places. Marketing wanted to track which campaigns were generating leads, but the data was split between two tools with no shared identifier.

We ran workshops with every department and documented 36 separate manual tasks that existed only because these four tools couldn’t talk to each other. Copying lead data from one app to another, manually checking if a task was completed by checking two dashboards, and rebuilding the same report in a different format for a different team.

PrepLadder didn’t need four tools. They needed one. We built a single platform where sales sees lead updates in real time, support sees ticket history alongside customer records, and marketing gets live campaign dashboards. The 36 manual tasks went to zero. Full case study here.

Buy when the problem is generic

Off-the-shelf software is the right choice when your problem looks like everyone else’s problem. You need to send marketing emails, buy email marketing tools. You need a CRM to track contacts through a standard sales pipeline, buy a CRM. You need project management with boards and timelines, buy that too.

Does the software work the way you work, or do you have to change how you work to fit the software? If it’s the first, buy. If it’s the second, you’ll spend the next year fighting the tool. We wrote about the signs that off-the-shelf has stopped working, and the tipping point is when you start building spreadsheet workarounds to fill the gaps.

Build when the problem is yours

Custom makes sense when your workflow has specific rules, specific data, or specific handoffs that no off-the-shelf tool was designed to handle. PrepLadder’s sales team needed lead data refreshed in real time, tied to support tickets and marketing campaign attribution, all in the same view. No off-the-shelf tool does that. You can connect three tools using Zapier, but this setup is fragile. If something unexpected happens, it could break easily.

You can connect three tools using Zapier, but this setup is fragile. If something unexpected happens, it could break easily.

The other signal is when you’ve already tried buying. You’ve purchased a tool, spent months configuring it, and your team still keeps a spreadsheet, because the tool can’t handle some critical part of their workflow.

I see this constantly. A company has Salesforce, HubSpot, Monday, or whatever. They’ve customised it as far as it’ll go. And there’s still a Google Sheet with 47 tabs that someone updates every morning before anyone else gets in.

Companies with between 20 and 80 employees have a mix of bought tools that work fine independently, but create gaps when work crosses between departments. The gaps are where manual labour lives, and the manual labour is where the money goes. If you want a framework for making that call, we wrote a guide to help you figure out which processes are worth building tools for.

The cost question

Companies compare the cost of custom software ($8K to $50K for a project like PrepLadder’s) to the annual license of an off-the-shelf tool ($5K to $30K a year). Custom looks more expensive. But they’re not counting the hidden cost of the manual processes the off-the-shelf tool creates. Those 36 tasks at PrepLadder, if each took 10 minutes a day across the team, would add up to over $70K a year in wasted labour.

Custom software is a one-time investment that eliminates an ongoing cost. Off-the-shelf is an ongoing cost that sometimes creates additional ongoing costs. $40K once vs $15K plus $70K in manual work every year.

It’s also rarely all-or-nothing. Most companies we work with keep their off-the-shelf tools for the things those tools do well. PrepLadder didn’t throw out everything. The custom build handles the gaps between the tools, the parts where work crosses between departments and data needs to flow somewhere the off-the-shelf tools can’t take it. You’re not replacing your entire stack. You’re filling the holes in it.

I realise this sounds like a sales pitch for building custom. It partially is. I run an agency that builds custom tools, so I have a bias. But I also tell companies to buy off-the-shelf when that’s the right answer, because building something custom when a $50/month tool solves the problem is a waste of everyone’s time. The decision is about where your specific gaps are and what those gaps cost you.

Your tools should work for your business, not the other way around.

Frequently asked questions

When should an SMB build custom internal tools instead of buying software?

Build when your workflow has specific rules, data, or handoffs that no off-the-shelf tool was designed to handle. The clearest signal is when you’ve already bought software, spent months configuring it, and your team still keeps a spreadsheet because the tool can’t handle a critical part of their workflow. Buy when your problem looks like everyone else’s — standard CRM, email marketing, project management.

How much does custom internal tool development cost?

Most projects for SMBs in the 20-80 person range fall between $8,000 and $50,000. The comparison to annual SaaS licenses looks unfavorable until you count the cost of manual workarounds that off-the-shelf tools create. If your team spends time copying data between systems, rebuilding reports, or maintaining spreadsheet overlays, that labor cost often exceeds the custom build cost within 12-18 months.

What’s the ROI on custom internal tools for growing companies?

The return is clearest when you can count manual tasks that exist only because your current tools don’t connect. One example: a company with four disconnected tools had 36 separate manual tasks per day across the team. At 10 minutes each, that added up to over $70,000 a year in wasted labor. The custom build cost $40,000 once and eliminated the ongoing cost.

Do I need to replace all my existing software to build a custom tool?

Almost never. The most common approach is keeping your existing tools for what they do well and building something custom to handle the gaps, the places where work crosses between departments and data needs to flow somewhere your off-the-shelf tools can’t take it. You’re filling the holes in your stack, not replacing it.

How long does it take to build a custom internal tool?

For a well-scoped project, 4-8 weeks from signed contract to delivery. The time depends on the number of integrations, the complexity of business logic, and how clearly you can describe what the tool needs to do before work starts. Unclear requirements are the most common cause of blown timelines.