Governments and tax-funded organisations spend billions on information technology every year. Much of it is wasted. Not through corruption. Through habit.
The same procurement patterns. The same vendor relationships. The same absence of technical scrutiny that turned “digital transformation” into a polite euphemism for writing large cheques to large consultancies.
Frugal IT is not austerity. It is the disciplined application of constraints. Spending less by understanding more. Accessing industry expertise without routing every decision through a firm that bills by the hour.
01. Problems
The analysis
The consultancy dependency cycle
Most public sector IT strategy is written by the same five consultancies that also implement it.
The incentive structure is obvious. The more complex the recommendation, the longer the engagement. A firm paid to diagnose will always find a disease that requires treatment. Preferably ongoing. Preferably expensive. This is not bad faith. It is structural misalignment between the advisor’s revenue model and the taxpayer’s interest.
Absence of internal expertise
Decades of outsourcing have hollowed out technical capability within government.
When a ministry cannot evaluate a vendor’s architecture proposal, it cannot negotiate. When it cannot negotiate, it overpays. When it overpays, it cuts elsewhere. Often from the very training budgets that would rebuild internal competence. The cycle is self-reinforcing and nobody is in charge of stopping it.
Procurement as theatre
Public procurement frameworks were designed for buying bridges. Not software.
Multi-year RFP cycles. Compliance-heavy evaluation criteria. A bias toward “nobody gets fired for buying IBM” that produces outcomes favouring incumbents over innovators, size over suitability, and process over results. A startup with a better solution at a tenth the cost often cannot even submit a bid. The paperwork is the barrier, and the paperwork was written by people who benefit from the barrier existing.
Bigger is not better
Government IT has a gravitational pull toward the monolithic.
A problem that could be solved in twelve weeks with a small team and a focused scope gets packaged into a multi-year, multi-million-euro “transformation programme”. The bigger the project, the higher the compliance bar. Turnover thresholds. Insurance requirements. Reference lists. The smaller the pool of eligible bidders.
In practice, this means the same four or five consultancies win the same contracts, year after year. Not because they are best. Because they are big enough to qualify.
The irony is that large projects fail more often. Research consistently shows that IT projects over a certain size have dramatically higher failure rates. Smaller, iterative deliveries succeed more often. The procurement system is not built for them. It rewards ambition on paper over delivery in practice.
The hidden cost of “enterprise” software
Licence fees are the tip of the iceberg.
The real cost of enterprise software in government is lock-in. Proprietary data formats that prevent migration. Customisation layers that only the original vendor can maintain. Integration dependencies that turn every adjacent system into a hostage. By the time an organisation realises the total cost of ownership, switching is more expensive than staying. Which is the whole point, from the vendor’s perspective.
The most expensive IT decision a government makes is not the one it signs. It is the one it cannot walk away from.
What policy-makers must do
Impose budget ceilings as a design constraint. Frugality is not a limitation. It is a forcing function for better engineering. When a project has half the budget, it cannot afford unnecessary complexity. Mandate that IT projects demonstrate what they would cut, not just what they would build.
Separate advisory from implementation. The firm that designs the architecture should not be the firm that builds it. This single rule eliminates the most corrosive incentive in public sector IT. Where legislation does not yet require it, procurement guidelines should.
Default to open source. Every procurement should begin with the question: does an open-source solution exist? If it does, the proprietary alternative must justify its cost against a baseline of zero licence fees. This is not ideology. It is due diligence with public money.
Break big projects into small contracts. Cap individual IT contracts at a size that small and mid-sized companies can deliver. Six months. Clearly scoped. With defined outcomes. Chain them iteratively, the next contract awarded based on the results of the last. This opens the door to smaller actors, reduces risk per engagement, and creates natural checkpoints where a failing project can be stopped before it consumes its entire budget.
Lower the entry barriers for small vendors. Reduce turnover thresholds, simplify insurance requirements, and accept relevant project experience over corporate scale. A three-person team that has delivered five successful government projects is a better bet than a consultancy with ten thousand employees and a mixed track record. Current procurement rules cannot see the difference.
Rebuild internal technical teams. Hire engineers into government at competitive salaries. Not as advisors. As decision-makers. A single senior architect on staff can save more than their salary in avoided vendor lock-in within the first year.
Cut the paperwork. A procurement process that takes nine months and two hundred pages of documentation to buy a €50,000 service is not rigorous. It is wasteful. Bureaucracy does not prevent bad decisions. It prevents fast ones. Streamline approval chains, reduce redundant compliance layers, and trust empowered teams to make proportionate decisions. The goal is accountability, not ceremony.
Speaking partners
Open Source Programme Offices (OSPOs) in governments that have them, including France, Germany, and Italy. The Free Software Foundation Europe. The Code for All network. GovTech agencies (UK GDS, Singapore GovTech, Estonia’s e-Governance Academy). And, critically, the CTOs and engineering leads of small-to-mid-sized companies who have delivered government projects without an army of consultants.
What individuals & companies can do
If you work in government: document what you actually need. Before the RFP. Before the vendor calls. Write down, in plain language, what the system must do. Not what features would be nice. What it must do. This document is worth more than any consultancy’s discovery phase, and it takes an afternoon.
If you run a small tech company: make yourself visible. Register on government procurement platforms. Attend pre-tender briefings. Publish case studies in language procurement officers understand. Outcomes, timelines, cost. Not technical jargon. The barrier to government work is often not capability. It is discoverability.
If you are an independent expert: offer micro-engagements. Governments do not always need a six-month strategy review. Sometimes they need a two-day architecture audit, a four-hour procurement review, or a single afternoon with someone who has built what they are trying to buy. Make these formats available. Price them accessibly.
02. Solutions
The analysis
The expertise marketplace
The knowledge governments need already exists. It lives in the heads of practitioners who build production systems every day.
The problem is access. Big consultancies act as intermediaries, packaging practitioner knowledge at a markup and wrapping it in slide decks. The solution is to disintermediate. Connect public sector decision-makers directly with working engineers, architects, and technical leads. Pay them for their time, not for the slide deck.
Constraints as architecture
The best systems are not the ones with the most resources. They are the ones designed within the tightest constraints.
A government IT team with a small budget and a clear mandate will, on average, build something more maintainable than a well-funded team with a vague one. The constraint forces choices. Choices produce clarity. Clarity produces systems that actually work.
Modular procurement
Instead of one contract for an entire platform, break the work into modules. Authentication. Data layer. User interface. Integration. Hosting. Each module can be competed separately, built by different vendors, and replaced independently. This is how the private sector builds resilient systems. There is no reason government cannot do the same.
Smaller modules mean smaller contracts. Smaller contracts mean smaller companies can compete. And when five different vendors each build one component, no single vendor holds the keys to the whole system. The result is not just cost savings. It is architectural antifragility. If one vendor fails, you replace one module. Under the monolithic model, you replace everything.
The fellowship model
Bring industry practitioners into government on short rotations. Three to six months. Not as consultants billing through a firm, but as embedded fellows with direct access to teams, codebases, and decision-making. They bring current practice. They leave behind capability. The cost is a fraction of a traditional engagement, and the knowledge transfer is dramatically higher.
Prototype before you procure
The most expensive line in any requirements document is the one nobody tested.
Government IT projects routinely spend months writing specifications, then years building to them, only to discover that the assumptions were wrong. The alternative is cheap and fast. Build a rough prototype in weeks. Put it in front of real users. Learn what actually works before committing budget. A €10,000 prototype that kills a bad idea saves €10 million in failed implementation. This is not agile methodology as buzzword. It is risk management through rapid learning.
Institutional memory
Government has a chronic amnesia problem.
Projects fail, lessons get written into reports that nobody reads, and the next team makes the same mistakes with the same vendors five years later. The knowledge exists. Buried in post-mortem documents, archived Slack channels, and the heads of people who have since moved on. Organisations that systematically capture, index, and revisit their own failures build compounding institutional intelligence. Those that don’t are condemned to pay for the same education twice.
Frugal is not the same as cheap. Frugal means the right thing, sized right, priced right, delivered on time by people who understand it. Cheap means whatever the lowest bidder said they would deliver. One is sustainable. The other is a liability with a deferred invoice.
What policy-makers must do
Create direct procurement channels for SMEs and independents. Simplified frameworks, lower insurance thresholds, faster payment terms. If a qualified individual can deliver the work, the procurement system should not require them to incorporate a limited company with five years of accounts to be eligible.
Fund technology fellowships. Allocate budget for practitioners from industry to spend time inside government departments. Model it on the US Digital Service, the UK’s Government Digital Service, or France’s Entrepreneurs d’Intérêt Général. Extend it beyond the usual suspects.
Publish spend data. Every IT contract, every vendor, every renewal, published openly. Transparency does not just prevent waste. It enables comparison. When one municipality pays three times what another pays for the same software, the conversation changes very quickly.
Mandate interoperability standards. No system purchased with public money should store data in a proprietary format. No integration should depend on a single vendor’s API without a documented exit path. These are not technical details. They are fiscal protections.
Require a prototype phase before full procurement. No IT project above a threshold value should proceed to full tender without a time-boxed prototype. Four to eight weeks. Minimal budget. Validates the core assumptions with real users. If the prototype fails, the project stops. This single rule would prevent more waste than any audit office.
Build a failure library. Establish a central, searchable repository of past IT project outcomes. What worked, what didn’t, and why. Make it mandatory reading before any new project of similar scope is approved. Require project teams to demonstrate they have reviewed relevant precedents. Learning from your own mistakes is free. Repeating them is not.
Speaking partners
Digital service agencies with proven track records (18F in the US, GDS in the UK). The Open Contracting Partnership. Transparency International’s public procurement programme. Local tech communities and meetup organisers. Freelancer cooperatives. And the growing network of public-interest technologists.
What individuals & companies can do
Mentor a civil servant. If you have production engineering experience, volunteer an hour a month to someone in government IT. Not to sell. To teach. The compound effect of practical knowledge entering the public sector is enormous.
Build government-ready open-source tools. Most open-source projects are built for developers. Government needs tools built for operators. Clear documentation. Deployment guides. Security hardening. And, above all, a path to support without vendor lock-in. If your project serves this audience, say so explicitly.
Form consortia. Small companies competing individually against large consultancies will lose on credentials every time. Small companies bidding together, with clear role separation, shared delivery frameworks, and combined track records, can win on quality and cost simultaneously.
03. Opportunities
The analysis
The public sector as innovation lab
Government is the largest buyer of technology in most economies.
When it buys well, it creates markets. A municipality that adopts an open-source document management system does not just save money. It validates the product for every other municipality. Public procurement, done right, is the most powerful accelerator the technology ecosystem has. It is also the one governments use least well.
AI as the great equaliser
The current generation of AI tools can collapse the capability gap between a well-staffed IT department and an understaffed one.
A single engineer with access to coding assistants, automated testing, and AI-driven documentation can maintain systems that previously required a team. This is not about replacing people. It is about amplifying the ones you have. The civil servant who was managing twelve systems with a spreadsheet and a prayer can now manage them with confidence.
Citizen-facing services as competitive advantage
Governments that deliver excellent digital services attract businesses, talent, and investment.
Estonia’s e-residency programme. India’s UPI payment system. Singapore’s SingPass. These did not just improve public services. They became national brands. Frugal IT is not a cost-cutting exercise. It is an investment in the quality of civic infrastructure that compounds over decades.
The sovereignty dividend
Every system built on open standards, hosted on domestic or European infrastructure, and maintained by local talent is a system that cannot be switched off by a foreign policy decision, a corporate acquisition, or a pricing change.
In an era of increasing geopolitical volatility, this is not a nice-to-have. It is a strategic imperative. And it gets harder to retrofit every year you don’t start.
The public sector is not a bad customer. It is an unprepared one. Give it the ability to buy small, test fast, and walk away from bad bets, and it becomes the best customer technology has.
What policy-makers must do
Measure outcomes, not inputs. Stop reporting IT success as “projects delivered on time and budget”. Start reporting it as “citizens served, processing time reduced, cost per transaction”. The metric change alone will transform what gets built.
Create shared services across agencies. Authentication. Payments. Notifications. Document storage. These are commodities. Every agency building its own version is waste. Shared platforms, maintained centrally and consumed as services, free individual departments to focus on their domain-specific problems.
Invest in maintainability, not novelty. The most valuable IT investment a government can make is not a new system. It is making an existing system easier to change. Refactoring, documentation, automated testing, and dependency upgrades are unsexy. They are also the difference between a system that lasts five years and one that lasts twenty.
Plan for exit. Every contract should include a documented exit path before it is signed, not after the relationship sours. Require open data formats, published APIs, full documentation, and a knowledge transfer phase as standard deliverables. A system you cannot walk away from is not an asset. It is a liability. The time to negotiate your independence is when the vendor still wants your business.
Speaking partners
National audit offices and their IT divisions. Parliamentary committees on digital affairs. Municipal CIO networks. The OECD Observatory of Public Sector Innovation. Academic programmes in public administration and digital governance. And, most importantly, the end users: citizens, caseworkers, teachers, and healthcare workers who use these systems every day.
What individuals & companies can do
Show your work. If you have delivered a government project cheaply and well, write about it. Present at conferences. Publish the architecture, the timeline, the cost. The public sector learns by example more than by argument. Every documented success makes the next frugal project easier to approve.
Participate in public consultation. When governments propose new IT strategies, procurement frameworks, or digital legislation, respond. The consultation process is often dominated by large vendors with dedicated policy teams. Independent voices, especially those with delivery experience, are underrepresented and urgently needed.
Conclusion
Frugal IT is not about spending less. It is about understanding more.
Understanding what you need before you buy. Understanding the market well enough to buy from the right people. Understanding your own systems well enough to maintain them without permanent external life support.
The constraints are real. Budgets are finite. Procurement is complex. Technical talent in government is scarce. But constraints, applied deliberately, produce better outcomes than abundance applied carelessly. Every euro spent on a system that works, that can be maintained, that can be changed, and that can be replaced is a euro that compounds in public value for years.
The alternative, the consultancy-dependent, vendor-locked, procurement-theatre model that dominates today, is not just expensive. It is fragile. And fragile systems, funded by taxpayers, are a risk that no government can afford to ignore.
The goal is not to make government IT cheap. The goal is to make it intelligent. And to make sure the intelligence comes from practitioners, not slide decks.