What does it cost to keep an internal tool running?

A server bill is an input to operating cost. It is not the operating cost. For a small internal tool, the infrastructure may be inexpensive while the effort to diagnose a broken integration is substantial. The useful question is not “Which host is cheapest?” It is “What must remain available, who takes responsibility, and what happens when it fails?”

This guide is a budgeting method, not a hosting quote. Prices vary by workload, supplier, region, availability requirements and the people involved. We deliberately avoid a universal monthly figure: a lightweight dashboard and a business-critical approval system do not need the same arrangement.

Start with the business consequence

Write down what happens when the tool is unavailable for an hour, a day and a week. Can the team use a spreadsheet temporarily? Are customer commitments missed? Does the application merely display data, or does it execute payments, delete records or make irreversible changes?

Then describe the data consequence. Losing a day’s disposable cache is different from losing a day’s customer submissions. These answers define useful targets for recovery time and acceptable data loss. They are decisions for the business owner, not numbers a hosting package should quietly choose on your behalf.

An internal application used during European office hours may reasonably have a different support agreement from a public service used continuously. “Managed” does not itself mean round-the-clock incident response. Ask for the hours, contact method, escalation process and exclusions in writing.

Separate the five budget lines

Infrastructure includes application compute, the database, storage, network transfer and domains. Include environments used for testing and recovery. A free tier can be a sensible experiment, but its limits, sleeping behaviour or lack of a service commitment may be inappropriate for a team dependency.

Third-party services include email, identity, external APIs, observability and AI model calls. Check whether the charge follows users, requests, stored data or tokens. Variable spending deserves an owner, alerts and a decision about what happens when a budget is reached.

Routine maintenance includes dependency updates, certificate and credential handling, backup checks, restore exercises and deployment upkeep. Even a quiet application changes because its dependencies, browsers and external providers change.

Incident support is the capacity to investigate unexpected problems. Define whether it is included, limited to an allowance, or billed separately. A response target states when someone starts responding; it does not promise a resolution by the same deadline.

Product changes are new features and altered workflows. Keep them visible instead of hiding them in “maintenance”. Adding a new approval role is development even if it looks like a small dropdown in the interface.

Build a workload estimate you can explain

List active users, expected concurrent sessions, typical requests, database growth, file storage and scheduled jobs. If you do not know, label the number an assumption and measure it during a limited pilot. Avoid buying for an imagined million users while overlooking the import job that already exhausts memory.

Look for bursts as well as averages. A monthly report might read the entire dataset in one request. An automation can send thousands of emails after a configuration error. A retry loop can create an unexpected API bill without any increase in legitimate users. Capacity planning should include limits and failure behaviour, not merely larger machines.

For AI-backed features, estimate input and output separately and include retries. Ask whether the application can continue in a reduced mode when a provider is unavailable. Do not assume that a lower-priced model is interchangeable without checking the work it performs.

Budget for recovery, not just backup storage

A successful backup task does not establish that the service can be restored. Recovery also needs database credentials, encryption keys where applicable, compatible application versions, configuration, uploaded files and instructions that someone else can follow.

Keep a recovery copy separate from the system it protects. Define retention and access. Test restoring into a disposable environment, inspect the restored records, and record how long it took. If uploaded files live outside the database, test that they remain accessible and consistent too.

The Google SRE workbook’s discussion of eliminating toil explains why repetitive operational work deserves deliberate engineering. Its examples come from a much larger operating context; a small tool does not need Google’s infrastructure. The relevant principle is to identify repeated work, reduce avoidable manual steps and leave clear procedures for the work that remains.

Make responsibility explicit

A useful agreement names the application owner and the operator. It answers who approves updates, who can access production data, who receives alerts and who decides when to disable a faulty integration. It also covers what happens when the original builder leaves.

Keep ownership of domains and important supplier accounts with the business. Give providers the access they need through controlled accounts. A future handover should not depend on a developer’s personal inbox or an undocumented laptop. Ask how code, configuration and data can be exported at the end of the arrangement.

Platform93 can be a component of an application platform where its capabilities fit. It is not a substitute for understanding the application, operating its database or agreeing on support. We choose components after assessing the workload and ownership model.

Compare proposals on the same basis

Give prospective operators the same short brief: application stack, environments, usage estimate, data categories, required service hours, recovery targets and known problems. Ask each to separate setup work from recurring service and variable supplier costs.

Read the exclusions. Are application bugs investigated? Who handles an upstream API change? Is a database upgrade included? Are restore tests included or merely backups? What happens if usage grows? What is the cancellation and handover process? Differences here often matter more than a small difference in the server line.

An illustrative comparison might put infrastructure, maintenance allowance, support coverage and change work in separate columns. Do not treat a quote with a maintenance allowance as unlimited engineering. Equally, a low-cost infrastructure-only proposal can be perfectly appropriate if your team knowingly owns the remaining work.

A sensible first operating arrangement

For a small tool, start with a limited production audience, documented deployment, monitored critical paths and a tested restore. Give the arrangement a review date. Compare actual usage, incidents and support requests with the assumptions, then adjust resources or responsibilities.

The goal is not to eliminate every possible failure. It is to make routine operation predictable and exceptional situations manageable. If nobody can explain how the service is recovered or who responds, the missing budget line is not another server: it is ownership.

Launch a Tool’s hosting and care service starts with an assessment and a separate proposal. A Starter Review can identify operational gaps within its agreed scope, but ongoing hosting, maintenance and implementation are not included in the €420 review.