Services

Solutions for the public sector

Systems for institutions whose requirements come not only from users but also from legislation. Accessibility, data protection and procurement documents are planned from the start.

Discuss your project Specification and design

Software development for the public sector differs from a commercial project not in technology but in procedure. The system must not only work, it must also comply with legislation, be purchased under public procurement rules and remain transferable when the maintainer changes. These three factors shape the result more than any technology choice.

What we build for institutions

We do not work on showcase websites but on systems where the actual work happens: applications are received, documents are assessed, registers are maintained and residents are served.

Application intake and assessment systems. Calls for applications, submission, expert assessment against forms, scores, decisions and contracts with signing. The entire workflow stays in a single record with an action log.
Registers and record-keeping systems. Members, properties, permits, equipment. With role-based access rights and a history that shows who changed a record and when.
E-services for residents. Submitting requests, booking appointments, orders and payments where they are needed.
Internal systems for staff. Document workflows, task allocation and reports that today are compiled by hand from several spreadsheets.
Event and activity administration. Registrations, participant lists, attendance and payments where an activity is paid.

Technically these are the same web applications, only with an additional layer of requirements that private buyers do not have.

Compliance planned in advance

Accessibility and data protection are cheapest to build in at the design stage. Adding them to a finished system costs several times more, and sometimes means rebuilding the interface.

Description of General Requirements. Websites of Lithuanian state and municipal institutions are governed by a description approved by Government Resolution No. 480. It sets out not only accessibility but also a mandatory structure: which sections must exist, what information is published and how it is kept up to date.

WCAG 2.1 AA. The accessibility requirements stem from Directive (EU) 2016/2102 of the European Parliament and of the Council (the Web Accessibility Directive) and apply as a mandatory minimum. In practice this means contrast, keyboard operation, text alternatives, associated form labels and accessible documents. We do not rely on automated tools alone, because they cannot detect some of the requirements.

Accessibility statement. An institution must publish how far its website meets the requirements and where it falls short. We prepare the technical part of this document from the audit results, not from guesswork.

Personal data. Role-based access rights, an action log, retention periods and deletion of data once the period expires. The data location is set out in the contract rather than left to the supplier's discretion.

Documents needed for procurement

The most common obstacle in institutions is not the decision to buy but the document to buy against. Without it, suppliers price different scopes and proposals cannot be compared.

The technical specification is written in terms of functional requirements and a description of the outcome, without references to specific products, brand names or patents that would favour a single supplier. It is a separate service, and it may end with someone else building the system: IT consulting and system design.

So that the maintainer can be replaced

In the public sector the maintainer changes every few years through a new procurement. A system that another supplier cannot take over becomes the institution's problem, not the developer's.

That is why the code, database, documentation and access credentials are handed over to the institution, and the system is built on an open source foundation without proprietary components that nobody else could license. The same principle applies to integrations: connections are documented so that someone else can maintain them.

How the work is done

We start with an analysis that ends with a scope and an estimate. Then come a prototype, development in stages, testing and launch with training. Each stage ends with a tangible result that can be submitted as evidence of progress if the project is funded by the EU. More about our process.

Similar projects, where the whole workflow from application to contract runs in a single system, are described in the case studies of the contract management and e-signing platform and the association membership and events system.

Off-the-shelf product for institutions vs custom system

Both routes are legitimate. The difference is where responsibility ends up.

Criterion	Off-the-shelf product	Custom system
Fit with procedure	Procedure adapts to the product	System adapts to the procedure
Accessibility responsibility	Depends on the vendor's roadmap	Written into the contract as a condition
Implementation time	Weeks	Months, depending on scope
Data location	Vendor's infrastructure	Server chosen by the institution
Integration with registers	Only those the vendor provides	Any system with an API
Changing maintainer	Depends on the vendor	Code and data are handed over
Long-term cost	Grows with the number of users	Maintenance not tied to user numbers

FAQ

Frequently asked questions

Can you prepare a technical specification for a public tender?

Yes. The specification is written in terms of functional requirements and a description of the outcome, without references to specific products or brand names that would favour a single supplier. It is a separate service, and it may well end with someone else building the system.

What does WCAG 2.1 AA mean in practice?

Text must have a contrast ratio of at least 4.5:1 against its background, the whole website must be operable by keyboard, every image needs a text alternative, form fields need associated labels and videos need captions. Then there is what is often forgotten: PDF documents published on the website must be accessible too.

What is an accessibility statement and who prepares it?

It is a public document in which the institution states how far its website meets the requirements, which parts do not and why, and how to report a problem. The institution publishes the statement itself, but we prepare its technical part based on the results of the accessibility audit.

Will the system meet the requirements of Lithuanian Government Resolution No. 480?

Yes, and this is written into the contract as an acceptance condition, not as a promise. The Description of General Requirements approved by the resolution covers not only accessibility but also a mandatory structure: which sections must exist, what information is published and how it is kept up to date.

Where is the data stored?

Wherever the institution specifies. Most often that means servers in Lithuania or elsewhere in the European Union. The system is built so that it is not tied to a single cloud provider, so the location can be changed later.

What happens when the contract ends?

We hand over the code, the database, the documentation and all access credentials. The system can be moved to another maintainer without technical obstacles because it does not rely on proprietary components of ours. This matters in the public sector in particular, where the maintainer changes every few years through a new procurement.

Can you take over a system built by another supplier?

Yes, as long as there is access to the code and the data. We start with a review that assesses its condition, security gaps and how far the system meets current requirements. After that it is clear whether it is cheaper to fix the existing system or build a new one.

Can the system be connected to state registers and other systems?

Yes, if they have an API or another method of data exchange. Integrations are described as early as the analysis stage, because they usually determine both the timeline and the cost.

How does the work run when a project is funded by the EU?

The work is split into stages with clear deliverables that can be submitted as evidence of progress. Each stage ends with something tangible: a document, a working version or a test report, so reporting requirements do not catch the project out at the end.