Digital government as infrastructure
Imagine a government designed to operate digitally
A citizen does not need to know which office handles their request.
A business does not submit the same information to four institutions in the same year.
A civil servant does not run an important national process from a personal spreadsheet and an email inbox.
An application has a status. An approval has a name against it. A payment has a record. A decision taken in March can be explained in November.
A ministry publishes a call for proposals in the morning, receives submissions digitally, and evaluates them without a single envelope.
A region offers services suited to its own population, on the same foundation the ministry above it uses.
And when a new service is needed, nobody starts from zero.
That is not a description of software. It is a description of how a government works when it has been designed around digital infrastructure rather than around buildings.
It has been done
Estonia rebuilt its administration around shared digital infrastructure and reusable components rather than isolated systems. Singapore treats digital government as national capability, with common building blocks its agencies draw on. The United Arab Emirates set service-level ambitions for government interactions and then built the platforms to meet them.
These countries differ enormously. What they share is a decision: treat the digital foundation as infrastructure — built once, governed centrally, reused everywhere — rather than commissioning each institution’s system separately and hoping the results connect.
The question this brochure exists to ask is a simple one.
What could that look like in Cameroon?
One government is not one organisation
This is the part most government software gets wrong.
A national government contains ministries, agencies, departments, regions, councils, public institutions, programmes and offices. Tens of thousands of employees. Millions of citizens and businesses.
They do not need the same application. A ministry responsible for public health, one responsible for public works and one responsible for territorial administration have genuinely different missions, processes and obligations. A council in one region does not operate like a directorate in the capital.
So the answer is not “everyone uses the same government software”. That approach fails, and it fails expensively, because it asks institutions to abandon how they actually work.
The answer is:
One platform. Many ministries. Many regions. Many departments. Different needs.
Different institutions. Different workflows. One digital foundation.
Each institution keeps its own users, roles, permissions, processes, forms, records and reporting. What they share is the machinery underneath.
Where it actually breaks today
Not at the ambitious end. Most institutions know what they want to digitalise.
It breaks because each digital service is commissioned as a separate project. Each one procures its own platform, invents its own user accounts, designs its own approval logic, builds its own notification system, and produces its own reporting.
The result is a portfolio of applications that each solved one problem and cannot speak to one another — every new service adding another island, another login, another supplier and another set of records that duplicates the last.
Ten years of that produces enormous spend and very little compounding.
What a government process actually is
Here is the technical argument, and it is the reason a shared foundation is possible at all.
A government process is rarely just a form.
It has people with roles and permissions. It has stages and approvals, often by more than one person. It produces records that must be findable years later. It sends notifications. It frequently involves payments. And it must be auditable — who did what, when, and what it was before.
Change the subject from a building permit to a research grant to a leave request and almost all of that machinery is identical. What differs is the fields, the stages, the rules and who may do what.
That is why a foundation is possible. The common parts are genuinely common. Only the surface is institution-specific.
The foundation FeePrime provides
FeePrime is a working platform, not a framework waiting to be filled in. It already runs, as reusable machinery:
Organisations — separate institutions on one platform, each owning its own data and boundaries.
Users, roles and permissions — granular, per module and per action, so who may create and who may approve are different questions.
Approval workflows — a change can be recorded by one person and require confirmation by another, before it takes effect.
A complete audit trail — every change keeps its author, its timestamp and its previous value. Nothing is deleted; records are archived and remain readable.
Configurable records and forms — structured data with defined fields, validation, and translations across languages.
Notifications, documents and file handling, transactions and payments, employee and payroll operations, inventory and assets, bookings and appointments, public websites and portals, and APIs for connecting to systems that already exist.
Each of those is the answer to a question every digital government service asks. Built once, they stop being the expensive part of the next service.
What could be built on it
For citizens — applications and requests with a status they can follow, appointments, permits, registrations, certificates, document submission, notifications, and payments.
For businesses — registrations, licences, permits, tender and proposal submissions, reporting obligations, inspections and payments to government.
For civil servants — this half is usually forgotten. Government employees deserve digital tools for operating government as much as citizens deserve them for accessing it: employee records, leave and internal requests, departmental workflows, approvals, assignments, payroll, and internal communication.
For institutions — official announcements, press releases and public notices; a proper digital presence for each ministry, agency or council on shared infrastructure rather than as another isolated website; calls for proposals published, received, evaluated and awarded digitally, with the records to show how.
Payroll deserves its own mention, because it is one of the largest recurring operations any government runs. FeePrime can connect employee records to payroll to transactions to approvals to institutional reporting, as one chain rather than four systems reconciled by hand.
To be clear about what this list is: these are capabilities the platform can be configured or extended to support. It is a description of what can be built, not a claim that every one of them already exists as a finished government module.
Ready-made, configurable, and extensible
Government technology usually offers two bad options: a rigid product that forces institutions to work its way, or an empty framework that is really a multi-year development project with a licence attached.
FeePrime sits deliberately between them.
Ready to use. Substantial capability exists and runs today. Organisations, permissions, approvals, audit, records, payments, portals — none of that is built for you from scratch.
Configurable. A great many institution-specific processes can be assembled from what already exists: define the records, the fields, the roles, the stages and the approvals, and the process runs.
Extensible. When a requirement genuinely falls outside the platform, we develop it — on top of a foundation that already handles the surrounding ninety percent.
That third point is not an apology. It is the proposition.
You do not have to wait for a vendor’s roadmap
Every serious government programme meets requirements no generic product anticipated. The usual answer is that it will be considered for a future release.
Because FeePrime is built and maintained by the team selling it, an institution with a specific process can have it configured or developed from the existing foundation — not designed from nothing, and not deferred.
Do not build everything from zero. Do not force government into a rigid package. Build on a platform that can evolve.
Boundaries, accountability and trust
Government software needs stronger governance than a business application, and the difference is mostly about proof.
FeePrime’s foundations were built with that in mind: institutional boundaries, so each organisation’s data is its own and shared access is a decision rather than a default; roles and permissions fine enough to separate recording from approving; two-person approval where a single actor should not be able to act alone; and an audit trail that makes every change attributable and every deletion impossible — records are archived, never destroyed.
Those are architectural facts about the platform, and they are the properties a public institution needs in order to answer for a decision two years later.
We will not claim certifications the platform does not hold. Security posture, hosting arrangements, data residency and accreditation are proper subjects for a serious conversation with your technical team, and we would rather have that conversation than print a slogan.
Built in Cameroon
FeePrime is built in Cameroon, by people who work here.
That matters practically rather than sentimentally. It means the team is in your timezone, reachable, and able to sit in the room. It means the platform already handles FCFA properly, mobile money as a first-class payment method, SYSCOHADA-oriented reporting, French and English side by side, and intermittent connectivity as a normal condition rather than an exception.
It also means the roadmap can respond to a Cameroonian institution’s requirement without that requirement first becoming a global priority for a company on another continent.
Built here. Built for serious infrastructure. Capable of serving institutions beyond here.
The path is not one enormous project
Nothing about this requires digitalising a government at once. That approach has a poor record everywhere it has been tried.
Start with one institution, one service, or one process — ideally one that is painful, well understood, and bounded.
Prove it in production, with real users and real records.
Expand it across the department, then the institution.
Reuse the foundation for the next service, where the accounts, permissions, approvals and audit already exist and only the specific work remains.
Connect institutions progressively, as the platform under them is already common.
Each step delivers something usable. Each step makes the next one cheaper. That compounding is the entire argument for a foundation over a portfolio of projects.
Let us discuss a pilot
The right next step is a conversation about one concrete process in one institution — what it involves today, what it would look like digitally, and what it would take to run it in production.
We will be direct about what already exists, what needs configuring, and what needs building.
Government should not have to build its digital future one disconnected application at a time.
The next government service should be built on a platform already capable of running the processes around it.