Expertise · Institutions and state-owned companies
We build platforms for an institution’s relationship with the public: receiving and routing requests to the competent authority, a file with generated documents, legal deadlines tracked, moderation with a human gate, accessible public archive and retention periods applied by code. We treat interoperability with government services separately, with the actual status of each one.
Already builtDouă platforme proprii, ambele publice și verificabile azi. Prima e o platformă civică în producție, cu 65 de rute de interfață de programare, peste 50 de migrări versionate, 103 fișiere de test pe partea de server și 59 de scenarii capăt-la-capăt, cu catalogul de autorități completat manual de pe site-urile oficiale ale instituțiilor. A doua e o platformă informațională construită pentru o instituție de stat: 573 de comunicate migrate dintr-un sistem vechi, opt categorii reale în locul uneia care ținea 545 din 573, căutare fără server, generator scris în Python fără nicio dependență externă. Pentru interoperabilitatea cu serviciile de stat am ales să nu folosim „livrat”: codul de autentificare federată și de semnătură electronică e scris și testat, dar oprit — lipsesc contractul cu autoritatea și certificatul de sistem, nu codul. Îl trecem la lista a doua, nu la prima.
An institution does not buy software, it buys the ability to respond within the legal deadline. That is why the first question we ask is not what features you want, but: what is the legal deadline, when does it start running, who is responsible for each stage, and what happens on the day the deadline is approaching and no one has looked.
We built the answer to that question into a proprietary platform. A request becomes a file with the competent authority determined through four levels of specificity — sector, locality, category, then general assignment — with priority in case of equal rank. The 30-day deadline is calculated on reading, from the date of sending, so there is no indicator that lags behind; the moderation queue warns from day 25, so someone can press on before the deadline passes.
The part we treat most seriously is what is not published. The raw photo remains private evidence; only an edited version reaches public, with the regions applied and the explicit approval of a moderator — and the one who edits is not the one who approves. Retention periods are not a policy promise: they are stored in the database, each with the published text word for word and the legal basis alongside it, and the cleanup function implicitly reports what it would delete; actual deletion requires an explicit argument.
About interoperability with government services, we say exactly where we are, because this is the area with the most empty promises in the market. We have federated authentication and electronic signature written from scratch, with tests, according to the authority’s public documentation — and switched off with a toggle. What is missing is not the code: it is the contract, the system certificate issued by the infrastructure operator, and the registration of the production address. For the payments platform, the interoperability bus and the citizen cabinet, we have no line of code and we claim nothing else.
What it covers
Destination resolution is done on four levels of specificity — sector rule, locality rule, category rule, then general category assignment — with priority in case of equal rank, and the destination is chosen in order: the rule destination, then the authority’s receiving destination, then its general address. In production, the catalogue has 102 institutions, of which 95 have a completed address.
Every email address, phone number and office address was copied from the institution’s official website. Where an address could not be confirmed on an official page, the field was left blank, with the reason noted. Nothing was filled in from memory or from aggregators — because a request sent to an invented address is worse than one not sent at all.
The document is built in the application, with the fonts embedded in the repository — no request to a font service at the time of generation. Alongside it, the petition text and the information required by Article 19 of Law 195/2024 are generated as a separate module, with no dependencies, therefore verifiable piece by piece.
Anonymous information and a signed petition are not the same thing and the platform does not mix them. The signed petition identifies the citizen to the authority, and only then does the 30-day term from the Administrative Code begin to run; anonymous petitions are not examined, and the platform says so instead of leaving the opposite illusion. The anonymous path has separate consent, because a tick for transfer to the authority would have been a false statement there.
Nothing reaches public without human confirmation. The raw photo remains private evidence; only the edited derivative reaches public, with provenance preserved and explicit moderator approval, and the one who edits is not the one who approves. If the media state becomes unsafe, the file is automatically withdrawn from public.
The 30 days are calculated on reading, from the date of sending, so there is no indicator that lags behind reality. The warning in the moderation queue starts on day 25. Transmission has a log with the attempt, the saved message identifier and classification between permanent rejection and temporary error.
The checking runs in automated tests against WCAG 2.0 A and AA criteria plus 2.1 A and AA. Only critical and serious issues block delivery, but there is a baseline per page, which means that any new issue blocks delivery even if the overall level has not changed. Contrast was fixed by emitting the resolved colour so that the tool can assess it effectively, not just apparently.
For a state institution, we migrated 573 press releases from the old system, through its public interface, and rebuilt the taxonomy: eight real categories instead of a single category that held 545 of the 573. The result is static — 697 files, 14 MB, serverless search via a prefix-matching index, served compressed — with 33,497 internal links checked and zero broken ones.
Accessibility statement, information on data processing in accordance with Law 195/2024, open data section, site map. We build them together with the rest, because added at the end they end up formal and useless.
What it looks like
What the deadline is, when it starts, who is responsible at each stage, what happens if it is exceeded. We deliver: the map of stages with the responsible person for each and the calculated deadlines, plus the list of legal grounds cited per article.
Each address is copied from the institution’s official page. What cannot be confirmed remains blank, with the reason written down. We deliver: the catalogue with the source of each field and the explicit list of fields left unfilled.
Nothing leaves and nothing is published without a human action, and the person who prepares is not the person who approves. We deliver: the moderation procedure, the roles in the platform and the automatic behaviour for content that has become unsafe.
The automated accessibility check is included in delivery, with a baseline per page. The processing register is completed in parallel with the code. We deliver: the accessibility report with what was fixed and what remained, plus the register with the “where implemented” column filled in.
Publishing, rollback to the previous version and the cleaning procedure are practised at least once before handover. We deliver: the procedures, staff accounts with two-factor authentication, and the list of decisions remaining with the institution.
The data
The questions anyone with a data protection officer would ask — asked here before they do.
A case
The situation
To route a request, you need the correct address of the competent institution. Aggregated sources on the internet are full of old addresses, from reorganised or dissolved institutions. A request sent to a dead address looks exactly like one sent correctly — until nobody responds in time.
What we built
We filled in the catalogue by opening the official website of each institution and copying the e-mail address, phone number and headquarters from there. Where the address could not be confirmed on an official page, the field was left blank, with the stated reason alongside. Above the catalogue we put a resolver with four levels of specificity — sector, locality, category, general attribution — with priority on ties, and an explicit order of destination selection.
What came out
In production there are 102 institutions, of which 95 have the address filled in, and 36 routing rules. The seven without an address are visible as such, so it is known where the platform cannot send — instead of sending somewhere wrong and seeming to have worked.
What the case does not say
A manually filled catalogue ages. Institutions are reorganised, addresses change, and a field filled in correctly last year may be wrong this year. Periodic re-checking is an operational duty of the institution or of ours, by contract — technology does not solve it.
Questions
No, none is active in production, and we distinguish them individually. For federated authentication we have written from scratch a service provider, with the specific defences implemented and with automated tests; it is switched off from a toggle, and the default test checks precisely that the off state does not leak anything. For electronic signature we have a complete client, with mutual-certificate transport; our internal document says, verbatim, “off, but complete”. For the payments platform, the interoperability backbone and the citizen cabinet we have no line of code and we propose nothing else.
Four things, all outside the code, and we list them so they can be planned: the production address of the service, which is not public; the technical interface description, which requires credentials; the system certificate issued by the state infrastructure operator; and the registration of our production address with the e-government authority, plus the related contract and annual fee. In a real project, these steps are a stage with its own duration, not a box ticked at launch.
The self-service option, which works today: the citizen signs the document on the state’s official portal and uploads it back into the platform. It is not as convenient as signing in flow, and we say so, but it is a real way, without contract and without certificate — and when the integration is activated, the case file format does not change.
No, up to 6 September 2026. The pipeline is built, tested and deliberately passed through a human gate — a case enters the 'sent' state only after the envelope has actually left, the transport has retries, increasing pauses, a log per attempt, the message identifier saved and a distinction between permanent rejection and temporary error. But in production there were 14 prepared cases and zero sends. There is no automatic process that triggers the first send: it is a human decision, not the effect of a publication.
No. It is a working mock-up, publicly published and marked as such on every page, with an instruction not to index it for search engines. The real content is migrated and recategorised — 573 press releases, eight categories — but the images are still linked to the source site, none of the 2,464 has alternative text, the English version of the archive is not translated, the administration panel is not built, and the colours and marks are provisional. We list them because the difference between a convincing mock-up and a launch is exactly this list.
As a risk, not as a detail. Identification elements go into the internal file and do not appear publicly. The public position is rounded. The raw photograph remains private evidence, and only an edited derivative approved by a different person from the one who drafted it is made public. Every retention period is stored in the database with the published text and the legal basis alongside it, and real deletion requires an explicit argument — a function that deletes in silence is a failure mode, not a feature.
We designed for it, we have not operated in it. In a file for an institution, we wrote the hosting requirements on the state platform according to the applicable government decision, and the project code repository targets a machine on that infrastructure. But the system does not run there: its authentication is a replacement explicitly stated in code as temporary, and the adapters to institutions are first-phase stubs. That is the correct way to say it.
No. We have not built any of them, we do not have a team with that experience and we will not bid for them as if we did. Our field is the institution’s relationship with the public: receiving and directing requests, publishing information, tracking deadlines and protecting data in the flow. When an institution needs a state database register, it needs a different supplier.
We do not have quality management or information security certifications and we are not registered as a government supplier in any international programme. The procurement procedure, eligibility requirements and required documents are set with the institution, and if an eligibility requirement excludes us, it is better to see that at the start. We do not make up for the lack of a certificate with wording that makes it seem as if we have one.
22 of them are code and files from our repositories. We don't publish their name or line: together, on a single page, they would describe too precisely how systems that aren't only ours are built. We go through them with you, in the repository, on request — verification stays possible, it just happens in a conversation.
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.