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 builtDouă platforme proprii, publice și verificabile azi. Prima e site-ul oficial al unei primării de comună: Laravel 12 pe PHP 8.2 cu MySQL 8, 40 de șabloane, 32 de rute, 10 migrări, cu conținutul editorial care se schimbă rar ținut într-un singur fișier de configurare de 1.613 linii și cu cel care se schimbă des în bază, editabil din panou; autentificarea în panou e limitată la 5 cereri pe minut, iar jurnalul de audit se șterge zilnic după 12 luni, cu trimitere explicită la temeiul legal. Antetele de securitate se pot citi din exterior chiar acum. A doua e o platformă civică în producție, cu 65 de rute de interfață de programare, peste 50 de migrări, 103 fișiere de test pe partea de server și 59 de scenarii capăt-la-capăt, cu verificare de accesibilitate în teste. Ce nu trecem la „livrat”: interoperabilitatea cu serviciile de stat — codul de autentificare federată și de semnătură electronică e scris și testat, dar oprit, pentru că lipsesc contractul cu autoritatea și certificatul de sistem.
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.