A founder messaged us recently: "We need a custom CRM."
The honest first response, as it usually is, was "Probably you don't."
For 80% of problems an operations team faces, off-the-shelf software is the right answer. Salesforce or HubSpot for CRM. Linear or Jira for engineering ticketing. Notion or Confluence for documentation. Retool or Internal.io for admin dashboards. These tools exist because the problem is common, the solution space is well-understood, and a thousand engineers have already solved the parts you'd otherwise have to.
But the 20% is real. The mistake is the same in both directions: building custom when you should have bought, or buying when you should have built. This post is about the signals that tell you which side of the line you're on.
The 80%: off-the-shelf is right
Most internal tool needs are some variation of:
- A way to view and edit rows in a database
- A way to send a templated email when a thing happens
- A dashboard showing a few KPIs
- A workflow that goes "form submission → approval → record updated"
For every one of these, there's an off-the-shelf tool. Sometimes ten. They cost between free and a few hundred dollars a month per seat. They're already tested. They have support teams. When you join a company that uses HubSpot, you already know how HubSpot works.
The cost of a custom build for any of these is a multiple of the off-the-shelf price, paid up front and then paid again every time the requirements change. The math doesn't work unless something else is in play.
The 20%: signals you should build
A custom tool starts making sense when one of these is true:
1. The workflow is the moat.
Your team does something differently from competitors, and that difference is why customers pick you. The workflow lives in the workflow. An off-the-shelf tool would force you to flatten it into Salesforce-shaped boxes, and the moat dilutes.
Example: a logistics company we know runs a custom dispatch tool because their dispatch algorithm is proprietary. Salesforce can't represent it. Building was the only option.
2. Integration cost exceeds tool cost.
You can buy four off-the-shelf tools that together handle the workflow, but the integration plumbing between them is more code than just building the thing custom. The "stack" becomes a maintenance burden the size of a small product.
Example: a marketplace ops team had Stripe + Airtable + Zapier + Retool. Five tools, four integrations, two engineers maintaining them. We replaced the lot with one custom internal tool. Less code overall.
3. Off-the-shelf prices you out of using it the way you need to.
Some tools have pricing models that penalise the use case you actually have. Per-record pricing when you have 10 million records. Per-API-call pricing when you have a high-volume workflow. Per-seat pricing when you want every employee to have access.
This is the most common case in our experience. The off-the-shelf tool can technically do the job. The pricing makes it economically irrational.
4. The data is too sensitive to hand to a vendor.
Compliance, audit, regulatory: certain industries can't put their core operational data in a third-party SaaS. The "where is the data stored" question has a wrong answer, and the answer is whoever you bought from. Build becomes the only path.
5. The integration with your product is too deep to bridge.
Your customer-facing product is custom. The internal tools that operate it need real-time access to product state. The latency and authorisation models of an off-the-shelf admin tool can't get close enough to feel native.
Example: a B2B SaaS we work with has a customer success team that needs to impersonate users to debug. Off-the-shelf admin tools can read the database. They can't safely re-issue auth tokens. Custom was required.
A concrete example
A team came to us thinking they needed a custom CRM. We took a week to audit the actual workflow. The output:
- 60% of the workflow was lead intake and qualification. HubSpot would handle this fine.
- 25% was a custom scoring algorithm based on signals from their product. HubSpot couldn't represent this without exporting to a sidecar.
- 15% was customer success ops with deep product integration.
The recommendation: HubSpot for the 60%, custom for the 25% (a scoring service that wrote results back to HubSpot), and a custom admin app for the 15%. The custom parts shipped in three months. The HubSpot setup took two weeks.
If they'd built the whole thing custom, it would have been a year of work to match HubSpot's lead management. They saved nine months by being honest about the 60%.
The hybrid pattern
The right answer is rarely "all custom" or "all off-the-shelf." It's usually a mix: SaaS tools for the common parts, custom for the differentiated parts, with integration code between them.
The mistake teams make is treating "build vs buy" as one decision for the whole stack. It's many decisions. Each workflow segment gets its own answer.
The framework we use:
- List the workflows. Each one, in plain language, end to end.
- For each, ask: is this how a thousand other teams do it, or is it specific to us?
- For the generic ones, look at off-the-shelf options.
- For the specific ones, ask: is it specific because it's a moat, or because nobody's bothered to fix the requirement?
The fourth question matters. Some "specific to us" requirements are accidental complexity that the team has accumulated. Off-the-shelf would force a useful simplification. Don't preserve weird requirements just because they're yours.
Hidden costs of custom
If the analysis points to custom, the costs to expect:
- Initial build: 2x what you estimate. Always. Internal tools have invisible scope.
- Maintenance: ~20% of build cost per year, ongoing.
- Onboarding: every new team member needs training on a tool that has zero Stack Overflow answers.
- Bus factor: if the original engineers leave, the tool becomes a black box.
- Feature parity drift: SaaS tools add features every quarter. Yours doesn't.
None of these kill a custom build that's actually justified. They do kill custom builds that should have been a Notion template.
When you'd come to us
For the 20% case, custom internal tools are a service we do well. The work is:
- A scoping conversation that's honest about what should and shouldn't be custom (we will tell you if we think you should buy instead).
- A design phase that maps the workflow as it actually is, not as the spec document says.
- A build phase using a stack that doesn't lock you in (TypeScript, Postgres, Next.js, all things any qualified engineer can pick up).
- A handoff that includes documentation good enough for the next team.
If you're staring at "we need a custom tool" and want a second opinion, start a conversation. Half the time we'll talk you out of building. The other half we'll quote it honestly.
See how we work on web apps for what the build phase actually looks like.