When a team decides to build and host an internal application itself, the budget usually covers the build and the servers. The real cost of self-hosting internal applications shows up later, spread across people's time in ways that rarely appear on one line of a budget. This article lists where that cost hides, how to estimate it for your own tools, and why a managed SaaS platform absorbs most of it.
Patching and dependency updates
Every self-hosted application sits on an operating system, a runtime, a web server, a database and a collection of third-party libraries. Each receives security fixes on its own schedule.
- Someone has to notice the fix exists.
- Someone has to apply it in a test environment, check nothing broke, and roll it out.
- Occasionally a library update changes behaviour, and the application needs code changes to keep working.
Skip this work and the application quietly accumulates known vulnerabilities. Do it properly and it takes steady engineering time for as long as the application exists. On Vibe, patching, dependency updates and secret rotation are handled by bizapps.io across every application, so no one on your team has to track them.
Backups, monitoring and on-call
Most self-hosted tools have backups. Far fewer have backups that anyone has actually restored. A backup that has not been restored is a hope, not a control.
Doing this properly means scheduled backups, retention rules, storage in a separate location, and periodic test restores with someone checking the result. It also means being able to restore to a point in time, because the most common data loss is not a disk failure but a mistaken bulk update. Vibe applications have point-in-time backups with tested restores as part of the managed platform; the platform page covers this.
An application that nobody monitors fails silently. The first sign is usually a user saying it has been slow for days, or that a nightly job stopped last week.
Real monitoring needs logs, metrics and traces collected somewhere, alerts with sensible thresholds, and a person who receives the alert and knows what to do. For an internal tool, that person is often the developer who built it, carrying an unofficial pager on top of their real job. Ask yourself who gets the call if your purchase approvals tool stops working late on a Friday. If the answer is a name rather than a rota, that is a cost and a risk.
Security reviews, again and again
Each self-hosted application has its own sign-in, its own permission model, its own logging and its own hosting setup. So each one needs its own security review, and each review tends to find the same gaps:
- No single sign-on, so leavers keep access until someone remembers.
- Coarse permissions, where everyone with access can see everything.
- No audit trail of who changed what.
- Unclear encryption of data at rest.
Fixing those gaps in one small application is disproportionate work, so it is often deferred. On a shared platform, the controls are built once and inherited by every application: SSO over SAML and OIDC, role-based access on every entity and action, audit logging, and encryption in transit and at rest. Reviewers assess the platform once rather than every tool separately. See can it pass our security review?.
Key-person risk
The most expensive hidden cost is also the least visible. Self-hosted internal tools often depend on the one person who built them. When that person moves role or leaves, the organisation discovers that nobody else knows how to deploy a change, where the backups are, or why a particular setting exists.
The application usually keeps running for a while. Then a change is needed, or something breaks, and a small tool becomes a small crisis. Documentation helps, but it rarely survives the pressure of day-to-day work. A managed platform reduces this risk because the operational knowledge sits with the provider, and because business users can make routine changes themselves.
Estimating the cost for your own tools
You do not need precise numbers to see the pattern. For each self-hosted internal application, write down:
- Who applies patches and updates, and roughly how often.
- Whether a backup has ever been restored and checked.
- Who receives alerts, and whether that is written down anywhere.
- When it last passed a security review, and what was left open.
- How many people could deploy a change today.
- How long a routine change, such as adding a field, takes from request to live.
Multiply the hours by what that time would otherwise be spent on. The answers often show that the running cost has long overtaken the build cost, and that some of it is simply not being paid, which appears later as risk. Our guide on how to cut the cost of internal tools extends this into a fuller method.
How managed SaaS changes the equation
A managed SaaS platform does not make these tasks disappear. It moves them to a provider who does them once, for every application, as their core job. With Vibe, that includes deployment pipelines with staged environments and one-step rollback, patching, dependency updates, secret rotation, point-in-time backups with tested restores, logs, metrics and traces, and capacity that follows demand.
What your team keeps is the part that is genuinely yours: the data, the process and the rules. Data and generated code remain exportable on any plan, so moving to managed hosting does not mean giving up ownership; see who owns the application and the data?. For the wider comparison, read no-code SaaS vs building business apps in-house.
Take one tool off your plate
Pick the self-hosted tool that worries you most and consider rebuilding it on a managed platform. You can do that yourselves on Vibe, or have our services team build it for you. Ahead of general availability, the design partner programme is open and free during the programme. Tell us about the application.