“Managed or self-hosted” is usually framed as a cost question. In practice it is a question about who holds the pager, who does the unglamorous work, and what the firm does when something breaks at 07:40 on the morning of a completion. Firms that decide on the licence price alone almost always underestimate the operational side — not because self-hosting is bad, but because the work is real and rarely itemised in a proposal.
Executive summary
Self-hosting a practice system is not difficult in the way that, say, writing the software is difficult. It is a standing obligation: releases arrive, certificates expire, backups fail silently, and someone has to notice. The obligation is small in a quiet month and considerable in a bad one.
This paper sets out the work item by item (§2), puts indicative hours and costs against each line so a firm can build its own total (§3), gives eight criteria that usually settle the decision (§4), describes the middle paths that most firms actually choose (§5), and states plainly where we sit on each path (§8).
1 · The question behind the question
When a partner asks “can we host it ourselves?”, there are usually three different questions inside it:
- Control. “I want to know where our data is and who can touch it.” Legitimate, and often satisfiable without self-hosting — provided the vendor can show the structure rather than describe it.
- Cost. “I do not want to pay a subscription for something we could run.” Sometimes right, frequently wrong once the hours are counted, and always worth modelling properly.
- Risk. “I do not want to depend on a small vendor.” The most important of the three, and the one self-hosting addresses best — if the software is open source, a firm can keep running it whatever happens to the vendor.
Separating these is the first useful step, because they lead to different answers. A firm motivated by control may be satisfied by an account it owns, with operations managed. A firm motivated by cost needs the full model in §3. A firm motivated by risk needs the exit path, not necessarily a server.
2 · What self-hosting really involves
The operational checklist, with an honest note on frequency and consequence for each line. Hours are indicative for a small firm with an existing IT capability, and assume nothing goes wrong.
| Work item | Frequency | Indicative effort | Consequence when neglected |
|---|---|---|---|
| Applying software releases | Monthly, plus security releases at short notice | 1–3 hours per release, including verification | Missed fixes; drift from the documented version |
| Testing before release reaches staff | Every release | 1–2 hours | A release breaks a workflow mid-week |
| Backups: schedule, verify, retain | Continuous schedule, monthly verification | 1 hour monthly, plus failures | Silent failure discovered during an incident |
| Restore drills | Quarterly | 2–4 hours each | An untested backup is a hope, not a plan |
| Monitoring and alerting | Set up once, reviewed quarterly | 4–8 hours initially, 1 hour quarterly | Outages discovered by clients, not by you |
| Access management | On joiners, leavers, role changes | 30 minutes each | Former staff retain access; audit findings |
| Secrets and key rotation | Annual, or on suspicion of exposure | 2–4 hours | Compromise window measured in years |
| Domains, TLS, email delivery | Annual checks, renewals | 2–3 hours per year | The portal stops working because a certificate lapsed |
| Incident response | Occasionally, unpredictably | Unbounded on the day | An ordinary outage becomes a client-relationship event |
| Capacity and cost review | Quarterly | 1 hour | Silent cost creep, or a limit hit at the worst moment |
| Evidence for insurers and audits | Annually | 3–6 hours | Answers improvised rather than documented |
Add these up for a year and the picture is clear: roughly 40–80 hours of routine work, plus whatever the incidents take. That is not a reason to avoid self-hosting — it is a reason to price it honestly and to check that somebody actually wants the job.
3 · A cost model with the invisible hours
The model below uses placeholder rates so you can see the shape. Replace every figure with your own: infrastructure invoice, your staff cost per hour, and your own estimate of incident frequency. There is no universal answer — only a firm’s own arithmetic.
| Line | Self-hosted (indicative) | Managed (indicative) |
|---|---|---|
| Software licence | Open source — no licence fee | Subscription per firm |
| Infrastructure | Paid by the firm directly (usage-based, usually modest at firm scale) | Included in the subscription |
| Routine operations | 40–80 hours per year × your internal rate | Included |
| Restore drills | 8–16 hours per year × internal rate | Included, with the drill record provided |
| Incident time | Unbounded; budget an allowance for it | Bounded by contract, with response targets |
| Skills required in-house | Deployment, databases, TLS, monitoring, on-call rota | Administering users and configuration only |
| Per-firm scaling | Multiplies with each office or associated practice | Adds a per-firm line to one invoice |
| Cost predictability | Good for infrastructure, poor for staff time | Subscription is predictable; usage is passed through |
Worked illustrations
Using a placeholder internal cost of 60 per hour and modest infrastructure:
- A three-person practice: 50 hours of operations plus one incident day ≈ 4,000 per year in internal time, against a similar amount for a managed subscription. At this size the decision is close, and should turn on whether anyone wants the work — not on price.
- A fifteen-person firm: operations and drills rise with releases and staff churn, and an incident costs several fee-earners a day of billable time. Self-hosting is still defensible where the firm has genuine IT capability; where it does not, the managed line is usually cheaper once the incident allowance is included.
- A multi-office group: the arithmetic inverts again only if the firm already runs infrastructure at scale. Otherwise the per-firm multiplication of operational work is the dominant cost, and there is little to be saved by in-housing it.
The number that decides it is rarely the subscription. It is the value of a fee-earner’s morning when the system is down and the fix is in someone else’s queue.
4 · Eight decision criteria
| Criterion | Points to self-hosting | Points to managed |
|---|---|---|
| Existing IT capability | You already run infrastructure, with monitoring and a rota | IT is a partner or a supplier with other priorities |
| Appetite for on-call | Someone genuinely accepts being woken | Nobody should be woken; that is what the subscription is for |
| Data residency requirements | A regulator or insurer requires a specific location you control | Requirements are satisfiable in a region the provider can evidence |
| Cost predictability | Staff time is genuinely available, not stolen from fee-earning | A predictable monthly figure matters more than the lowest one |
| Vendor-risk appetite | You want the ability to keep running regardless of the vendor | You are content with contractual exit rights and full export |
| Growth path | One deployment, stable size | More offices or associated firms arriving over time |
| Security posture | You have monitoring, patching discipline and a tested restore | You want those things operated by someone whose job it is |
| Exit rights | You hold the data and the deployment today | The contract and export rights are strong enough to leave anyway |
5 · The patterns in between
The choice is not binary. Four patterns cover almost every firm we speak to:
- Bring your own account, managed operations. The firm owns the cloud account, the data and the meter; the vendor operates updates, backups and monitoring. Control and the exit path belong to the firm; the work does not.
- Fully managed. The vendor operates everything, including the account. Simplest to run, weakest to leave — mitigate with export rights and a documented handover.
- Fully self-hosted. The firm does the work. Strongest control, real standing obligation, and the path that open-source software makes genuinely possible rather than theoretical.
- Self-hosted with purchased support. The firm operates, the vendor provides contracted support and update guidance. Often the pragmatic middle for firms with an IT supplier.
A firm can also move between patterns over time — which is itself a criterion. Ask any vendor what a move in each direction would involve, and whether either direction carries a fee.
6 · The decision tree
Asked in this order, these five questions usually settle it in ten minutes:
- Does anyone in the firm genuinely own infrastructure today? If no, go managed or bring-your-own-account-managed. Self-hosting is a new capability, not a saving.
- Do you require the data to sit in an environment you administer, for a stated reason? If yes, self-host or bring your own account. If the reason is “it feels safer”, test whether the managed structure can be demonstrated instead.
- Can you name the person who will do the quarterly restore drill? A name, not a role. If no name, choose a pattern where the drill is somebody else’s obligation with a record attached.
- What happens in the first hour of an outage? Describe it. If the answer involves a supplier’s ticket queue, price that queue into the decision.
- If you left the vendor, what would you run? If the answer is “the same software, on our own account”, the exit risk is handled — and you may not need to self-host today to be safe tomorrow.
7 · Mistakes firms make
- Comparing subscription to infrastructure only. The operations line is the larger one and never appears on a cloud invoice.
- Assuming self-hosting means no vendor dependency. It means a different dependency: on whoever holds the operational knowledge, and on licence clarity. Open source removes the licence risk; it does not remove the skills risk.
- Choosing self-hosting to save money, then doing none of the work. The most expensive option available: full exposure with none of the control.
- Choosing managed without export rights. Managed is fine; managed without a tested exit is a trap.
- Deciding once. Firms change size, capability and risk appetite. Revisit annually, in writing, with the same four questions.
8 · What OpenLPM offers on each path
Our position, stated so a firm can choose against it rather than around it.
| Path | What you get | What you take on |
|---|---|---|
| Self-hosted | The software under Apache 2.0, the deployment runbook, community channels | Everything in §2 — releases, backups, monitoring, drills, on-call |
| Self-hosted with support | The same, plus contracted support and update guidance | Day-to-day operations, with a route to expertise when needed |
| Bring your own account | Your firm’s account, meter and keys; we operate the instance | Paying the infrastructure invoice directly — which is the point |
| Managed | Updates, monitoring, scheduled backups, rehearsed restores, support with response targets | Administering your own users, roles, procedures and data |
One honest caveat, stated here as it is elsewhere: in our managed deployments the demo fleet currently shares a single cloud account boundary between firms, and per-firm accounts are a documented piece of in-progress work. Where a firm’s risk assessment turns on that boundary, the bring-your-own-account path or self-hosting is the answer today — and we will say so rather than talk around it.