Every tooling decision at a mid-market company gets framed as build or buy. That framing is incomplete, and it’s costing you months of wasted effort. There’s a third path that most ops teams overlook entirely.
Someone on the leadership team says “we need better lead scoring.” The engineering lead says “we could build something custom.” The VP of Sales says “let’s just buy a tool.” The conversation ping-pongs between these two options for three weeks. Meanwhile, nobody asks whether the CRM you’re already paying for has a lead scoring engine sitting unconfigured in the settings panel.
This is the pattern I see at nearly every mid-market product company between $3M and $50M. The build-vs-buy framing was designed for software product decisions — should we build this feature or license it? It makes sense in that context. But for operations tooling, it misses the option that delivers the best ROI roughly 60% of the time.
The binary framing creates two failure modes. Companies that default to “build” end up with a fragile internal tool that one engineer maintains and nobody else understands. Companies that default to “buy” end up with a graveyard of SaaS subscriptions, each solving a narrow problem and none talking to each other. Both paths share the same root cause: nobody evaluated whether an existing platform could handle the use case if properly configured.
This is part of the broader tool stack architecture challenge. Your stack isn’t just what you buy — it’s how you configure what you have. And most mid-market companies are using 15–30% of the capabilities they’re already paying for.
HubSpot out-of-the-box and HubSpot properly configured are different products. This is not an exaggeration. A default HubSpot instance has basic contact records, a pipeline with generic stages, and a handful of canned reports. A deeply configured HubSpot instance has custom properties mapped to your sales process, automated lead scoring with behavioral triggers, lifecycle stage automation, custom reporting dashboards, and integration workflows that sync data across your stack.
The platform is the same. The subscription cost is the same. The operational value is separated by an order of magnitude.
“Configure” means taking an existing platform and doing the work to make it fit your operations precisely. It’s not buying a new tool. It’s not building something from scratch. It’s investing operational expertise into a platform you already own to unlock capabilities that are sitting dormant.
Before adding any new tool to your stack, audit what you already have. Open the settings panel of every platform you’re paying for. Count the features you’ve never touched. I’ve found entire automation engines, reporting modules, and integration capabilities that clients were paying for and had never opened. The best “new tool” is often the one you’re already subscribed to.
This is where most teams get it wrong. They configure a platform once during setup, then treat it as static. But your operations change. Your sales process evolves. Your ICP shifts. Configuration is ongoing tuning — adjusting lead scoring weights as your market feedback changes, updating pipeline stages as your sales motion matures, refining automation rules as you learn which sequences actually convert.
The companies that get the most value from their stack are the ones that treat configuration as a continuous operating discipline, not a one-time project. This is a core part of maintaining a lean stack that outperforms bloated alternatives.
Building custom tooling makes sense in exactly three situations. First, your workflow is so specific to your business that no existing platform can model it. Second, the custom tool creates a competitive advantage — it’s not just ops infrastructure but a differentiator. Third, you’ve evaluated the existing platforms in your stack and confirmed none can handle the use case even with deep configuration.
Example: a product company with a proprietary hardware + software bundle had a quoting process that depended on component availability, custom engineering time estimates, and dynamic margin calculations based on customer tier. No CRM quoting module could handle the logic. Building a custom quoting tool was the right call — the workflow was genuinely unique and touched their competitive advantage.
But be honest about this. Most workflows are not unique. They feel unique because you’ve never seen how another company handles the same problem. Before committing to build, talk to three operators at similar-stage companies about how they solve it. You’ll usually find that a standard platform handles it fine.
Buying a standalone tool makes sense when: the function is commoditized (email delivery, form capture, scheduling), your team doesn’t have the dev capacity to build or the ops capacity to configure, and you need fast time to value with minimal setup.
Example: buying Calendly for meeting scheduling instead of building a custom booking system or configuring HubSpot’s meeting tool with complex round-robin logic. Calendly does one thing extremely well, costs $10/user/month, and works in 30 minutes. The decision is obvious.
The danger with buying is tool sprawl. Every tool you add creates integration overhead, another login, another data silo, another vendor relationship. Before buying, ask: does this need to be its own tool, or could an existing platform in my stack handle this if I spent two hours configuring it? The answer is the latter more often than you think.
If an existing platform in your stack handles 80% of the use case natively, configure it. Don’t buy a separate tool for the remaining 20%. That last 20% is rarely worth the integration overhead, additional subscription cost, and data fragmentation. Accept the 80% solution and move on.
Configure when a platform in your stack has the capability but it hasn’t been activated, customized, or integrated into your workflow. This is the path for most ops tooling needs.
Example: a $12M product company wanted custom dashboards showing marketing attribution by channel, product line, and customer segment. They were about to buy Tableau licenses at $70/user/month. We looked at their existing GA4 setup — which had default configurations only — and built everything they needed using GA4’s native exploration reports, custom dimensions, and Looker Studio connections. Total cost: zero dollars in new subscriptions. Time invested: three days of configuration. Result: dashboards they still use daily, 18 months later.
Another example: a company built a custom Python script for lead scoring because “HubSpot’s scoring isn’t sophisticated enough.” Their HubSpot instance had the scoring feature turned on with three basic criteria from two years ago that nobody had updated. We rebuilt their scoring model using HubSpot’s native scoring with behavioral signals, engagement decay, firmographic criteria, and negative scoring attributes. Eighteen properties. Took a day. Outperformed the custom script within a month because it updated in real time instead of running as a nightly batch job.
The question isn’t “should we build this or buy it?” The question is “can something we already own do this if we invest the time to set it up properly?” Start there. Move to build or buy only after configuration has been ruled out.
Every path has costs. Most teams only count the obvious ones. Here’s the full picture:
Build: Development time (typically 2–8 weeks for ops tooling) + ongoing maintenance (your engineer is now responsible for this tool forever) + opportunity cost (that engineer isn’t working on your product) + documentation debt (what happens when the engineer leaves?) + integration overhead (you built the tool, now you need to connect it to everything else). Real cost for a mid-complexity ops tool: $30K–$80K in year one, $10K–$25K annually after that.
Buy: Subscription fee (ongoing, usually increasing) + onboarding and training time + data migration + integration setup + switching cost when you eventually outgrow it. Real cost: $5K–$30K year one, $3K–$15K annually, plus the hidden cost of one more tool in a stack that’s already too wide.
Configure: Operator expertise (someone who knows the platform deeply) + setup time (typically 1–5 days) + ongoing tuning (2–4 hours per month) + no additional subscription cost. Real cost: $3K–$15K in year one, $2K–$5K annually for maintenance and tuning. Often the lowest total cost of ownership by a significant margin.
When evaluating “build,” multiply your estimated development time by 3x for year-one total effort (building + testing + fixing + documenting). Then budget 20% of the original build effort annually for maintenance. Most teams underestimate maintenance by 5x. The tool you built in two weeks will consume two weeks of engineering time every year to keep running.
When a tooling need surfaces, run through these questions in order. Stop as soon as you reach a clear answer.
1. Does an existing platform in our stack have this capability? Check the documentation. Open the settings panel. Search the knowledge base. If the answer is yes — even partially — go to question 2. If no platform in your stack can handle any part of this, go to question 4.
2. Can we get to 80% of the use case with configuration alone? If yes, configure. Accept the 80%. The remaining 20% is almost never worth a separate tool or a custom build. If the existing platform gets you to 50% or less, go to question 3.
3. Can a combination of configuration + lightweight integration close the gap? Sometimes the answer is configure platform A and connect it to platform B via API or middleware. If a Zapier connection or native integration solves the gap, this is still the “configure” path. Evaluate this as part of your API-first tool selection approach. If the integration is too complex or fragile, go to question 4.
4. Is this a commodity function or a unique workflow? Commodity function: buy. Someone has already solved this problem better than you will. Unique workflow: go to question 5.
5. Does building this create competitive advantage or is it just infrastructure? If it’s competitive advantage, build — but scope it tightly and plan for maintenance from day one. If it’s infrastructure, buy the closest available solution and adapt your process to fit the tool rather than building a tool to fit your process.
The sequence matters: configure first, buy second, build last. Most mid-market ops teams should be configuring 60% of the time, buying 30%, and building 10%. If your ratio looks different, you’re probably overspending on tools or over-investing engineering time in ops infrastructure.
The best operators I’ve worked with share a common trait: they extract maximum value from existing platforms before adding anything new. They know their tools deeply. They read the documentation. They test features that most users ignore. And as a result, they run leaner stacks, spend less money, and move faster than teams with twice the budget and four times the tools.
The next time someone in your company says “we need a tool for that,” ask one question first: “Have we checked whether something we already have can do this?” The answer will save you more money and time than any software evaluation ever will.
30-minute discovery call. We’ll evaluate your specific tooling decisions and recommend the path that saves the most time and money.
Schedule Call