Public sector.

I design and code sites for public institutions that comply with WCAG 2.1 AA. Accessibility goes in at the design stage, not as a patch at the end - and your own staff manage the content, with no external invoice for every announcement.

Diagnosis

An institution's website that breaks the law and puts residents off.

The three problems that cost a public institution the most - and none of them can simply be waited out.

A law you cannot work around

Polish law obliges public institutions to provide digital accessibility compliant with WCAG 2.1 AA. A site that fails to meet it is not a matter of taste - it is a breach of the regulations and a real risk of a complaint.

A look from a decade ago

Residents judge an institution by what they see in the first few seconds. A site that looks like 2010 undermines trust before anyone reads a single announcement.

Every change through an outside firm

An employee wants to post a notice or update the opening hours - and waits days for the contractor. Where information has to be current, that is an operational problem, not a detail.

Process

How an institution's site gets built.

A clear course, firm deadlines and documentation at every step - including the documentation the procurement process needs.

Requirements analysis

We establish the scope, the procurement route and the accessibility requirements. You get a concrete offer and a schedule before you sign anything.

Design with accessibility

I design the site screen by screen, and WCAG 2.1 AA enters right here - contrast, structure, focus order. Not as a patch at the end.

Code and panel

I write the site from zero in Next.js and set up Payload CMS with permissions for individual members of staff. No off-the-shelf themes.

Audit and training

Before handover I check keyboard navigation, screen readers, contrast and content structure. Then I train the team on the panel and hand over the code.

What you get

A site that meets the law and serves the resident.

Accessibility confirmed by an audit, private-sector design quality and independence from an outside supplier.

WCAG 2.1 AA compliance

Keyboard navigation, screen readers, contrast, alternative text and a legible content structure. Every resident reaches the information they came for.

A design without the municipal template

A look matched to the character of the institution, approved screen by screen. None of the generic themes that give an official website away from a mile off.

Your staff run the content

Payload CMS lets them add a notice, a news item or a document without a developer. The change history shows who corrected what, and when.

Permissions shaped to your structure

The secretariat edits the news, HR posts the job adverts, the administrator has everything. Everyone sees exactly what belongs to them.

Comparison

A typical municipal site, or a site from me.

The same institution, two completely different experiences for the resident - and two different levels of legal risk.

A typical municipal site

A site from me

Accessibility bolted on at the end, if at all

WCAG 2.1 AA from the design stage, audited before handover

A template recognisable from a mile off

A design shaped to the institution

Every content change is a ticket and an invoice

Your staff run the content themselves

A multi-year service contract

The code handed to the institution, no lock-in

A heavy site that takes an age to load

Next.js - the page opens instantly

Pricing

A quote shaped to the procurement route.

In a public institution the scope follows the requirements and the procurement procedure, so I price it individually. You get a concrete offer with a scope and a date - ready for the procedure.

Institutional website

Design, code in Next.js, a CMS panel with permissions and a WCAG 2.1 AA audit before handover.

On request

Accessibility audit of an existing site

A check against WCAG 2.1 AA and a report listing the concrete fixes to implement.

On request

Maintenance and hosting (SLA)

Server, backups, monitoring and security updates with a guaranteed response time.

fromPLN 300

monthly

FAQ

Before you ask.

Accessibility, code ownership, deadlines and editing the content yourself.

For the public sector and institutions – yes, it's our golden rule. We write clean, semantic code, implement keyboard navigation, and test platforms using screen readers. We take full responsibility for ensuring the site passes rigorous government audits.

In 2026, responsiveness (adapting to screen sizes) is not a feature, it's the bare minimum. We go a step further – we focus on mobile performance. Our architectures load blazingly fast even on slower mobile networks (3G/LTE), drastically reducing bounce rates.

Yes, and at the highest technical level. Thanks to Next.js (Server-Side Rendering), Google bots can read the entire source code instantly. We ensure that your Core Web Vitals (Google's strict performance metrics) are in the green. This technical foundation comes as a standard.

Absolutely. We build on open-source technologies (Next.js, Payload CMS). From day one, we transfer full rights to the codebase to you. This means zero vendor lock-in – you are not tied to us and can scale your system with any other team in the future.

Yes. We implement a dedicated, modern admin panel powered by Payload CMS. It operates on a block-based system, making adding new pages, editing pricing, or publishing posts incredibly intuitive. You won't need to write a single line of code.

The timeline depends on architectural complexity. High-performance Next.js landing pages are deployed in 2-3 weeks. Complex B2B platforms, Headless stores, or WCAG implementations typically take 6 to 10 weeks. You always receive a rigid schedule before signing the contract.
Taking on new projects

A site that meets the law and makes a good impression.

Write to me and I will prepare an offer matched to your institution's requirements and the applicable procurement route. The first conversation costs nothing.