Build vs Buy: When a Custom Internal Tool Beats Another SaaS Subscription

Most growing companies reach a point where their software stack looks like this: a CRM, an accounting package, a helpdesk, a project tool, two or three niche SaaS products, and a set of Google Sheets that hold everything together. Someone spends part of every day copying data between them. When a new need comes up, the reflex is to find another subscription.

Often that's the right call. Sometimes it isn't, and a small custom tool would fit better and cost less over time. This guide gives you a way to make the build vs buy decision for internal tools deliberately, rather than by habit.

Start with a bias toward buying

Let's be clear up front: for most problems, buying is the better choice. Accounting, payroll, email, CRM, helpdesk, HR systems: these are mature categories where vendors have spent years on features, security and compliance. Building your own version of any of them is almost never worth it.

Buying makes sense when:

• The process is standard across most businesses, and you're happy to follow the tool's way of working.
• A product exists that covers most of what you need without heavy workarounds.
• The vendor handles things you don't want to: compliance, tax rules, security certifications, uptime.
• You need it working this week.

Signs that building may win

The case for a custom internal tool gets stronger when several of these are true:

• The process is specific to how you operate. Your quoting rules, your production scheduling, your approval chain. If it's part of what makes you different, forcing it into a generic tool tends to mean workarounds.
• You're paying for a big product to use a small part of it. A platform with dozens of features, bought for one workflow, priced per seat across a growing team.
• The real work happens in spreadsheets between tools. If staff export from one system, fix the data in Sheets, and import into another every day, the gap between tools is your actual problem, and no single SaaS fills it.
• Integration is the hard part. You need data from your ERP, your Shopify store and your CRM in one screen, and none of the vendors talk to each other in the way you need.
• Seat-based pricing scales badly for you. Lots of occasional users (warehouse staff, field reps, partners) who each need a small view.
• You need control over the data or logic, for example where it's stored, how calculations work, or how AI is applied to it.

The middle options

Build vs buy is rarely binary. Between "subscribe" and "write a custom app from scratch" sit some useful options:

• Configure what you already own. Custom objects in HubSpot or Salesforce, Shopify Flow, Airtable automations. Often the cheapest answer, until the configuration becomes so complex that only one person understands it.
• Glue with workflow tools. Make, n8n or Zapier can move data between systems on a schedule or trigger. Good for straightforward syncing. Less good when logic gets complicated, volumes are high or you need a proper user interface.
• Low-code internal tool builders. Retool, Appsmith and similar platforms let you put screens on top of your databases and APIs quickly. They're a solid fit for admin panels, though they bring their own per-user pricing and limits.
• Extend a SaaS product through its API. Keep the vendor for the core and build a small app for the part that's specific to you. This is often the sweet spot.

A good rule: try the lightest option that can work, and move up only when you hit a real limit.

Compare total cost, not sticker price

People tend to compare the monthly subscription against the build quote, which flatters both sides in different ways. A fairer comparison looks at three years and includes the costs people forget.

Buying: often forgotten	Building: often forgotten
Seat growth as the team expands	Hosting, database and monitoring
Price increases and plan changes	Ongoing maintenance and small changes
Add-ons needed for key features	Security updates and dependency upgrades
Time spent on workarounds and manual exports	Model usage, if the tool uses AI
Integration tools to connect it to everything else	Someone who understands the code long term
Switching costs if the vendor changes direction	Your team's time during discovery and testing

The "time spent on workarounds" line is the one that changes most decisions. If three people each spend an hour a day reconciling data between systems, that's a cost the subscription quote doesn't show, and it continues for as long as the workaround does.

A simple scoring checklist

Score each statement from 0 (not true) to 2 (very true). The higher the total, the stronger the case for building.

1. The workflow is specific to our business and affects how we compete.
2. We've tried existing products and each needs significant workarounds.
3. The main pain is moving data between systems we already have.
4. Many people need small, role-specific views rather than the full product.
5. Per-seat pricing grows faster than the value we get.
6. We need control over where data lives or how logic works.
7. The process is stable enough that we can define it clearly.
8. We have, or can arrange, ongoing maintenance.

The last two matter more than they look. If the process is changing every month, building is risky because you'll be rebuilding constantly. And if nobody will maintain the tool, it will eventually break at a bad moment.

A worked example

Consider a hypothetical industrial parts distributor. Sales reps build quotes in a spreadsheet using price lists exported from the ERP, customer-specific discounts kept in another sheet, and freight estimates from a carrier website. Approved quotes are retyped into the ERP as orders. Managers have no view of open quotes except by asking.

They look at a quoting SaaS product. It handles quote documents nicely but can't apply their tiered discount rules, has no integration with their ERP, and charges per seat for every rep and manager.

The alternative is a focused internal tool: a quote builder that pulls live prices and customer terms from the ERP through its API, applies their discount rules, fetches freight estimates, produces the PDF, and pushes accepted quotes back as orders. A manager dashboard shows open quotes by rep and age. Optionally, AI can read customer RFQ emails and pre-fill a draft quote for the rep to check.

In this case building scores well: the logic is specific, the pain is integration, and the process is stable. But it's not automatic. If their ERP had a decent quoting module, configuring that would likely be the better first step.

What a good internal tool looks like

If you do build, aim for something small and dull in the best sense. The internal tools that last tend to share a few traits:

• One clear job. "Build and track quotes" rather than "manage the sales process."
• Other systems stay the source of truth. The ERP keeps prices, the CRM keeps contacts. The tool reads and writes through their APIs rather than keeping its own competing copy.
• Screens designed around the actual task. The fields a rep needs, in the order they need them, rather than every field in the database.
• Clear roles. Reps see their own quotes, managers see everyone's, finance sees margins.
• Logs and alerts. When a sync fails, someone hears about it before a customer does.
• AI only where it helps. Reading unstructured inputs like emails and PDFs, summarizing, drafting. Prices, discounts and approvals stay as explicit rules.

A tool like this is often a matter of weeks to a first version rather than months, precisely because it does one thing. The longer projects are the ones that try to replace an entire category of software.

Questions to ask before you decide

• If we buy, what will we still be doing by hand a year from now?
• If we build, who fixes it when it breaks on a Saturday?
• What happens to our data if we cancel the subscription, or stop maintaining the tool?
• How many people will use this in two years, and what will that cost under each option?
• Is this process likely to change significantly in the next year?

Risks of building, and how to reduce them

• Scope creep. Internal tools attract feature requests. Define a first version tightly and keep a list for later.
• Single point of knowledge. Insist on documentation, tests and a mainstream stack (for example Next.js and Postgres) so any competent developer can pick it up.
• Abandonment. Agree up front who maintains it and how small changes get made.
• Security. Internal doesn't mean low-risk. Use proper authentication, role-based access and audit logs, especially if the tool touches financial or customer data.
• Rebuilding a commodity. If you find yourself recreating a full CRM or accounting system, stop and reconsider.

Risks of buying, and how to reduce them

• Lock-in. Check that you can export all your data in a usable format.
• Tool sprawl. Every new subscription adds a login, a data silo and an integration to maintain. Count them.
• Process bending. Make sure you're adapting to the tool because its way is better, not just because it's the only option.

Making the decision

Write down the workflow, the people involved, the systems it touches and what it costs today in time and errors. Shortlist two or three products and one build option, then compare them on fit, three-year cost, integration and risk. Often the answer is a hybrid: keep the SaaS that does the commodity work, and build a small tool for the part that's yours.

If building comes out ahead, our internal tools service covers exactly this kind of focused app, and our API integration work handles connecting it to the systems you already run. Sometimes the right answer is lighter still: plain workflow automation between existing tools. You'll find more examples of where this fits on our operations page.

If you'd like an outside view on a specific decision, tell us about the workflow. We're happy to say when an existing product is the better choice.