When towns invest in digital platforms, the conversation usually focuses on features, branding or launch timelines. It rarely focuses on financial structure.
Yet the way a platform is funded and maintained has more long-term impact than the initial specification. Over time, financial design determines whether a system becomes durable infrastructure or a repeating project.
This post compares two models:
- The traditional single-town model
- A shared infrastructure model
Both are legitimate. They are simply built on different assumptions about cost, control and lifecycle.
1. The traditional single-town model
In many places, digital platforms are commissioned independently to meet specific programme needs. A regeneration team commissions one site. A BID commissions another. A growth hub launches its own portal. Each is logical in isolation.
A typical standalone platform includes:
- Discovery and design
- Development
- Hosting setup
- Plugin or software licensing
- Security configuration
- Initial training
Initial build costs vary depending on scope and supplier. That is normal. What is more consistent is what happens next.
Rebuild cycles
Standalone platforms are frequently rebuilt every three to five years. This is rarely framed as a strategic choice. It tends to be a structural consequence of:
- Contract expiry
- Supplier change
- Platform obsolescence
- Funding cycle reset
- Policy changes
Rebuilds are typically treated as new projects rather than incremental upgrades. Each cycle resets momentum, re-procures similar functionality, and restarts training and onboarding. The issue is not incompetence. It is structure. When funding is project-based and delivery is organisation-specific, rebuild becomes the default pattern.
Ongoing overhead
Every standalone platform carries recurring costs:
- Hosting
- Security updates
- Plugin or software licences
- Accessibility compliance monitoring
- Supplier retainers
- Performance optimisation
These costs exist whether a town has one platform or five. Where multiple organisations commission parallel systems, overhead multiplies. This is not inherently flawed. The traditional model is simply structured around individual organisational delivery rather than shared infrastructure. It optimises for autonomy at the point of commissioning, not efficiency across the lifecycle.
2. The shared infrastructure model
The shared infrastructure model approaches digital infrastructure differently. Instead of each town carrying the full infrastructure burden independently, foundational cost is distributed across a defined cohort. Core elements are shared at infrastructure level while local branding, governance and configuration remain local.
What is shared:
- Hosting environments
- Security architecture
- Core module development
- Licensing arrangements
- Ongoing maintenance processes
This produces structural advantages that compound over time.
Shared infrastructure cost
Core build and maintenance costs are distributed across participating towns. Per-place overhead reduces because foundational layers are not repeatedly commissioned. Hosting architecture, security hardening, and core functionality exist once and are maintained collectively.
The logic mirrors other forms of shared services. The difference is that digital is often still treated as a project rather than infrastructure.
Reduced duplication
Common functionality is developed once and reused, such as:
- Business directories
- Events platforms
- Opportunity listings
- Member or partner profiles
Under the traditional model, these components are frequently re-specified, re-designed and re-built in slightly different forms across neighbouring places – The shared model does not remove local identity. It removes unnecessary repetition.
Shared licensing
Software and plugin licences can be managed centrally where appropriate. This reduces:
- Duplicate licence fees
- Procurement cycles
- Administrative overhead
- Risk of non-compliance
Centralised management creates clarity around version control, renewal schedules and security updates. It also strengthens negotiating power with suppliers.
Centralised maintenance
Security patches, compliance updates and performance optimisation are handled within a structured infrastructure layer rather than through fragmented local arrangements. This improves:
- Resilience under staff change
- Continuity beyond funding cycles
- Consistency in accessibility and security standards
- Confidence for finance and assurance teams
Maintenance becomes systematic rather than reactive.
The objective is stability, not uniformity
The shared model is not about eliminating local expenditure. Nor is it about imposing a single template across places, it is about stabilising and reducing lifecycle cost while improving durability.
Local places still decide:
- How they present themselves
- What priorities they promote
- How governance operates
- Which modules they activate
What changes is the underlying financial logic. Instead of repeating similar costs in isolation, towns participate in an infrastructure layer that compounds capability over time.
From projects to stewardship
At its core, this is a shift in mindset. The traditional model treats digital as a sequence of projects tied to funding rounds and contracts, the shared model treats digital as infrastructure that requires stewardship.
Lifecycle and structural behaviour comparison
| Traditional single-town model | Shared infrastructure model |
|---|---|
| Resets every few years through rebuild cycles | Improves incrementally through structured iteration |
| Multiplies overhead across separate organisations | Distributes overhead across a defined cohort |
| Fragile under policy shifts or supplier change | Designed for continuity and long-term resilience |
The financial structure reflects that philosophy. Predictable, transparent, revenue-classifiable, lower in whole-life cost and structurally resilient. Not because it is cheaper at day one, but because it is designed to endure.
