Public sector

Digital services organisations can rely on.

Public and semi-public organisations work to different requirements. Not just for functionality and ease of use, but also for accessibility, security, maintainability, transparency and continuity.

Discuss your challenge See our work

What you build today will be run by someone who doesn't work there yet.

In the public sector, delivery is not the finish line. A system is assessed by auditors who don't know the code, handed over to colleagues who weren't there when the decisions were made, and used by people who have no alternative. That changes what a good solution is.

So we don't start with a technology, but with what needs to improve and what that is worth. Only once that question is sharp do we design and build. That saves money in the short term and trouble in the long term.

Six requirements we build in from day one.

Not because they are in the tender, but because a solution that doesn't meet them will be rejected, redone or replaced later anyway.

01AccessibilityWe build WCAG 2.1 AA into the information architecture, design and front end, not as a check at the end. We validate with keyboard use, contrast checks and screen reader tests, resolve findings before acceptance and agree who owns accessibility after go-live, including for new content.
02Information securityLeast-privilege access, separated environments, traceable logging and documented agreements on vulnerabilities and incidents. We set up hosting and processing within the EU. Our ISO 27001 certification applies to our organisation and its scope, and does not mean that every solution automatically meets every security requirement.
03Quality and process controlScope and acceptance criteria are fixed in advance, as is who reviews, who tests and who signs off. Changes go through change management and decisions are traceable. The ISO 9001 certification supports that process, but doesn't replace explaining it.
04MaintainabilityWe build on widely supported standards and frameworks you can find people for in the market. No construction only we understand, and no system that depends on one person.
05Documentation and transferabilityDocumentation, operating instructions and the reasoning behind decisions are part of delivery and acceptance. A next supplier can take over without starting again.
06Continuity after deliveryA system that is live is not finished. In advance we agree who manages what, how reports and incidents are handled, which response times apply and when we review the figures again.

What you can hold us to.

Two certifications and a number of frameworks we take into account in design and build.

ISO 27001Certified for information security.

ISO 9001Certified for quality management and process control.

Data within the EU: We set up hosting and processing within the European Union.
WCAG 2.1 AA: As the starting point for design and build, not as a check at the end.
GDPR: Data minimisation, lawful basis and retention period are design decisions, not an appendix.
NIS2 and EU AI Act: We take these frameworks into account in design decisions and document what they mean for your system.
BIO: If the BIO (Baseline Informatiebeveiliging Overheid, the Dutch government information security baseline) applies, we work out together what it requires of the set-up.

If your tender contains something we don't meet, we tell you before you spend evaluation time on it. An honest no is quicker than a bid that won't make it anyway.

First find out what needs to improve. Then build.

DiscoverThe question first, the technology secondWe map where time, money and quality are leaking away and what a solution would be worth. That leads to a reasoned choice about what should and shouldn't be built. Even when the conclusion is that buying makes more sense than building.
BuildOne team, one point of contactStrategy, design, software, data and AI sit in the same team with us. One schedule, one person responsible, no suppliers pointing at each other when something doesn't work.
ImproveGo-live is where it startsWe measure whether the goal is being met and adjust what turns out to work differently in practice. What we can't back up, we don't promise.

We choose a reference to match the criterion, not the best-known name.

In a tender we supply the reference that addresses the award criterion: comparable scope, a comparable working environment, evidence we can show and permission to share it. Below is an example from education.

Custom digital assessment software for a universityMore than 30,000 students and 2,500 lecturers, tens of thousands of exams a year. Secure test delivery, integration with the existing LMS and an environment that handles the peak around exam weeks.EducationWeb appIntegrationsView the case

More work is in our cases. References with a name, contact person and substantiated results are supplied with the tender itself, with the permission of the client concerned.

Taking part in a public tender.

Send us the tender documents or the preliminary market consultation. We answer the criterion first and only then say anything about ourselves. If we're not a fit, you'd rather hear it now than after the evaluation.

Send your tender

What we supply

A direct answer to the criterion, in the wording of the tender
The approach, with named roles and responsibilities
Evidence: relevant references, current certifications and documented control measures
The material risks, with control measures and an escalation route
A timeline and price breakdown you can explain to others

Frequently asked questions

Do you take part in public tenders?

Yes. Send us the tender documents or the preliminary market consultation, and we'll tell you up front whether we're a fit and where we differ. We answer each criterion with the approach, the evidence and the risks with control measures. If we don't meet a requirement, we say so before you spend evaluation time on it.

How is information security handled?

We are ISO 27001 certified for information security and ISO 9001 certified for quality management. Those certifications apply to our organisation and the documented scope, and do not mean that every solution automatically meets every security requirement. For each system we document who has access on a least-privilege basis, how environments are separated, what is logged and how vulnerabilities and incidents are handled. If the BIO (the Dutch government information security baseline) applies, we work out together what it requires of the set-up.

Where is our data stored?

We set up hosting and data processing within the European Union. Which data a system really needs is decided in the design, not afterwards, so data minimisation is an architectural choice.

How do you ensure accessibility?

We build in WCAG 2.1 AA from the information architecture and design onwards, so contrast, heading structure, keyboard operation, visible focus indicators and text alternatives are design decisions, not repair work. We validate with keyboard use, contrast checks and screen reader tests, resolve findings before acceptance and agree who owns accessibility after go-live, including for new content your editorial team publishes.

Can we switch to another supplier later?

Yes. We build on widely supported standards and frameworks, and documentation, operating instructions and the reasoning behind decisions are part of delivery. A next supplier can take over without starting again.

Can you also use AI within our organisation?

We can, but we don't start with the technology. First we look at where time or quality is leaking away in the process and whether AI is the right answer there. For each workflow we document what may happen automatically, what is first presented for approval and when a person is brought in.