Public Sector
Digital solutions development for the public sector.
For public clients we develop information systems, web and mobile applications, portals, interactive solutions, system integrations and digitalisation or AI projects.
The scope can include requirements analysis, technical design, development, data migration, integrations, QA, security requirements, technical and user documentation, user training, handover and maintenance under an agreed SLA.
When public bodies bring us in
- you're preparing a tender and need a supplier
- the project needs several disciplines at once
- an existing system needs extending or connecting
- a procedure needs digitalising from application to decision
- long-term support after handover is required
On a public project, technology isn't the only responsibility
- functional requirements
- technical requirements
- the project team
- deadlines
- integrations
- security
- testing
- documentation
- users and training
- acceptance
- support
What we can build for the public sector
- information systems
- citizen portals
- staff portals
- mobile applications
- registers and records
- digital forms
- case management systems
- digital kiosks
- interactive displays
- dashboards
- AI systems
- automation
- integrations
- document workflows
- multimedia solutions
What this means for the contracting authority
- Traceability for every step of the procedure.
- Documentation that matches the tender requirements.
- One accountable partner even with several vendors.
- Acceptance testing against pre-agreed criteria.
- Support and development after handover.
Problem → solution
What the system is made of
Click a part to switch it off - whatever cannot work without it goes dark. Click again to bring it back.
Projects where one discipline isn't enough
Project management
Coordinating the client, the teams and specialist partners.
Business analysis
Translating tender requirements into a buildable specification.
Development and UX/UI
Frontend, backend, mobile and user experience.
AI and data
Document processing, archive search, analytics.
DevOps and security
Environments, releases, monitoring, permissions and audit trails.
QA and documentation
Testing, acceptance, manuals and training.
Project lifecycle - from requirements to long-term operation
Requirements analysis
Review of the functional and technical requirements of the tender or order.
Project organisation
Team, responsibilities, milestones and schedule.
UX/UI
Users, processes and prototypes before development.
Development
Phased delivery with a working build at every milestone.
Integrations
Connections to existing systems and registries.
AI & data
Where relevant: document processing, search, analytics.
QA
Test scenarios, regression and defect resolution.
Security
Permissions, data handling and audit trails.
Documentation
Technical and user documentation.
Training
Training for users and administrators.
Acceptance
Verification against the client's agreed criteria.
Launch
Go-live with a rollback plan.
SLA & support
Maintenance, response times and continued development.
Project examples
Citizen portal
Applications, statuses, documents and notifications in one place.
Internal system for a public organisation
Records, users, processes and reporting.
AI over documentation
Search and analysis of large archives with cited sources.
Digital kiosk
An interactive experience at a physical location.
Mobile application
Information and services for users on the move.
Integrating existing systems
Connecting systems without a full replacement.
From tender requirements to acceptance
In a public-sector project, delivery starts with the documentation and ends with acceptance. In between is a sequence of steps that have to be documented, not merely performed: requirements, project plan, development, integrations, data migration, testing, security review, accessibility, training, user acceptance testing, handover and maintenance.
It matters that requirements can be traced to the implementation, to the test scenarios and to the acceptance criteria. When that link exists from the start, each requirement can be verified at acceptance instead of debated.
Requirements review
breaking the technical and functional requirements down into manageable workstreams
Project plan
milestones, owners, dependencies, risks and the reporting model
Design
architecture, data model, user roles and the integration plan
Development
phased delivery with a working build at the end of each phase
Integrations and migration
connections to existing systems and a validated data migration
Testing
functional, regression, integration and security testing
Training and UAT
user training and acceptance testing against scenarios
Acceptance and handover
documentation, access, knowledge transfer and agreed maintenance
Documentation as part of delivery
Documentation written after the project is usually incomplete. We produce it as the work progresses, as part of each workstream, and hand it over in a form that allows maintenance to continue - including by a different team.
- the architecture and the technical decisions
- the data model and code lists
- integrations, mappings and error handling
- environments and the release procedure
- user and administrator guides
- test scenarios and test results
- known limitations and open items
- material for user training
Accessibility
For public portals and applications, accessibility is part of the requirements, not an extra. In practice that means everything can be operated from the keyboard, field labels are tied to their fields, focus is visible, contrast is sufficient and the content is intelligible to screen readers.
Where the tender requires conformance with a particular standard or an accessibility audit, we treat it as a measurable requirement with its own test scenarios. We do not claim a conformance certificate where none has been issued for the project.
Personal data and the audit trail
In systems holding personal data, the purpose of processing, access rights, retention, export, deletion and the audit trail have to be defined at design time. We do not use real personal data in test environments. The legal assessment is the client's; our part is the technical implementation of the agreed requirements.
- user roles and least-privilege permissions
- an audit trail of access and of changes to important records
- separated environments and no personal data in test
- export and deletion on request
- backups and a restore that has been tested
The project team on a public-sector project
- a project manager as the single point of contact
- a business analyst for requirements breakdown and traceability
- a solution architect for the architecture and integration plan
- a development team for the individual workstreams
- a QA engineer, separate from the developers where required
- a security specialist to review architecture and access
- an owner for documentation and training
The core project structure can be extended with vetted specialist and partner teams where the tender demands skills or capacity beyond one workstream. Individual specialists in the wider network have experience in the public sector, critical infrastructure and regulated environments; that experience belongs to them and to the partner teams and is not an Epix reference.
How we run a public project
Requirements
Tender and technical requirements are translated into a delivery plan with milestones and responsibilities.
Project management
One contact, regular progress reporting and subcontractor coordination in one place.
Quality and security
Test scenarios, a security review and compliance with the client's requirements before acceptance.
Documentation
Technical and user documentation, instructions and training material.
Acceptance and SLA
Acceptance testing, handover and support with agreed response times.
Related work
Sub-pages
FAQ
Can you take on the entire project?
Yes. We deliver the whole scope including management, development, testing, documentation and support.
Can you work as part of a wider team?
Yes - as a consortium partner, a subcontractor for a specific lot, or as an extension of the client's team.
Do you provide project management?
Yes, with a single point of contact, a schedule, milestones and regular reporting.
How does acceptance testing work?
Against criteria agreed before development: test scenarios, a record, defect resolution and re-testing.
Do you prepare documentation?
Yes: technical documentation, user manuals and administrator guides.
Do you provide training?
Yes, for end users and administrators, on site or remote, with recordings.
Do you offer an SLA?
Yes, with agreed response times based on severity.
Can hosting stay in our infrastructure?
Yes. The solution can run in your infrastructure; we provide deployment instructions and support.
How do you handle permissions?
With roles, per-feature and per-record permissions, and an audit trail on every change.
Can you just extend our existing system?
Yes, where it makes sense: an audit, a new interface, an API layer or module-by-module modernisation.
Do you build integrations?
Yes, with existing systems, registries and external services.
Do you build AI for the public sector?
Yes, with clear boundaries: cited sources, checkpoints, logging and human approval.
Can you take part as a subcontractor?
Yes. We can take on a single workstream - development, integrations, mobile, AI, QA or documentation - within the lead contractor's structure.
How do you ensure requirements traceability?
We break the documented requirements down and link them to the implementation, the test scenarios and the acceptance criteria, so each requirement can be verified on its own.
What does the client receive at acceptance?
A working system, documentation of the architecture, integrations and environments, user and administrator guides, test results, access, and a list of known limitations.
Can the system run in our own infrastructure?
Yes. We work in the cloud, in the client's own infrastructure or in a hybrid setup; the decision follows the data and availability requirements.
How is maintenance handled after acceptance?
Through a support contract: issues are classified by severity, while the scope and response times are set according to how critical the system is and what is agreed.
Related reading
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.