The Forgotten Reflex
In the late 2000s it was still normal for companies to build their own internal tools: the order system, the dispatch system, the commission calculator, the internal knowledge base. With the rise of SaaS, that reflex faded. "Why would we build it when we can buy it?" became the standard answer in every architecture meeting.
That answer was right for a while. It often isn't any more. A growing number of companies are building back-office tools themselves again – not out of nostalgia, but because the economics have flipped.
What No Longer Adds Up About Enterprise SaaS
Three problems compound the longer a company runs on Enterprise SaaS:
Pricing scales with the wrong factor. Per-seat licences, add-on modules for every other feature, per-connector charges for integrations. What starts as an affordable standard solution costs six figures a year three years in, with 200 users and six modules – without the tool getting noticeably better.
Feature breadth is wide and shallow. Enterprise SaaS has to cover every industry, every company size, and every use case. The result is tools with hundreds of features, most of them irrelevant, and the few that are really needed are often too generic to map onto the actual process. Workarounds, Excel crutches, and "that's just how we do it" solutions follow.
Speed of change collapses. Need a tweak in your workflow? Wait for the vendor's next quarterly release – or pay a consultant to bend the SaaS platform until it fits. Both are slow, both are expensive, both frustrate the team that uses the tool every day.
What's Now Technically Possible
Building internal tools used to be a nightmare for three reasons: too expensive, too slow, too high-maintenance. All three are gone.
Building is cheap. An AI-assisted development team builds an internal order system with approval workflow, reporting, and Slack integration in two to four weeks. Five years ago that was three to six months. Costs are now often lower than a year of licence fees for the SaaS alternative.
Components come as Lego. Auth from Auth0 or Clerk, databases from Supabase or Neon, UI components from shadcn, workflow engines from Temporal, reporting from Metabase. From these blocks, a productive tool can be assembled without the team reinventing authentication, data modelling, or reporting from scratch.
Maintenance is manageable. What used to be "someone should look after this" is today often small and focused enough that a single developer maintains it on the side. On top of that: AI-driven code reviews, automated refactoring, and test generation have cut maintenance overhead drastically.
What's Changed About the Value
Ten years ago, Enterprise SaaS delivered value an internal tool couldn't match: years of product development, a broad feature list, best practices from thousands of implementations. That value proposition has eroded.
Best practices are now public. How an order process should be structured, what a pipeline visualisation should look like, how an approval workflow works – all documented in blogs, in open-source projects, in the heads of every developer who's ever worked at a mid-sized company. AI amplifies this: it pulls best practices into every code suggestion.
Broad feature lists are a burden. What used to be sold as a strength – "1,200 features out of the box" – is now often the weakness. Employees can't find the functions they need or don't understand the concepts. Internal tools have the advantage of containing exactly what's needed, and nothing beyond it.
Your own processes don't have to bend. That's the real lever. An internal tool that exactly mirrors your workflow saves five to fifteen minutes per employee per day in clicks and copying. With 50 employees, that's several person-days a week flowing back into actual work.
Where Internal Tools Are the Right Answer
Not every area fits. Internal tools play to their strengths where three conditions converge:
The process is company-specific. Anyone with a workflow that differs from most other companies – for historical, regulatory, or strategic reasons – suffers especially under generic SaaS tools. An internal tool pays off most strongly here.
The user group is clearly bounded. Internal tools work best for internal teams with a clear use case: dispatching, accounting, sales ops, HR. Where external audiences or large user counts come into play, the cost-benefit ratio gets harder.
Integration with your own data model is valuable. A tool that taps seamlessly into internal data, without the export-import dance, beats any SaaS tool offering only standard interfaces. The deeper the integration needs to be, the stronger the case for building.
Where Enterprise SaaS Still Wins
Three areas remain SaaS territory:
Highly regulated standard processes. Payroll, accounting, tax. Here, a good vendor delivers regulatory compliance as a service. Maintaining that internally is risky and expensive.
Collaboration with external parties. Email, video conferencing, shared documents. The platform everyone uses wins because network effects matter. Nobody wants to run their own Zoom.
Specialised verticals with real depth. High-end industry software – clinical trials, actuarial work, specific logistics segments – offers decades of accumulated domain knowledge that can't be rebuilt in two weeks.
In these areas, SaaS vendors aren't going anywhere. Outside of them, the advantage is getting thinner.
What the Transition Looks Like in Practice
Companies that make this move successfully tend to follow a similar pattern:
A pain point first, a strategy later. It rarely starts with a resolution to "build more ourselves". It starts with one specific tool being particularly annoying, an internal replacement getting built, and everyone realising: that went faster than expected and fits better. The individual case becomes a pattern, the pattern becomes a strategy.
Platform thinking, not tool thinking. Companies building internal tools systematically end up with their own internal platform after three to five tools: shared auth, shared data models, shared UI library. That platform makes the next tool even cheaper and faster.
Clear ownership. Internal tools need a responsible owner – someone who understands both the tech and the process. Without ownership, internal tools become orphans.
At nh labs, we accompany exactly this transition in many projects. It often starts with an honest comparison of the TCO of an existing SaaS tool versus the estimated effort of in-house development – and the maths comes out quite differently than most participants expected.
Bottom Line
Internal tools are back. Not as a fallback for companies that can't afford Enterprise SaaS, but as a strategic choice for companies that want to control their processes, their data, and their speed themselves. Enterprise SaaS remains useful – but the default reflex "let's buy something for that" is losing its justification. Anyone who builds a few annoying internal tools over the next two years and realises how much cheaper and better the result is will look at the next licence renewal much more critically. That wave has just started.