Public Sector
We build digital services adjacent to public-sector work — citizen-facing portals, case-processing tools, and the integration layers that connect them with legacy government IT — designed around accessibility standards from the outset.
- Citizen-facing portals
- Case-processing tools
- Legacy government IT integration
- Accessibility (WCAG / EN 301 549)
- Direct-contracting engagements
Public-sector software development, in this context, covers digital services adjacent to government work — citizen-facing portals, case-processing tools, and the integration layers that connect them with legacy government IT — built to meet accessibility standards like WCAG and EN 301 549. North Tech Labs does not hold public-procurement framework agreements or security clearances, so this work is scoped to organisations that can contract directly, such as agencies procuring outside a restricted framework, or private and non-profit organisations building public-facing digital services adjacent to government processes.
Sector context
Public-sector-adjacent organisations — agencies, municipal bodies, and the private and non-profit organisations that build digital services alongside them — typically run on legacy case-management and records systems procured years or decades ago, with citizen-facing access layered on top unevenly if at all. Modernising the citizen-facing layer is usually an integration and interface problem sitting on top of systems that are difficult to replace outright.
Accessibility is not optional in this sector in the way it can be elsewhere — WCAG and, in the EU, EN 301 549 are established technical standards that citizen-facing digital services are expected to meet, and designing to them from the outset is materially different from retrofitting an existing interface afterward.
North Tech Labs is a remote-first European software engineering studio. We do not hold public-procurement framework agreements, do not hold government security clearances, and do not claim any Nordic legal entity or local office through which such agreements are typically issued. This means we are not positioned to bid on framework-restricted government contracts or handle classified or security-cleared work. The engagements described on this page are scoped instead to organisations that can contract directly outside those restrictions — public bodies procuring below a framework threshold or through an open-tender route that doesn't require a pre-existing framework agreement, and private or non-profit organisations building citizen-facing digital services adjacent to government processes.
Where a legacy government system needs to be reached, the practical path is usually a bounded integration — a defined API or data exchange with an existing case-management or records platform — rather than replacing that system, which is typically outside the scope an outside engineering partner without a framework agreement could take on.
Operational and digital challenges
- Legacy case-management systems are difficult to extendCore government case-management and records platforms are often old, vendor-locked, or poorly documented, making even a bounded integration a significant undertaking.
- Citizen-facing access lags behind internal systemsA case or application status may be tracked digitally internally while citizens still have to call or visit in person to check on it.
- Accessibility requirements are treated as an afterthoughtWCAG and EN 301 549 compliance is frequently addressed late in a project rather than built into the interface design and component choices from the start.
- Multiple departments hold pieces of the same citizen recordA single citizen interaction can span several departmental systems that were never designed to share data, forcing manual reconciliation.
- Procurement paths restrict who can be engagedFramework agreements and security-clearance requirements on much government work mean an engineering partner's realistic scope depends heavily on the specific procurement route involved.
- Digital services need to serve citizens with no digital assumptionsPublic-facing tools have to work for citizens without reliable internet access, current devices, or comfort with digital interfaces, not just an average web user.
Software capabilities
- Application and case-status portals
- Self-service forms and submission workflows
- Appointment and service-request booking
- Multi-language, accessibility-first interfaces
- Internal case-management and workflow tools
- Document handling and submission review workflows
- Status tracking and inter-department handoff tools
- Reporting dashboards for caseload and processing time
- Bounded API integration with existing legacy government systems
- Data-exchange layers between departmental systems
- Consolidated reporting across previously siloed records
- Accessibility-compliant front-end component libraries
Representative systems
The examples below describe common system types and potential engineering applications. They do not represent undisclosed client projects.
- Citizen application-status portalA portal where citizens can submit an application and track its status online instead of calling or visiting in person.
- Case-processing workflow toolAn internal tool for caseworkers to manage, route, and track cases through a defined process with shared visibility.
- Legacy system integration layerA bounded API layer connecting a citizen-facing portal or internal tool with an existing legacy case-management system.
- Accessible self-service form platformA form and submission platform built to WCAG and EN 301 549 accessibility standards from the outset.
- Inter-department data-exchange serviceA service reconciling citizen or case data held separately by two or more departmental systems.
- Appointment and service-request booking systemA system letting citizens book appointments or submit service requests without a phone call.
- Caseload reporting dashboardA dashboard giving managers visibility into caseload, processing time, and backlog across a case-processing tool.
Relevant services
- Custom Software DevelopmentDesign and development of secure, scalable custom software for companies across Sweden and the Nordic region.
- API Development & Systems IntegrationAPI design, partner integrations, and systems-integration engineering connecting ERP, MES, WMS, and third-party platforms into a reliable data flow.
- Legacy System ModernizationAudit-led legacy system modernization with incremental, strangler-fig migration and phased cutover for companies across Sweden and the Nordic region.
- UX/UI DesignStandalone UX/UI design engagements — audits, redesigns, and validated prototypes — with a handoff your own engineering team can build from.
Delivery considerations
- No procurement framework agreements or security clearancesNorth Tech Labs does not hold public-procurement framework agreements or government security clearances, and does not claim a Nordic legal entity through which these are typically issued. Engagements are scoped to direct-contracting routes and to public-sector-adjacent work that doesn't require either.
- Bounded scope around legacy integrationIntegration with existing legacy government systems is scoped narrowly — a defined API or data exchange — rather than assuming access to replace or restructure the underlying system.
- Accessibility designed in from the startWCAG and EN 301 549 requirements are treated as input to interface and component design from the outset, not a compliance pass applied after the fact.
- Realistic citizen-facing usabilityInterfaces are designed for citizens with varying device access, connectivity, and digital familiarity, not assumed to be a typical office or consumer web user.
Architecture, data & integration considerations
- Accessibility as a technical requirementFront-end architecture and component choices are built around WCAG and EN 301 549 conformance as real, testable technical standards, not a general usability goal.
- Legacy integration boundariesA clear, narrow interface to legacy government systems — typically a defined API or data-exchange contract — that limits how much of an old system's internal complexity leaks into new services.
- Data reconciliation across departmentsA data model that reconciles citizen or case information held separately by systems that were never designed to share a common structure.
- Integration resilienceInterfaces to legacy government systems designed to tolerate those systems' own downtime, rate limits, and inconsistent data quality.
Security, privacy & compliance considerations
- Not a holder of procurement frameworks or security clearancesNorth Tech Labs does not hold public-procurement framework agreements or government security clearances. Organisations that require a framework-agreement holder or security-cleared team for classified or restricted work should engage a supplier qualified for that specific procurement route.
- GDPR-aware handling of citizen dataSystems handling citizen data are designed around GDPR data-protection principles — access scoping, data minimisation, and deliberate handling of personal data — as a design practice. This describes how systems are architected, not a claim of certified compliance with GDPR or any other specific regulatory framework.
- Role-based access to case and citizen dataCase-processing tools and portals scope access by role rather than granting broad default visibility into citizen records.
- Data handling boundaries with legacy systemsIntegration layers are designed to pass only the data required for the citizen-facing or case-processing function involved, rather than duplicating full legacy records into systems that don't need them.
Where this fits
- Node.js
- AWS
- PostgreSQL
- WCAG
- EN 301 549
Frequently asked questions
Do you hold public-procurement framework agreements or security clearances?
No. North Tech Labs does not hold public-procurement framework agreements or government security clearances, and we don't claim a Nordic legal entity through which these are typically issued. Work described on this page is scoped to direct-contracting engagements and to public-sector-adjacent digital services that don't require a framework agreement or clearance — organisations that need a framework-agreement holder or cleared team for classified or restricted government work should engage a supplier qualified for that specific procurement route.
What is public-sector software development, in this context?
It's the design and engineering of citizen-facing portals, case-processing tools, and the integration layers that connect them with legacy government IT — public-sector-adjacent digital services, not direct government contracting or restricted procurement work.
Can this integrate with our existing legacy case-management system?
Often, through a bounded API or data-exchange layer scoped to a defined set of data rather than access to restructure the underlying system. The specific approach depends on what the legacy system exposes and what data actually needs to move.
Do you build systems that meet WCAG or EN 301 549 accessibility standards?
Yes — accessibility is treated as a technical requirement built into interface and component design from the outset, not a compliance pass applied after a system is otherwise complete.
Who is this work actually a fit for?
Public bodies procuring outside a restricted framework agreement, and private or non-profit organisations building citizen-facing digital services adjacent to government processes — not framework-restricted or security-cleared government contracts, which require a supplier holding those specific credentials.
Working in Public Sector?
Tell us whether a procurement framework or security clearance is required for your project — if it isn't, tell us which legacy system or citizen-facing gap needs solving and we'll scope from there.