Web Application Development — A Case Study Based on My Experience with the KRS Website

Developing web applications is no easy task. In this article, I’ll share my experience with the KRS system. I’ll outline some simple recommendations that, if implemented, could help reduce the costs associated with the KRS system’s server infrastructure.

Frustration experienced while using the portal

I’m writing this post as a frustrated user of the government website – ekrs.ms.gob.pl. Perhaps this message will reach the people who developed and manage the site. As a software development company, we had the opportunity to participate in a project commissioned by the government. Unfortunately, this project wasn’t particularly well-managed.

Behind the scenes, there was utter chaos: team members were chosen more by chance than by skill, and there was a lack of dedicated system architects with solid experience. All of this meant that the application being developed had a whole host of critical bugs. Additionally, what really bothered us was the pressure to deliver functionality focused on the requirements described in the project charter. Even during development, we already knew that these features were of little importance or should have been implemented differently. Unfortunately, no one was willing to take the risk associated with a post-project settlement. Our hands were tied from a business perspective.

We have no solution to such problems because I understand the idea behind spending public funds as effectively and transparently as possible. However, creating this type of web application requires an “iterative” process—a kind of “knowledge cycle”: we build something, begin to understand it better, improve it, and create subsequent versions, all while continuously working with the user. Here, the user is an essential element. We study their experiences and problems. We check whether the system is still sufficiently intuitive, because as developers we can make things very complicated, and what comes naturally to us isn’t necessarily “user-friendly” for the average person.

Consequences of a KRS Error

It might seem like nothing—just a KRS error. Unfortunately for me, this means a significant loss of time; yesterday was the statutory deadline for submitting the documents. As a business owner, I could face penalties for missing this deadline. Due to the system failure, I now have to gather “evidence” for my defense. Yesterday, I made five attempts to upload the documents. In the process, I experienced the app’s frustrating design, where selecting a date is only possible using a “picker” control.

What Needs Improvement on the Website

Login

Let’s start with the login process. Logging in is a grueling process that causes many users to give up. That’s why it’s worth devoting more time to it. Loading spinners (those icons that indicate the page is waiting for something, like a spinning circle) are an important part of this process. When the internet is slow or the servers are overloaded, after clicking “Log In,” the user doesn’t know what’s happening. Since they’re not sure if they clicked correctly, they start clicking repeatedly. The server, which is already overloaded, gets an extra “kick” from hundreds of thousands of users. It’s not their fault—it’s the fault of poor UX.

A good way to check how your website behaves when someone has a slow internet connection is to set up a slow connection simulation in the Chrome browser:

Then, navigating through the site and seeing how it behaves under heavy load will allow us to make an initial diagnosis of the problem.

A message that has already been read won’t appear again

Every browser has what’s called “local storage.” App developers can use it to store information about what the user has already read or what settings they’ve configured on their local computer. Of course, you must inform the user that this is happening if you’re collecting data there that could be used to profile them. But if it’s just information about whether the user has read the message, we don’t even need to do that.

The message above appears every time, even though I sign my documents differently; this is not the right place to display it. The message should appear when we are close to the event it refers to. On the KRS website, we can view documents and submit new ones. This message applies exclusively to the submission of new documents and only to users who want to sign them in a specific way. After clicking on it about 30 times over the last two days, I don’t want to look at it anymore 😉

Date picker – allow the user to enter a date using the keyboard

Above, we see a form where you must specify the period for which you’re submitting the balance sheet. A user-friendly website could have a button on the side that says “Submit report for 2023.” When clicked, the date range would immediately be set for that period. I don’t know the exact numbers, but based on my experience using this site over many years, I click this dropdown menu every year

Validation done too late

When uploading a document in XML format, the necessary dates can easily be extracted from it. I submit documents for several companies, and each one takes a long time to load. Once it’s loaded, it’s possible to extract the data and enter it into the appropriate fields. Therefore, instead of displaying the message:

Error! The document creation date provided in the submission does not match the document creation date provided in the XML file

It would be enough to ask: “Do you want to set the document creation date in the file to xxxx-xx-xx? Do you want to use this date?” Let’s move on. Since I’m specifying the type of document I’m sending to the repository (Annual Financial Report) and I can’t send anything other than an XML file with a predefined structure, why am I even being asked for this date? The form validation won’t let me submit a document with a different date. In my opinion, the best approach would be the first step—specify the document type—and then display the fields that need to be filled in manually, which the system cannot recognize.

What I’m writing about here isn’t a major change, but this change could make life easier for hundreds of thousands of business owners—it’s worth implementing.

Another CRASH after saving

After correcting the date, I click “Save,” and the form is analyzed again by the backend processes, which ultimately causes it to crash:

Why It’s Worth Implementing UX Changes

A UX change—such as improving validation—is not just about making things “better” for the user. In this case, re-entering data triggers a resource-intensive process of re-analyzing the document—even though the document has already been analyzed and we’ve pointed out the errors in the form to the user.

This is also a great opportunity to deploy microservices that run in parallel when traffic exceeds normal levels. After all, all we need to do now is calculate how many business owners make this mistake when submitting documents. A small validation process multiplied by tens of thousands of users at any given time makes a significant difference in server computing power consumption.

Which is more expensive: good UX (whose implementation will shorten the time users spend on the portal) or maintaining a DevOps team that analyzes why the entire system crashed? For systems handling large numbers of users, it’s worth crunching the numbers. In my experience, good UX is cheaper than dealing with infrastructure issues after the fact.

Building web applications is difficult, but I wonder if the people commissioning the system and issuing the RFP have considered how a malfunctioning system burdens businesses. Hours wasted battling a system that generates no value—and for which business owners must pay—is simply unfair.

Application Architecture – Monolithic / Microservices

Given the problems I’m experiencing on this site, I assume that the KRS service uses a monolithic architecture. Monolithic architecture is simpler to deploy but, unfortunately, more difficult to scale. For many early-stage projects, it’s a sound first choice before they’ve proven their business value.

However, when dealing with services that can experience a very high volume of users within a short time window, a better solution in this case is to use so-called microservices. During an outage like this one, where we need to handle large amounts of data, it is essential to use load balancers. It’s also worth considering the use of queuing systems that will accept data and process it with a delay, without blocking the user. Additionally, load balancers distribute traffic across many smaller servers, ensuring smooth server operation.

These servers can be dynamically provisioned based on cloud infrastructure and the volume of incoming user requests. This allows them to handle data spikes and, once the data is processed, avoid incurring maintenance costs by being “decommissioned” by the cloud platform. Currently, every cloud provider offers such solutions.

Government systems must be secure—developing web applications for government agencies is no easy task

But since the service is a government service, perhaps the requirement is that the entire system be hosted exclusively in Poland. In practice, this scenario would mean having to set up our own server colocation center, with a team of specialists ideally replicated across several independent locations in Poland. Any other scenario exposes us to the risk of other countries gaining access to this data, etc.

But does the KRS actually hold sensitive data?

It appears that all the data we send to the KRS is data that ultimately becomes public. Therefore, relying on the server infrastructure of tech giants (AWS, Azure, GC, etc.) may be the most cost-effective solution. A solution that will allow businesses to fulfill their legal obligation without additional costs associated with “waiting and checking” whether the system is already functioning properly. Not to mention the stress associated with it.

How can the system be improved?

I’m keeping my fingers crossed for the IT team supporting the KRS; I’m sure they’ll find a solution.