"Do we buy software or have it custom-built?" This question has been on municipal IT managers' desks for decades. The right answer is never the same for every City Council. This article breaks down the criteria that matter when deciding.
Let's start by clarifying the terms
Talking about "in-house software" versus "SaaS" simplifies a more complex reality. In the real world at least four models coexist:
- Bespoke development: the City Council hires a company to build software from scratch, tailored exclusively to its processes. The source code and infrastructure remain under municipal control.
- Packaged on-premise software: the City Council buys licences for a standard commercial product and installs it on its own servers. It customises it within the limits the supplier allows.
- Dedicated SaaS: the supplier runs the software as a cloud service, but the City Council has its own instance, isolated from the rest.
- Multi-tenant SaaS: many City Councils share the same technical instance, logically separated. It is the most efficient model but also the one requiring most trust in the supplier.
The question is not just "in-house or SaaS?", but which point on the spectrum suits your administration.
The economic criteria
Total cost of ownership over 5 years
The most common mistake when comparing is to look only at the upfront cost. You need to look at the full TCO:
| Item | Bespoke software | Multi-tenant SaaS |
|---|---|---|
| Upfront investment | Very high (typically €80-300k) | Minimal (deployment + training) |
| Recurring fee | Support and maintenance only | Ongoing annual fee |
| Infrastructure | Borne by the City Council | Included in the SaaS |
| Updates | A separate project each time | Continuous, at no extra cost |
| Regulatory compliance | Municipal responsibility | Shared responsibility |
Over 5 years, in small and medium-sized municipalities, SaaS is usually clearly cheaper. In large municipalities with very specific needs, bespoke development can start to break even by around the fifth year.
Capex vs Opex
Beyond the total cost, the timing of the spending matters. Bespoke software is Capex (a large upfront investment); SaaS is Opex (ongoing operating expenditure). For administrations with budget peaks, Capex may be easier to get approved. For administrations with stable budgets, Opex is more manageable.
The technical criteria
In-house technical capacity
Bespoke software needs a technical team capable of maintaining it. If the City Council does not have, and will not have, an IT department with real capacity (not just managing users but understanding architecture, managing servers, interpreting logs), bespoke development is a trap: you'll buy a Formula 1 car and nobody will know how to drive it.
As a very rough guide: below 30,000 inhabitants there is rarely enough in-house technical capacity. Above 80,000, there almost always is.
How specific your processes are
Does your City Council do things the same way as similar administrations, or does it have very specific processes? If your cases are 95% standard and 5% special, standard SaaS covers you. If you have unusual processes for historical, geographical or political reasons, you may need deep customisation capabilities that only bespoke development offers.
Speed of deployment
Typical timescales:
- Multi-tenant SaaS: 2-8 weeks from signing to go-live.
- Dedicated SaaS: 6-12 weeks.
- Packaged on-premise software: 3-6 months.
- Bespoke development: 9-18 months for a first usable version.
If the urgency is real (a regulatory change forces your hand, an old system is breaking down, an event is coming up), the deadline decides the maths.
The operational criteria
Who takes on regulatory compliance
The GDPR, the ENS, the AI Act and the rest of the regulatory ecosystem are a growing burden. With SaaS, the supplier takes on most of the technical and organisational measures (encryption, backups, access control, certifications). With bespoke development, compliance is the City Council's responsibility, which means audits, certifications and continuous updating, all with recurring costs.
Risk of obsolescence
Bespoke software carries a silent but real risk: technological obsolescence. What was built in 2018 with the fashionable technology of the day may, by 2026, be running on an unsupported version with no team able to update it. We have seen more than one case of "in-house" municipal software ending up as a black box nobody wants to touch.
Well-managed SaaS evolves continuously without the City Council noticing: the supplier migrates from obsolete technologies to new versions transparently.
Dependence on the supplier
The classic argument against SaaS: "you become dependent on the supplier". It is a real risk, but it can be mitigated with data portability clauses in the contract and by checking that the supplier exports data in standard, open formats.
The mirror-image argument against bespoke development is just as real: "you become dependent on the only people who know the code". If the company that developed it disappears or changes staff, the City Council is trapped all the same.
A simplified decision matrix
| City Council profile | Recommendation |
|---|---|
| < 20,000 inhabitants, no technical team | Multi-tenant SaaS |
| 20,000-80,000 inhabitants, basic technical team | Multi-tenant or dedicated SaaS |
| 80,000-200,000 inhabitants, mid-sized technical team | Dedicated SaaS or packaged software |
| > 200,000 inhabitants, mature technical team | Mix: SaaS for standard processes, bespoke for specific ones |
| Provincial Council with many small municipalities | Shared multi-tenant SaaS |
| Very unusual processes not replicated in other public administrations | Consider bespoke development |
The Labrax model
At Labrax we operate mainly as multi-tenant SaaS for our own products, with two options for clients who need more isolation:
- Shared multi-tenant (the most efficient): your City Council shares an instance with others, but the data are cryptographically isolated.
- Dedicated tenant: an exclusive instance on shared infrastructure. More expensive, more isolated.
- On-premise: for exceptional cases with requirements for absolute data sovereignty. Only when genuinely necessary, because cost and operational complexity rise considerably.
Our honest advice: if you are torn between bespoke development and SaaS, start with SaaS. If within a year you find real limitations, you can always evolve. If you start with bespoke development and find it was overkill, you have already spent a lot of money.
