Municipalities should use a shared platform when the required functionality is well-established, the timeline is tight, and budget constraints are real. Building from scratch makes sense only when a municipality has genuinely unique operational needs that no existing solution can meet. The sections below walk through the key questions decision-makers face when choosing between these two paths.
What are the main risks of building a municipal platform from scratch?
Building a municipal platform from scratch carries significant risks: cost overruns, long delivery timelines, talent shortages, and the challenge of maintaining a complex system after launch. Custom software municipalities develop in-house or through vendors often takes far longer than planned, and the ongoing maintenance burden can strain already limited public sector IT budgets.
Beyond cost and time, there are structural risks that are easy to underestimate:
- Scope creep: Without a proven product baseline, requirements tend to expand during development, pushing budgets and deadlines further out.
- Vendor dependency: If a municipality commissions custom software from a single vendor, it can become locked into that vendor for all future changes and support.
- Security and compliance gaps: Established shared platforms in the public sector typically go through rigorous compliance testing. A custom build must pass the same standards but without the accumulated experience of multiple deployment cycles.
- Knowledge loss: When key developers leave, institutional knowledge about how the system works often leaves with them, making future development riskier and more expensive.
These risks do not make custom development impossible, but they do mean that municipalities need a clear and compelling reason to take that route rather than defaulting to it.
What is a shared platform in the context of municipal IT?
A shared platform in municipal IT is a standardized digital infrastructure used by multiple municipalities simultaneously, typically developed and maintained by a central government body, a cooperative, or a specialist vendor. It provides common functionality, such as citizen portals, permit management, or social services administration, without each municipality needing to build or host its own system.
Shared platforms for municipalities can take several forms:
- Inter-municipal platforms: Built collaboratively by a group of municipalities that pool resources and governance.
- National or regional government platforms: Centrally developed and offered to local authorities as a standardized service.
- Commercial SaaS solutions for the public sector: Third-party platforms designed specifically for government workflows, offered on a subscription or licence basis.
What all of these have in common is that the core product already exists, has been tested in real public sector environments, and benefits from ongoing investment spread across many users. The shared IT infrastructure model in the public sector is built on the premise that most municipalities need broadly similar capabilities, even if the surface-level branding or configuration differs.
When does a shared platform make more sense than custom development?
A shared platform makes more sense than custom development when the required functionality is common across municipalities, the implementation timeline is short, or internal IT capacity is limited. If a municipality needs a citizen-facing portal, a licensing system, or a standard reporting dashboard, there is rarely a good reason to build it from scratch when proven solutions already exist.
Specific situations where a shared municipal digital platform is the stronger choice include:
- The municipality is small or medium-sized with a limited IT team and no dedicated development capacity.
- Regulatory requirements are uniform across the region, meaning the platform does not need to accommodate unusual local rules.
- Speed of deployment matters, such as when a new legal obligation requires a digital solution within a fixed deadline.
- Budget predictability is important, since shared platforms typically come with fixed licensing or usage costs rather than open-ended development budgets.
- Interoperability with other municipal or national systems is required, and the shared platform already has those integrations built in.
The build vs buy government software decision often tips toward buying when the municipality’s needs align closely with what the market already offers. Reinventing a wheel that already rolls well is rarely a good use of public funds.
When does building from scratch give municipalities a real advantage?
Building from scratch gives municipalities a real advantage when their operational processes are genuinely unique, when existing platforms cannot integrate with critical legacy systems, or when the municipality is large enough to justify the investment and has the internal capacity to sustain a custom product over time.
Custom software for municipalities is worth considering in these scenarios:
- Highly specific workflows: Some municipalities manage services, such as specialized infrastructure, unique land management rules, or complex multi-agency coordination, that no off-the-shelf platform handles well.
- Strategic data ownership: A municipality that wants full control over how citizen data is stored, processed, and governed may prefer a custom solution that gives it complete architectural authority.
- Long-term platform ambitions: If a large municipality intends to build a broader digital ecosystem over many years, a custom foundation can offer more flexibility than adapting a third-party platform to fit an evolving strategy.
- Integration complexity: When existing internal systems are so specialized or legacy-bound that no shared platform can connect to them without prohibitive customization, building a new system tailored to that environment may be more practical.
The key test is whether the uniqueness is real and lasting, or whether it reflects a preference for familiar ways of working that could reasonably be adapted to a shared platform with modest process change.
What factors should municipalities weigh before making the decision?
Before choosing between a shared platform and custom development, municipalities should weigh total cost of ownership, internal capacity, timeline, integration requirements, and long-term flexibility. No single factor is decisive on its own, but together they reveal which path is genuinely viable.
A practical checklist for the decision includes:
- Total cost of ownership: Compare not just the initial build or licence cost, but ongoing maintenance, upgrades, support, and the cost of future changes over a five to ten year horizon.
- Internal IT capacity: Does the municipality have developers who can build and maintain a custom system, or will it depend entirely on external contractors?
- Fit with existing processes: How much would the municipality need to adapt its workflows to use a shared platform, and is that adaptation reasonable?
- Regulatory and compliance requirements: Does the platform need to meet specific national or regional standards, and does an existing shared solution already satisfy them?
- Interoperability needs: What other systems does the platform need to connect with, and how well do available shared platforms handle those integrations?
- Governance and data control: What level of control does the municipality need over data storage, processing, and access policies?
- Scalability: Will the platform need to grow significantly in users or functionality, and which approach handles that growth more gracefully?
Running through these factors honestly, rather than defaulting to a preference for custom development or assuming a shared platform will always be cheaper, leads to a more defensible and durable decision.
How Bloom Group helps municipalities choose the right approach
Choosing between a shared platform and a custom build is not a purely technical decision. It involves governance, budget cycles, stakeholder alignment, and a realistic assessment of what your organisation can actually deliver and sustain. That is exactly where we add value.
We work with public sector organisations and enterprises to evaluate their options clearly and objectively. Here is what we bring to this kind of decision:
- Independent platform assessment: We analyze whether existing shared platforms genuinely meet your requirements or whether the gaps are significant enough to justify custom development.
- Architecture and integration expertise: Our team can assess how any platform, shared or custom, connects with your existing IT landscape, including legacy systems that are often the hidden complication in these decisions.
- Custom application development: When building from scratch is the right answer, we design and develop tailored solutions with teams that hold advanced degrees in Computer Science, AI, Mathematics, and related fields.
- Team as a Service (TaaS): For municipalities that need ongoing development capacity without building a permanent internal team, we can provide dedicated specialists who work as an extension of your organisation.
- Product management and UX/UI design: We ensure that whatever platform you choose or build, the experience for both citizens and internal staff is intuitive, accessible, and fit for purpose.
If your municipality is weighing this decision and wants a clear-eyed perspective from a team with deep technical expertise, we would be glad to talk it through. Get in touch with us and let us help you make the right call for your organisation and the people you serve.
Frequently Asked Questions
How long does it typically take to implement a shared municipal platform compared to building one from scratch?
Shared platforms can typically be deployed within weeks to a few months, depending on configuration needs and integration complexity, since the core product already exists and has been tested in live environments. Custom builds, by contrast, often take one to three years from initial scoping to go-live, and that timeline frequently extends due to scope creep or shifting requirements. If your municipality is working toward a fixed regulatory deadline or needs to replace a failing system quickly, a shared platform is almost always the faster and lower-risk path.
What is the most common mistake municipalities make when deciding between a shared platform and custom development?
The most common mistake is treating familiarity with existing workflows as a technical requirement. Many municipalities conclude they need a custom build because a shared platform does not replicate exactly how things are done today, when in reality the existing process could be adapted with modest change management effort. Before ruling out a shared platform, it is worth honestly asking whether the workflow difference reflects a genuine operational necessity or simply a preference for the status quo. Conflating the two can lead to costly custom builds that solve a process problem rather than a technology one.
How should municipalities handle the transition from a legacy system to either a shared platform or a new custom solution?
Transition planning should begin well before the technical implementation does, covering data migration, staff training, citizen communication, and a parallel-running period where both the old and new systems operate simultaneously to catch errors. Legacy data quality is frequently the biggest hidden challenge: inconsistent records or proprietary data formats can significantly extend timelines regardless of which route you choose. Engaging an independent technical partner early to assess integration and migration complexity will surface these issues before they become costly surprises mid-project.
Can a municipality start with a shared platform and switch to a custom build later if its needs grow or change?
Yes, and this is actually a sound strategy for many municipalities, particularly smaller ones that lack the budget or internal capacity for a custom build at the outset. Starting with a shared platform allows you to go live quickly, learn from real operational use, and build internal digital maturity before committing to a more complex custom investment. The important caveat is to choose a shared platform with open data standards and documented APIs from the beginning, so that migrating or extending the system later does not require starting entirely from scratch.
How do municipalities protect themselves from vendor lock-in when using a shared or commercial platform?
The most effective protections are contractual and architectural: ensure your contract specifies data portability rights, export formats, and exit provisions before signing, and confirm that the platform stores data in open or widely supported formats rather than proprietary structures. On the technical side, favour platforms that expose standard APIs so that integrations and future migrations remain feasible without the vendor’s exclusive involvement. Reviewing these terms with both legal counsel and a technical advisor before committing to any platform is strongly recommended.
What role should citizens and frontline staff play in the platform decision-making process?
Both groups should be involved early, as they are the primary users of whatever system is ultimately chosen or built. Frontline staff can identify workflow requirements and pain points that decision-makers may overlook, while citizen input, gathered through surveys, usability testing, or community panels, helps ensure the public-facing experience is accessible and genuinely useful. Skipping this consultation often results in platforms that are technically compliant but poorly adopted, which undermines the return on investment regardless of whether the solution was shared or custom-built.
Is it possible to use a shared platform for some municipal services while building custom solutions for others?
Absolutely, and this hybrid approach is increasingly common among mid-sized and larger municipalities. Standard, high-volume services such as permit applications, citizen portals, or payment processing are strong candidates for shared platforms, while genuinely specialized functions, such as complex land management workflows or multi-agency coordination tools, may justify targeted custom development. The key is to define clear integration points between the two environments from the start, so the overall IT landscape remains coherent rather than becoming a fragmented collection of disconnected systems.