In this story, you learn about the reality of working with Hilma, Finland’s official service for public procurement notices that is connected to changing legislation, complex EU requirements, and the needs of users who may use the service every day or just once in a decade.
Changes in legislation can have consequences across the system
Hilma (hankintailmoitukset.fi) is the service used by Finnish contracting authorities to publish public procurement notices. It is owned by the State Treasury and operated by Hansel. The service is free to use and official, and it also acts as Finland’s gateway to European procurement systems. When a procurement is open to companies outside Finland, the relevant information needs to reach European systems through Hilma.
This makes the service important for transparency and fair competition in public procurement. At the same time, it means that the system cannot be developed in isolation. EU requirements define what information needs to be provided and how it needs to be structured, while Finnish legislation adds its own requirements and national adaptations.
We’ve been responsible for the continuous development and maintenance of this service for around two and a half years. During that time, we have worked on everything from day-to-day support and technical development to user research, accessibility, and a significant front-end renewal. We have also had to respond to significant changes in procurement legislation and move the service to a new version of the European Commission’s technical specification. One of the larger updates took around six months, as we worked through the requirements and made sure the service remained compliant.
Working directly with the customer
Our team works closely with Hansel, with a direct connection to the product owner and subject matter experts. There is a low hierarchy between the teams, and people involved in the project can bring their questions and ideas directly into the discussion.
We also have a shared Slack channel with Hansel, which keeps communication moving between meetings. If a Developer needs to clarify how a particular field or feature should behave, or there is a question about an exception in the procurement rules, we can ask directly and get the answer from people who know the domain.
That collaboration has been especially important because the system contains a lot of detailed business logic. The customer has the domain knowledge, while we bring the technical, design, and development expertise. Working closely together means we can combine those perspectives rather than trying to solve everything from one side.
Every day looks different and offers variety
Our team includes a Project Lead, Software Designers and Developers, and a UX Designer, and no two days are quite the same. Jarkko, as Project Lead, keeps an eye on the overall situation, sets priorities with the team, and works closely with the Product Owner.
The Software Designers and Developers tackle everything from support tickets and unexpected issues to larger changes. Support tickets are particularly important, which is why we have a rotating on-call Developer during office hours. This allows us to respond quickly to end users’ needs and ensures that their feedback reaches the development team directly. We also have our own technical Slack channel where we discuss problems and help each other, even though the team is spread across Tampere, Oulu, and Helsinki.
Mia is responsible for the design work, which has also changed throughout the project. At different stages, we’ve carried out user interviews and workshops, worked on accessibility and usability, prepared a component library, and explored how the service should look and feel after the front-end technology renewal. At the moment, much of the work involves creating layouts and designs in Figma and considering how the renewed service can provide a more modern and usable experience.
From hard-coded forms towards a data-driven approach
One of the most interesting technical changes has been the way we are approaching the notice types used in public procurement and the different forms related to them. The European requirements come with a technical specification that defines, among other things, the information that needs to be included and the validation rules that apply. Previously, the forms were largely built by coding their structures directly. With the front-end renewal, we have started moving towards a different approach.
Instead of manually defining every form, the idea is to have a rules-based engine generate the forms based on the underlying data and requirements. The system can use the European rules together with Finnish national requirements to determine what the form should contain.
This is particularly interesting because the requirements will continue to change. A new version of the European specification is expected next year, and further changes to procurement legislation are already on the horizon. The more of the system we can generate from the underlying rules and data, the less we need to hard-code each individual change.
It is also an example of the kind of engineering work this project involves. We aren’t just replacing one technology with another. We are looking at how the system itself should work so that it can adapt more easily to the environment around it.
Learning to tolerate mistakes
The domain is complex, and that shapes the skills we need in the team. You need to be able to understand a large system and see the bigger picture, but at the same time be comfortable working with very detailed requirements and edge cases.
Being able to accept mistakes is also important. With procurement legislation and complex forms, it isn’t always possible to get every edge case right on the first attempt. Sometimes a solution needs to be changed halfway through implementation because we discover that a particular case behaves differently than expected. That isn’t necessarily a failure. It is part of working with a complex system and a domain where there are many interdependencies.
Sometimes our job is to challenge obvious solutions and old ways of working. The system has legacy elements, and sometimes there might be a tendency to stick with established ways of doing things. That is where a fresh perspective can be useful. Good ideas can come from questioning existing solutions, whether the question is about usability, accessibility, technology, or the way a particular part of the system works.
Plenty of opportunities to grow professionally
The project has also offered plenty of opportunities to grow. Over the past two years, our Software Experts have expanded their skills across both front-end and back-end development, and the project has provided a broad view of software development. One of our Developers describes the experience as the point where calling themselves a full-stack developer stopped feeling like a stretch.
The same applies to design. Working on the project has meant learning more about the domain, taking on new types of design work, and developing a better understanding of how technical decisions and user experience connect.
For us, that is one of the good things about a project like this. You can come in without knowing everything about the domain and gradually build an understanding, while at the same time expanding your technical and professional skills.
Making a complex service work better for everyone
One of the highlights of this project has been its clear purpose. Hilma is a public service, and its purpose is to make public procurement work better for the people and organisations using it. Since taking over the service, we have been able to improve the system even with a relatively small team. The number of support requests and feedback received from the customer has decreased over the last few years, which has also freed up time for other work.
We’ve also improved the public API used by other procurement systems that integrate with Hilma, and made the documentation and handling of issues more transparent. These changes have improved the experience for people using Hilma directly, as well as for the organisations and systems that depend on it.
Being able to see this kind of impact has made the project particularly meaningful. The work is technical, and there are plenty of difficult problems to solve, but the end result is a service that many people and organisations rely on. Improving the service has a wider impact on its users and on the organisations that depend on it.
Want to take a look at our open positions? We have plenty. Subscribe also to our talent community newsletter.
