Most support teams don't begin with a purpose-built tool.

They start with a shared Gmail inbox, a spreadsheet, and someone refreshing it a couple of times a day. At two people, that's fine. You don't need ticket routing or a dedicated platform. You just need to respond quickly and not let things slip.

Some teams take it a step further - a lightweight RAG system so customers can self-serve. Scrappy, low-cost, gets the job done. At this stage, that's often the right call. The overhead of a proper support tool isn't justified yet.

Then growth happens.

More agents. More channels. More volume. And the setup that carried you this far starts breaking down. Conversations get missed. Response times stretch. Nobody knows what's wrong until a customer points it out.

That's where things start costing you.

Suddenly two priorities are fighting for the same attention: fix the support infrastructure, or keep building the business. You can't do both properly. And for a company in growth mode, taking your eye off the business is the riskier mistake.

That's when the build vs buy question stops being theoretical.

Before you answer it, one principle is worth holding onto:

if something isn't core to the value you deliver to customers, you should probably buy it.

Building non-core tooling rarely feels like a distraction at first. It becomes one. Maintenance overhead, engineering time pulled from your product, a tool that needs ongoing care - none of that is visible when you're looking at the initial proposal.

What building actually costs

AI has made early prototypes feel almost free. A weekend to spin something up, a month to ship. That's often true.

What doesn't get talked about is everything that follows.

Getting to a working prototype is relatively straightforward. Keeping a production tool running over time is a different problem entirely. That gap is bigger than most teams realise when they're looking at a working demo.

A basic ticketing and routing system typically takes three to six months before your team can actually rely on it - and that's assuming engineering has the capacity, which usually isn't guaranteed. Meanwhile, your support team is still grinding through the old setup.

On the numbers: the median US software engineer salary sits at $130,160 according to Bureau of Labor Statistics data. Fully loaded with benefits, taxes, and overhead, that's $160,000 to $180,000 a year for one mid-level engineer. That person isn't just building - they're maintaining, debugging, and extending the tool as your needs grow. Factor in infrastructure, API integrations, and every new feature your support team asks for, and the first year alone often costs more than several years of a bought solution would have.

There's also the risk that comes with ownership. Every bug is yours to fix. Every integration that breaks when an upstream API changes is your team's problem. When the person who built the thing leaves, what you're left with is undocumented code and knowledge that left with them.

None of this means you should never build. It means you should know what you're signing up for.

What buying actually costs

Buying has real costs too. An honest comparison requires looking at both sides clearly.

The main one is the subscription. Most tools charge per agent per month, so your costs scale with your team - no surprise infrastructure bills, no hidden debugging time, no engineering hours quietly disappearing into upkeep.

The fair pushback: per-seat pricing adds up. At $50 to $100 per agent per month across ten agents, you're looking at $6,000 to $12,000 a year. That's not trivial. But the right question isn't whether it costs money - it's how that figure compares to the true cost of building and owning the equivalent. For most teams, the comparison isn't particularly close.

On speed: purpose-built tools are designed to get teams up and running in days, not months. No engineering queue to wait in. No QA cycles. No competing with product priorities for bandwidth. When your team is already stretched, getting to value quickly matters.

The risks on the buy side are real, just different.

You're relying on a vendor to stay solvent, keep pricing fair, and build in a direction that continues to fit your needs. Data portability is worth thinking about - you should know you can export cleanly if you ever need to move. If your customers operate in regulated industries, compliance and data residency aren't optional items to check later.

These are legitimate things to pressure-test before you commit. But they're the kind of problems you can manage - unlike an internal build that's spiralled out of scope.

How to actually make the decision

Most build vs buy calls get made on instinct and a spreadsheet that only captures the obvious line items. There's a more useful approach.

Treat it like a product discovery problem. The same rigour you'd apply to validating a product bet - testing assumptions, running trials, checking estimates before committing - applies here too. A wrong call costs you in both directions.

Signals that point toward build

Building makes sense when the capability is genuinely core to your product or a real differentiator. When engineering has capacity and no higher-priority work competing for it. When your workflows are truly unusual - not just different from what you're used to - and existing tools genuinely can't accommodate them.

Worth asking: have you actually explored what bought solutions can handle, or is build just the path of least resistance?

Also worth thinking through: who owns this thing 12 months from now? What does the next iteration look like, and who builds it? What happens if the engineer who created it moves on?

Signals that point toward buy

Buying makes sense when engineering is needed on the core product. When you need to be running in days rather than months. When the standard features - routing, ticketing, reporting, escalations - cover the majority of what your team actually does.

The clearest signal: if a capability isn't part of what makes your product valuable to customers, buying it frees your team to stay focused on what is.

It doesn't have to be one or the other

Some teams land on a middle path - buy a core tool for ticketing and standard workflows, then build targeted custom layers for specific needs. A particular integration, an internal view, a reporting setup that matches how they operate. That can work well.

The thing to watch: make sure those custom additions don't slowly become their own maintenance problem. That's the path to getting the downsides of both approaches without the benefits of either.

Questions worth sitting with before you decide

If you're leaning toward build:

• What's the realistic engineering hour count - and what doesn't get built in that time?
• Who owns this after it ships, and what's the plan if that person leaves?
• Is your workflow genuinely unique, or does it just feel that way at this stage?
• Have you modelled the maintenance cost at 12 and 24 months, not just the initial build?

If you're leaning toward buy:

• Have you run an actual trial with real workflows, or only sat through a demo?
• Where does your customer data live, and does the vendor meet GDPR, CCPA, or other relevant requirements?
• Does the vendor hold SOC 2 or ISO 27001 certification?
• Can you export your data cleanly if you need to switch vendors?
• What does pricing look like if your team doubles?
• Is the vendor building toward where your support operation is headed?

The question that cuts through all of it

What does staying on your current setup cost you for another six months?

Sometimes the answer is manageable. More often it's higher than expected. Missed tickets, slower responses, agents working around tools that don't serve them, customers who quietly stop coming back because support felt like friction. Not a headline number. But it accumulates.

Support tooling isn't your competitive advantage. Your product is. Your team is. Your customers are. The real opportunity cost of building non-core infrastructure isn't just engineering hours - it's everything that doesn't get built while that attention is elsewhere.

The build vs buy question is ultimately about where your team's focus goes. Make it a deliberate call. Test before you commit. And whichever direction you choose, account for the full cost - not just what shows up on the invoice.