← All posts
'Internal tool vs buying software: the cut line for SMBs and early SaaS'
'Internal tool vs buying software—when to keep SaaS/low-code, when a fixed-scope custom app beats another license for distributors and founders.'
Internal tool vs buying software is never “build everything” against “buy everything.” For regional wholesale distributors, multi-location operators, and technical SaaS founders across the US and EU, the real question is narrower: which staff workflows stay on licensed SaaS or low-code, and which ones deserve a fixed-scope custom app your team actually owns.
At Wolverine Solution we usually get pulled in after the spreadsheet phase, right before another seat pack hits the card. The stack in the room is familiar: NetSuite, Microsoft Dynamics 365 Business Central, QuickBooks Online, Salesforce, HubSpot, Airtable, Retool, Appsmith, Zapier / Make, Slack, Notion, and a pile of Google Sheets. So are the roles — ops lead, AR/credit, warehouse supervisor, franchise or field manager, support eng, founding CTO. Three delivery options are on the table: another SaaS module, a Retool/Appsmith internal app, or a React / Next.js + PostgreSQL tool on AWS or GCP with Auth0 or Clerk and Terraform.
If you got here searching wolverine software, this is the agency framework — not Marvel merch, not a PC brand. We ship fixed-scope internal tools, SaaS dashboards, and customer portals. We don’t sell PBNs, link packages, or “digital transformation” retainers with no definition of done.
Companion cut lines, different keywords, same discipline: [Internal link: custom software vs off the shelf for distributors] and [Internal link: when to replace spreadsheets with custom internal tools].
When should you choose an internal tool vs buying software?
Buy when the workflow is commodity, the vendor already encodes the happy path, and your team will genuinely live in their UI without a permanent spreadsheet side-car. Build when the process encodes your rules — credit overrides, account price exceptions, multi-location approvals, feature-flag admin — and another license would still leave staff copying data between systems every single day.
That’s the whole decision. Where “internal tool vs buying software” goes wrong is when leaders turn it into brand preference (“we hate SaaS”) or engineering ego (“we build everything”). Score the workflow. Not the vendor pitch deck.
Who should decide:
- Owner / GM (budget ceiling, fixed-scope vs open-ended)
- Process owner (AR, ops, warehouse, support—whoever eats the exceptions)
- IT or fractional CTO (Auth0/Clerk, APIs, hosting ownership)
- One person who can freeze scope on a one-page functional spec
What does “buying software” actually mean in this decision?
Buying software means paying for a maintained product — SaaS seats, a low-code platform, a vertical module — where the vendor owns the schema, the upgrades, and most of the UI. It wins when your process fits their happy path and you have no intention of staffing engineers to maintain a ledger, CRM, or ticket queue yourself.
Buy, or keep buying, when most of these hold:
- The process matches a mature product category. Ticket queues (Zendesk, Intercom), basic CRM (HubSpot, Salesforce), GL (QuickBooks Online, Xero), core inventory math (Fishbowl, Cin7 Core, NetSuite Inventory).
- Configuration removes the pain. Fields, workflows, and permissions cover 80%+ of cases without a parallel spreadsheet.
- You will not own the data model. Ops can live in vendor UI; you do not want Postgres migrations for commodity objects.
- Integrations already exist. Native connectors or Zapier/Make bridges are enough; you are not inventing a new system of record.
| Buy path | Typical products | Good for |
|---|---|---|
| Horizontal SaaS | HubSpot, Salesforce, Zendesk, Monday.com | Standard CRM, tickets, light project tracking |
| ERP / IMS modules | NetSuite, Dynamics 365 BC, Fishbowl, Cin7 | Ledger, stock, receiving, basic reorder |
| Low-code internal apps | Retool, Appsmith, Budibase, Softr | Admin UIs over existing APIs when rules stay simple |
| Glue | Zapier, Make, native webhooks | Simple syncs without a custom service layer |
Don’t confuse “we dislike the UI” with “we must rebuild the system.” Hate the UI? A read-only ops dashboard or a Retool view is often enough. Hate the rules the product can’t express? That’s usually custom — not another seat tier.
When does a custom internal tool beat another software license?
Custom wins when your bottleneck is proprietary rules or cross-system exceptions, and no amount of configuration stops the repeated data entry, the delayed approvals, or the quiet policy breaks. Fixed-scope React/Next.js tools earn their keep when two or more expensive workflows sprawl across ERP, CRM, email, and Sheets with no clean product fit anywhere.
Build, or tightly customize, when you recognize these:
- Credit hold → override → first ship paths AR will not trust in a generic storefront or CRM stage.
- Account / branch / promo pricing that lives in Sheets because NetSuite or Dynamics price books cannot encode the contract without weekly admin heroics.
- CSR or franchise approval queues that need audit trails finance accepts—not Slack “LGTM.”
- Feature-flag or entitlement admin for an early SaaS before LaunchDarkly + a full admin suite is worth the complexity—but hardcoded toggles in app code are already breaking releases.
- Inventory aging alerts or exception queues where a full WMS is overkill and Monday.com is not inventory-aware.
- Staff re-key the same order, customer, or location data between three systems every day.
- A spreadsheet still controls a process that moves cash, inventory, or customer commitments.
On our engagements, “custom internal tool” means:
- React or Next.js staff UI (not a public marketing site)
- PostgreSQL for app state; quantities, invoices, and tickets still sourced from ERP/CRM APIs where possible
- Auth0 or Clerk with role-based access (ops vs AR vs warehouse vs founder admin)
- Hosted on AWS or GCP; Terraform when the client wants portable ownership
- Optional LLM exception triage later—with human-in-the-loop gates—not as the system of record
[Internal link: custom internal tools agency for wholesale distributors]
How should you score internal tool vs buying software module by module?
Go module by module. Buy the commodity work with a healthy vendor ecosystem behind it. Build where the module encodes your contracts, credit policy, location rules, or product entitlements and SaaS would force permanent workarounds. Before you fund a custom codebase, rate three things: how differentiated the workflow is, how often the rules change, and whether a Retool or Appsmith layer over bought APIs already covers it.
| Workflow | Default | Why |
|---|---|---|
| CRM pipeline, email sequences | Buy | HubSpot / Salesforce already own that schema |
| Support ticket inbox | Buy | Zendesk / Intercom beat a custom mailbox |
| Stock ledger, pick/pack | Buy | Fishbowl / Cin7 / NetSuite own barcode + locations |
| Account-specific price + credit gate | Build (often) | Your risk model, not a storefront feature |
| Multi-location marketing asset approval | Build or specialized DAM | Approval + expire beats another file library |
| SaaS feature-flag admin (pre–paying users) | Build thin or buy LD later | Week-0 matrix + audit often beats enterprise flag suite |
| PR preview / ephemeral envs | Buy platform pieces + thin glue | Use Vercel/Railway/Fly patterns; custom only the kill-list policy |
| Full ERP replacement | Almost never first | Disruption dwarfs internal-tool ROI for SMB / early SaaS |
The cut line we use in workshops: if you can write acceptance criteria on one page — screens, roles, critical actions, and an explicit “not building” list — the workflow is a candidate for a fixed-scope engagement. Can’t get it on one page? Buy time with process, a SaaS trial, or a Retool spike before anyone opens a production React app.
What does a hybrid stack look like in practice?
A hybrid stack leaves the bought systems as systems of record and drops a custom internal tool exactly where staff touch exceptions. NetSuite or Dynamics stays truth for orders and inventory. HubSpot or Salesforce stays truth for pipeline. A thin Next.js app absorbs the approval, pricing, or exception queue your SaaS can’t express cleanly.
Three concrete patterns from US/EU SMB and early SaaS work:
- Regional distributor — CSR exception console. Buyer order posts to NetSuite via REST. Credit hold blocks submit. CSR resolves missing price, partial ship, or FEFO lot conflict in an internal queue—not Outlook threads. Warehouse still picks in the IMS.
- Multi-location operator — proof-of-service / approval tool. Field staff capture photo + signoff in React Native (offline queue). Franchise marketing assets go through submit → approve → expire. Monday.com or Drive is not the audit trail.
- Seed SaaS — feature-flag admin before LaunchDarkly sprawl. Founding CTO needs a flag matrix, environment scopes, and who changed what. Hardcoded toggles die; a fixed-scope admin UI ships in weeks; enterprise flag platforms wait until seat math justifies them.
Custom around bought platforms, in other words — not a rewrite of either. It’s also how you stay portable across US and EU ops without pretending one horizontal SaaS understands every regional rebate, VAT nuance, and private-label pack rule.
How should you budget an internal tool vs buying software?
Budget bought software as recurring license plus admin time, forever. Budget a custom internal tool as a fixed-scope build plus hosting and a thin maintenance lane — not an open-ended agency retainer. For the teams we work with, the comparison that actually means something is annual SaaS sprawl plus shadow-labor cost against a one-time tool with clear acceptance tests.
Directional ranges, to validate in discovery — this is not a quote:
- Another SaaS seat pack or Retool seats: lower cash up front; high forever cost if workarounds remain.
- Fixed-scope internal tool (single workflow cluster): commonly a defined project in the tens of thousands USD depending on API depth—not a multi-year “platform” program.
- Hidden cost of “buy everything”: CSR or ops hours reconciling NetSuite + Salesforce + Sheets often dwarf the license line item.
Kill criteria for a custom project: no named owner, no one-page spec, no scope freeze, no metric (time-to-approve override, exception volume, hours pulled out of Sheets). Any of those missing? Stay on bought software and fix the process first.
FAQ
Is a custom internal tool worth it if we already pay for NetSuite or Salesforce?
Yes — when the gap is exception handling, pricing, credit, multi-location approvals, or staff UX, rather than modules you bought and never configured. The tool belongs beside NetSuite or Salesforce as an API-connected layer, never as a second ledger or CRM. If the bought product already does the workflow and the real gap is training, buy seats and write SOPs.
Should we start with Retool or Appsmith before a custom React app?
Usually, yes. Retool, Appsmith, and Budibase are strong when the UI is mostly CRUD over existing APIs and the rules stay simple. Graduate to a fixed-scope React/Next.js app when you need offline mobile, complex domain rules, public-grade UX, or ownership and portability the low-code vendor won’t hand you cleanly. Spike it first. Don’t guess.
Will a custom internal tool lock us into one agency?
Not if you own the code, the hosting, and the infrastructure-as-code. Insist on GitHub-hosted repos, Terraform on AWS or GCP, documented APIs, and a one-page runbook. Handoff to your IT team or a successor shop is part of done. What you want to avoid is black-box low-code only the original builder can change — and that builder can just as easily be a SaaS vendor as an agency.
Can we buy software now and add an internal tool later?
That’s the default path, and it’s the right one. Stabilize ERP/CRM, measure exception hours, then scope the single highest-ROI staff workflow: approval queue, credit gate, aging alerts, flag admin. Buying first for commodity objects is sane. Buying forever for commercial rules that are unique to you is how teams end up collecting workarounds.
How is this different from hiring a general app shop?
Internal tools for distributors, multi-location ops, and early SaaS are integration-heavy and rules-heavy. General shops tend to ship a pretty UI that still dumps every exception back into Slack and Sheets. You want a shop that draws the cut line against NetSuite/Fishbowl/HubSpot reality, freezes scope, and hands you a compounding asset instead of a demo.
CTA: If you are weighing an internal tool vs buying software for a specific workflow—CSR exceptions, credit holds, multi-location approvals, or early SaaS admin—book a fixed-scope discovery workshop with Wolverine Solution. You leave with a one-page spec, buy/build/low-code cut line, and a recommendation you can take to your GM or board. Start at wolverinesolution.com.
KPI / review: Organic clicks + assisted discovery requests from this URL; target ≥40 GSC clicks and 2 qualified discovery calls by 2026-10-16.