Public Sector Software Projects: What to Define Before You Choose a Partner

A public institution's software has to work for everyone, protect sensitive information, and keep running long after the people who commissioned it have moved on. It usually also has to stand up to an audit.

Most of the problems that surface during delivery were created earlier, when the project was defined. Here is what is worth settling before you publish a tender or choose a partner. Your own procurement and data protection rules always come first, so treat this as a list of questions to work through with your legal and procurement teams.

Start with the service, not the system

"We need a portal" describes a solution. "Citizens should be able to submit this request and follow its progress without travelling to an office" describes an outcome, and it is much easier to test whether you have achieved it.

Write down who the service is for, what they are trying to do, and how you will know it improved. Those few sentences will settle many later arguments about features.

Be clear about data from day one

Before anyone designs a screen, answer these questions:

What personal or sensitive data will the system hold, and why is each item needed?
Which laws and internal rules apply to it?
Where must it be hosted, and who is allowed to access it?
How long must it be kept, and how is it deleted?
What gets logged, so that actions can be traced during an audit?

Answers to these questions can change the architecture and the budget, which makes them expensive to discover late.

Design for everyone who has to use it

Public services do not get to choose their users. Plan from the beginning for:

Languages. Decide which languages are required, including any that read right to left, because adding them later is harder than building them in.
Accessibility. People with visual, motor, or cognitive impairments must be able to use the service. Set a clear standard, such as WCAG, and make testing against it part of acceptance.
Devices and connections. Many people will use an older phone on a slow connection, so test under those conditions rather than on office equipment.
An alternative route. Consider what happens for people who cannot use the digital service at all.

Secure your independence

Institutions outlast contracts, so the contract should make sure you can carry on without your supplier. Clarify these points in writing:

Who owns the source code, the data, and the designs?
Will you receive administrator credentials and access to all accounts and hosting?
What documentation must be delivered, and can another team really maintain the system from it?
How can data be exported in a usable format if you change supplier?
What support, security updates, and response times apply after launch, and for how long?

Plan the integrations early

New services rarely stand alone. They need to exchange data with existing registries, payment services, and internal systems, some of them owned by other departments. Identify each one early, find out who controls it, and allow time for the approvals needed. These dependencies are a common cause of delay, and they are usually outside the supplier's control.

Deliver in stages you can verify

Long projects with a single delivery at the end leave you little ability to correct course. Stages with visible results are easier to manage and easier to account for. Ask for working software to review at regular intervals, tie milestones to outcomes you can check, and pilot with one team or region before a wider rollout. Do not forget the people side: staff need training and time to adapt, or the new system will quietly be worked around.

Questions to ask any supplier

How will you handle confidential information, and who on your team will have access to it?
How will we see progress, and how often?
What happens if requirements change during the project?
What exactly do we receive at handover?
Who is responsible once the system is live?

Clear answers to these questions will tell you more than a long list of technologies.

Talk it through early

Willowcy builds web platforms, mobile apps, and connected systems for organizations where precision, confidentiality, and long-term reliability matter. If you are defining a project, we are happy to review your requirements with you. Request a discovery call.