Solutions · Institutions & administration
The sections required by the government decision, written in code and updated by the officer — not added at the end, as an annex.
A town hall or institution has a fixed list of mandatory sections, a transparency obligation in decision-making and a public officer who has to publish an announcement without calling a developer. We build exactly that, with an audit log that is deleted automatically on schedule and a limit on login attempts.
Already builtTwo proprietary platforms, public and verifiable today. The first is the official website of a commune town hall: Laravel 12 on PHP 8.2 with MySQL 8, 40 templates, 32 routes, 10 migrations, with editorial content that changes rarely kept in a single 1,613-line configuration file and the content that changes often stored in the database, editable from the panel; panel authentication is limited to 5 requests per minute, and the audit log is deleted daily after 12 months, with explicit reference to the legal basis. The security headers can be read from outside right now. The second is a civic platform in production, with 65 API routes, over 50 migrations, 103 server-side test files and 59 end-to-end scenarios, with accessibility checks in tests. What we do not mark as “delivered”: interoperability with state services — the federated authentication and e-signature code is written and tested, but turned off, because the contract with the authority and the system certificate are missing.
A public institution website is not judged by how it looks, but by a list. Government Decision 728/2023 sets out which sections must exist: decision-making transparency, projects and decisions, announcements, documents, contacts, budget. They are mandatory, checked and not negotiable. That is why we build them from the start, as structure, and do not add them at the end — added at the end, they become formal and useless, and that is immediately visible.
The second condition is more practical: the institution must be able to publish on its own. A tender notice, a decision draft put out for consultation, a photo from an event — if each one goes through a developer, information of public interest stays on paper or in a social network group, and the site becomes a dead display window. We intentionally separated two types of content: the editorial content that changes rarely — geography, history, institutions, contacts, budget — is kept in a single configuration file read directly by templates; the content that changes often is kept in the database and edited from the panel.
The third condition is the one nobody asks about in the specification: what happens to the data. A public administration panel needs a limit on login attempts — on the sixth request in one minute from the same address, the response is 429, and this is covered by an automated test, not assumed. The audit log contains IP addresses, so it is personal data: a scheduled task cleans it daily of anything older than twelve months, with the legal basis written in the code comment, not in a separate document that nobody opens.
And, finally, the part we prefer to talk about before the tender: interoperability with government services. Federated authentication and electronic signature are written and tested by us, but switched off by a toggle, because the contract with the authority and the system certificate are missing — the paper is missing, not the code. For the state payments platform, the interoperability bus and the citizen cabinet, we have no code at all, in any repository, and we state that as such.