Build vs buy: a decision framework for SMB internal tools

A founder is sitting across the table from us. They run a USA-based manufacturer that sells through dealers — over a hundred of them now, scattered across continents. Leads, pipeline, and customer history all live in Zoho. Years in, Zoho is doing exactly what Zoho is supposed to do for the internal team. Nobody is arguing with the CRM.

The problem is the dealers.

The dealer network just crossed a hundred, and every dealer needs to see their assigned leads, the orders flowing through, and a way to send a quote back to head office. The obvious answer — give them Zoho seats — has gone from awkward to absurd. The annual seat cost, multiplied across a hundred external partners, would dwarf what the company pays for the CRM itself. The security team is tense; dealers don't need full CRM access, they only need their slice. The dealers don't actually want the CRM either — they want their leads, their orders, and a way to generate quotes without three logins and a training session.

So the founder is asking the question every owner in this position eventually asks. Replace Zoho with something else? Buy a different SaaS for the dealer side? Build something custom?

They're stuck because every option has a trapdoor under it. Replacing a working CRM to solve an external-user problem feels insane. Bolting on another SaaS adds another bill, another login, and another seam to babysit. Building custom sounds expensive and slow, the kind of project that becomes someone's weekend job for two years.

We've sat across from versions of this exact moment dozens of times. After 250+ apps for 100+ businesses — shipped on Glide and native, picking the right tool for the job — here's how we walk through the decision.

The four questions we actually walk through

Every build-vs-buy conversation collapses to four questions. Most owners we meet have only asked the first one.

1. Is the workflow standard, or specific to your business? If a thousand other businesses solve it the same way, there's a SaaS for it. If your version is shaped by a quirk of how your operation runs, generic tools will fight you.
2. Will SaaS per-user pricing punish you at scale? Per-seat is fine when your user count is your team. It breaks the moment you need to extend access to dealers, contractors, customers, or franchisees.
3. Does the workflow need to integrate with three or more existing systems? SaaS integrations work cleanly in pairs. Three-way and four-way stitching is where SaaS economics quietly fall apart.
4. Is the team bending its process to fit the SaaS, or is the SaaS bending to fit the team? If you've changed how you work because the tool insisted, the tool is now the boss. That's the trap.

The patterns of "yes" and "no" map to four answers — buy, build, wrap, or do nothing. The rest of this post walks through each.

When the right answer is buy

Standard work runs on standard tools. We tell every owner this in the first meeting because it saves them money the rest of the conversation can't.

Accounting is accounting. QuickBooks or Zoho Books does what an accountant needs and integrates with what they're already using. Building a custom ledger is a category error — you'd be reinventing a problem that's been solved beautifully for thirty years. Same logic applies in three other categories.

Vanilla CRM — buy. Zoho or HubSpot. If your sales process is "lead in, qualify, quote, close, hand to delivery," there is a SaaS that does that better than anything we'd build.

E-commerce — buy. Shopify or WooCommerce. The platform decision pulls payments, inventory, taxes, shipping, returns, and a hundred other adjacencies along with it. Building those from scratch is a mistake we've never seen pay off.

Task and project management — buy. ClickUp, Notion, or Asana. The one caveat: if your tasks need to live next to your operations data — orders, claims, dispatches — and a generic task tool would mean people tab-hopping between two systems, build the task layer into the operations console. Otherwise, buy.

This is not a controversial list. We make money building software, and we still tell every prospect: if your work fits these tools, use these tools. Building inside this lane is busywork dressed up as strategy.

When the right answer is build

Build when the workflow defines the business.

Two patterns we see again and again. The first: a recurring multi-week program operator we've worked with had to coordinate hundreds of people from different cities across overlapping field engagements — scheduling, attendance, daily operational notes, expense capture, travel logistics, last-minute substitutions, in-app communications, payouts, all rolling up to a single admin console where the owner could see what was happening today. There's no SaaS for that. Project management tools assume office work. Field-service tools assume short jobs. HR tools don't do logistics. They tried for years to stitch it together from generic tools and ended up with a fragile no-code stack and a lot of WhatsApp threads. We replaced the lot with one custom build.

The second: refunds tied to quality claims and delivery exceptions, with operational rules behind every decision. The Service Portal operations rebuild we did for a multi-market fresh-produce company is the canonical example — claims tied to delivery exceptions, AI doing the first pass on every claim photo, refunds and coupons issued from a single console wrapping WooCommerce and the company's automation platform, duplicate-prevention enforced in three layers, every action audit-logged in two places. None of that exists as a SaaS feature.

Build also wins reliably for multi-stakeholder approvals with role-scoped views, industry-specific compliance flows, and integrations no off-the-shelf tool ships with. The shared pattern: forcing these workflows into a generic tool slowly bends the business to fit the tool's opinion instead of the other way around. When the workflow is the business, the workflow has to be the software.

The path most founders don't see

Back to the manufacturer.

The move we walked them through: don't replace Zoho. Wrap it.

Zoho was working. The internal team had built habits, automations, and reports on top of it over years. Replacing a working CRM is a six-month project that delivers the same outcome the team already has. It's the most expensive way to solve a problem that isn't actually a CRM problem.

The actual problem is that 100+ external dealers need a thin, role-scoped surface onto leads and orders that already live in Zoho. That's not a CRM purchase. That's a custom dealer portal — small, focused, talking to Zoho.

So we built one. Lightweight and mobile-friendly, linked to Zoho through its API. New leads sync from Zoho into the dealer portal and route to the assigned dealer. Dealers see only their own leads and orders. They generate quotes inside the portal, which flow back into Zoho as a record on the original lead. The internal team keeps using Zoho exactly as before. No per-user pricing punishment. Security tightly scoped — dealers never touch the CRM. One bill instead of a hundred seats.

This is the pattern, and it's the answer most owners never consider. Don't replace SaaS that works. Wrap it. The hybrid path is almost always cheaper, faster to ship, and easier to maintain than either extreme.

The cost question

A custom build has a higher upfront cost than a SaaS subscription. That's the comparison most owners stop at, and it's the wrong one. The right comparison is total cost over a year or two against the burn of the SaaS stack the build replaces or extends.

A client we worked with last year invested in a custom build that paid back roughly 4× annually within the first year. The project shipped in 8–10 weeks. Payback hit in the first 3–4 months. By year-end, first-year savings were 3–4× the build cost, and the ongoing monthly burn is materially lower than the equivalent SaaS would have been at their scale.

The mechanics behind the math are consistent. Custom doesn't charge per seat, so adding users is free. Custom doesn't charge per feature, so adding workflow rules is free. Custom doesn't charge for integrations, so the cost of stitching tools together disappears. SaaS is priced as if you'll keep adding to it; custom is priced as if you've already built it.

The other cost SaaS doesn't show on the invoice is the cost of the workflow not fitting. Longer cycle times. Missed handoffs. Admin time spent stitching tools together. That bill gets paid every week, in payroll, forever.

Why most owners hesitate to build

Owners hesitate on build for real reasons and outdated reasons, mixed together. The real reasons: change management is hard, adoption is uncertain, getting the team to switch workflows takes effort. Those concerns are legitimate, and we plan around them on every engagement.

The outdated reasons are the ones that keep most owners stuck. "Build takes six months." "Build costs six figures." "Build needs a team of senior engineers." Those were the realities of 2010–2020, and they shaped a generation of buy-by-default thinking.

AI-assisted development has collapsed the timeline and the cost. Builds that used to take six months now ship in 8–10 weeks. Budgets that needed six figures run a fraction of that. Adoption is easier when the tool is shaped around how the team actually works, not the other way around.

The biggest shift is quiet but enormous. Enterprise-grade systems — multi-stakeholder approvals, audit trails, role-scoped access, integrations across legacy systems — are now within reach for SMBs at SMB cost. That used to be a Fortune 500 privilege. It isn't anymore.

Why we say this with confidence

Our founders, Raghav and Prachi, spent years at Infosys building exactly these kinds of systems for Fortune 500 companies. The patterns are the same — multi-stakeholder approvals, audit trails, role-scoped access, integrations across legacy systems. They just used to cost millions and take 18 months. AI-assisted development collapses both. We've watched the same patterns from both sides of the company-size line, and that's the lens behind every recommendation here.

Where the manufacturer landed

The dealer portal went live. Zoho is still humming, doing exactly what it always did for the internal team. The dealers have their own surface, scoped to what they need, and the founder stopped paying the per-seat penalty they were about to walk into. Quotes flow back. Leads flow forward. Nobody had to learn a new CRM.

The real win wasn't the portal. It was that the framework gave the founder permission to stop thinking about the decision in binary terms. Standard SaaS for standard work. Custom for the work that defines you. Wrap, don't replace, when something already works.

Most owners we meet are forcing at least one workflow into the wrong tool. That's the cost of the default — and it's the one decision that separates SMBs that get unstuck from the ones that stay stuck.

If any of this sounds like your business, our case studies show how we've helped clients break out of these exact patterns. If you'd rather talk specifics, book a 30-minute conversation.