Digital services

A scoped investigation before you invest: needs, alternatives, cost, and risk. It ends in a recommendation you can act on.

We map the needs of those who will use the service, review what you already have, and weigh the alternatives against each other. Each path is given a rough cost and a clear risk.

You receive a supporting document that can be taken to management or the board: what the problem is, what it costs to solve, and what happens if you abstain.

Not in the technology. Start with what the organization needs it for. A maturity assessment shows where AI adds value and where it just becomes noise.

The assessment looks at which workflows take time today, what data you have in order, and what the organization is capable of managing after the launch. This last point fails the most projects.

The result is usually a short list of use cases worth testing, and a longer list of things that sound good but are not sustainable. Both lists are useful.

No. The basis is yours. Build with us, with someone else, or not at all.

We write it so that anyone can calculate it: requirements, alternatives, cost ranges, and risks. No lock-ins in our tools and no formulations that only we can interpret.

Sometimes the conclusion is that you should not build anything at all. We state that just as clearly as the opposite.

Yes. Websites, apps, and digital services, from user research to production and operation.

The way of working looks the same regardless of technology. We start with the users' needs, develop and test a proposal, and then build in steps that can be released continuously rather than in a single large delivery.

We also take over services that someone else has built. We then start with a review of the code, content, and operation, so that you know what you have before we promise anything.

WCAG is part of the build from the start, not an afterthought review. For legal requirements such as EAA, LPTT, and DOS, we connect the accessibility service.

In practice, this means that contrasts, keyboard navigation, heading structure, and screen reader support are handled when the interface is designed and coded, long before it is to be delivered.

We test continuously using both tools and by hand. Automated tests catch some of the requirements; the rest require someone to sit down with a keyboard and screen reader.

More and more are doing it. The EAA and LPTT cover large parts of the private sector since 2025, and the DOS Act applies to the public sector. We clarify what applies specifically to you.

In short: The DOS Act affects public and publicly funded operations. The EAA and LPTT affect private actors who sell certain services to consumers, such as e-commerce, banking, transport, and digital books.

There are exceptions, including for the smallest companies, and transitional rules for services that were in place before the requirements came into force. We review your situation and tell you what applies before you spend money on measures.