Build vs Buy for Internal Software
When to build custom internal software and when to buy a platform, with the five signals that make custom the right answer and the maths that decides most cases.
Build versus buy is the recurring conversation of any operations function that has been around long enough. It usually starts as an argument and ends as a spreadsheet, and the spreadsheet usually loses to whoever wanted the answer they wanted going in. This is the method we use to make the call honestly, and it covers the same ground as our earlier notes on build vs buy for AI features but for the broader question of internal software.
TL;DR
- Default to buying. Platforms are cheaper, faster and easier to hand over than most engineers admit.
- Five signals push you towards custom: cost curve, performance, proprietary logic, data residency and vendor risk.
- One signal is a conversation. Three signals is a build.
- The hybrid is usually right: platform for the workflow, your own service for the parts that need to be portable.
- Custom is cheapest at scale and most expensive to start. Be honest about which phase you are in.
Start from buying
A platform implementation gets a working tool into production in weeks and costs less than most teams estimate. It handles auth, permissions, deploys, monitoring, upgrades and backup for you, and every one of those is something a custom build has to reproduce. Engineers underrate this because the happy path of a custom tool is genuinely simple. The cost is not in the happy path. It is in the retries, the credential rotation, the audit log and the runbook.
Buying also lets your team change their mind. A Retool app rebuilt three times as the team learns what they actually want is the normal shape of internal software adoption. Custom code makes each rebuild an engineering project. That does not make custom wrong, it makes it unsuitable for the early exploratory phase.
The five signals that buying has run out of road
1. The cost curve has inverted
Platforms are billed per user, per entry or per action. That is excellent value at low volume and poor value at high volume. When the monthly bill for a platform exceeds the fully loaded cost of an engineer amortised across a year, plus a share of hosting, the economics have flipped. That crossover typically arrives somewhere past a few hundred users on tools like ClickUp or Retool, though it depends heavily on the platform. The trap is that it arrives gradually, and nobody is watching the trend.
2. Performance or latency matters
Platforms are built for the average customer, not the extreme case. If the tool has to render sub-second at very high concurrency, or handle event volumes the platform's underlying architecture cannot serve, the platform will hit a wall. Custom code lets you make different tradeoffs. That said, most internal tools do not have this problem; if you are considering custom for performance reasons alone, verify that the platform actually cannot serve your workload before you assume.
3. The logic is genuinely proprietary
If the tool encodes something you would not want on a vendor canvas, it should not be on one. Not because the vendor will steal it, but because business logic that matters deserves version control, tests and code review, none of which a platform canvas provides. This is the strongest signal on the list. Even when the other four say buy, if this one is true, at least the logic layer should be custom code called from the platform.
4. Data residency
Regulated data with a residency clause forces you off managed SaaS. Self-hosted platforms (Retool self-hosted, Strapi self-hosted, n8n self-hosted) solve this without going fully custom, so this signal on its own pushes towards self-hosting rather than towards code. Combined with signal three it pushes towards code. The legacy system modernization guide covers the shape of these migrations.
5. Vendor risk
Forty tools on one platform with no written documentation is a business continuity issue, not an engineering preference. The mitigation is not necessarily building, it is documenting each workflow so a rebuild elsewhere is possible. But when the concentration becomes uncomfortable and the vendor is showing signs of consolidation, pricing changes or strategic drift, custom or self-hosted alternatives deserve serious consideration.
Scoring the signals
| Signals present | Recommendation | Reasoning |
| None | Buy, and stop reading | A platform will do this faster and cheaper |
| One | Buy, but plan the exit | Document the workflow properly and keep logic portable. Revisit in six months |
| Two | Hybrid | Platform for the workflow, your service for the part that triggered the signal |
| Three or more | Build | The platform is now costing more than it saves, in money, speed or risk |
| Signal 3 alone | Hybrid at minimum | Proprietary logic belongs in version control regardless of the other signals |
The hybrid, which is usually the right answer
The false binary of build versus buy hides the option most teams should actually take. Let the platform handle what platforms are good at: connectors, credentials, scheduling, retries, permissions, an interface non-engineers can edit. Move the part that triggered the signal into your own service, exposed as an API the platform calls. So a Retool app might trigger a workflow, call your own scoring service for the decision, then write the result back through Retool. The platform never sees the algorithm. Your engineers never build a scheduler. Same pattern as the plug and play integration approach we use for SaaS integrations.
What each path costs, honestly
| Platform | Custom | Hybrid | |
| Time to first working tool | Days | Weeks | Weeks |
| Build cost | Lowest | Highest | Middle |
| Run cost at low volume | Low | Higher (hosting regardless) | Middle |
| Run cost at high volume | Highest | Lowest | Low |
| Who can change it | Ops team | Engineers only | Both, by layer |
| Retries, logging, alerting | Included | You build it | Mostly included |
| Portability | Poor | Total | Good |
| Ongoing attention required | Low | High | Medium |
The row people underestimate is the last one. Custom code needs someone who cares about it: dependency updates, certificate rotation, the deprecated API upstream. Budget this as an ongoing retainer rather than pretending the build is the whole cost.
Three situations we see repeatedly
- The early-stage startup that built custom too early. Two engineers spent six weeks writing a custom admin panel to save a $150 per month Retool subscription, then spent a further year maintaining it. The subscription would have been cheaper for many years.
- The mid-market team that stayed on a platform too long. Fifty tools on ClickUp, undocumented, four figures a month in licences, and nobody who could describe half of what was running. Migration cost more than three years of the subscription they were trying to escape.
- The enterprise that built everything custom because procurement was slow. A genuine organisational constraint rather than a technical one, worth naming honestly, because the answer is to fix procurement rather than to write more code.
How to decide this quarter
- Count your current platform spend and project it at three times the current usage. If uncomfortable, that is signal one.
- Ask which tools encode logic you would not put on a vendor canvas. If any, that is signal three, and it outranks the others.
- Identify any tool that is business-critical and undocumented. Fix that today, whichever path you choose.
- If you are unsure, buy. You can move later at a known cost. You cannot get back the weeks spent building the wrong thing.
- Revisit annually against the same signals, not never.
If the answer is build, our custom software development and custom web applications services cover the shape of that engagement. If it is buy, our internal tools development guide covers the platform decision in more detail.
Frequently Asked Questions
Should we build or buy our internal software?
Buy first. Platforms are cheaper to start with, ship faster, handle the boring operational plumbing for you, and let your team change their mind cheaply during the learning phase. Move to custom when at least three of five signals apply: inverted cost curve, performance requirements, proprietary logic, data residency or vendor risk.
When does a platform become too expensive?
When the fully loaded monthly cost exceeds the amortised cost of an engineer plus a share of hosting for a comparable custom build. That crossover depends on the platform and the usage pattern, but as a rough guide, per-user platforms like ClickUp or Retool start to fund an engineer somewhere past a few hundred users. It arrives gradually, so watch the trend.
What is the hybrid approach?
The platform handles connectors, credentials, scheduling, retries and the interface. Your own service holds the business logic, exposed as an API the platform calls. You keep the platform's operational plumbing and the valuable business logic stays portable. This is usually the right answer when at least one but fewer than three signals apply.
How much does it cost to migrate off a platform?
Plan for thirty to fifty percent of the original build cost per tool, and more where the original was never documented. Tools rarely port between platforms, so a migration is a rebuild from a specification, which is why writing the specification at build time is worth the hour it takes.
Can we build custom internal software without a big engineering team?
You can build it. Whether you can maintain it is the harder question. Custom software needs someone who will notice a failed job at two in the morning and update dependencies before they become vulnerabilities. If that person does not exist, buy or use a maintenance retainer. Custom without maintenance ends badly.
Does self-hosting count as building?
No, it sits between the two. Self-hosted Retool, Strapi or n8n gives you data residency and cost independence while keeping the visual interface, connector library and retry handling. You take on hosting, upgrades and monitoring in exchange. For teams whose only trigger is signal 4 (data residency), it is usually the right stop.
What if we already built custom and regret it?
Moving back to a platform is often easier than moving off one, because your logic is already in code and can be exposed as an API the platform calls. That is the hybrid, arrived at from the other direction, and it is a perfectly respectable place to end up. Do not treat rethinking the choice as an admission of failure; treat it as evidence you have learned what the workflow actually needs.
How do we stop this decision being reopened every six months?
Write down the signals you are watching, the thresholds that would change the answer (specific monthly spend, specific latency requirement) and review annually against those thresholds rather than relitigating from first principles whenever someone reads an article.
Ready to scope a platform implementation? Book a free 45 minute scoping call. We will map the workflow, name the platform decisions that matter, and give you a written scope before you commit.