Reducing maintenance costs with a cleaned-up infrastructure
Our client's old diabetes platform had significant issues with its outdated, fragmented architecture, complicated maintenance, and rising costs, which also increased developers' frustration. We worked together to find a better solution that would benefit both end users and all departments involved in the project.
Adam T.
Fragmented infrastructure
Our client encountered plenty of troubles when extending or simply maintaining their 10+ years old diabetes platform.
It started as a simple website to help patients with diabetes manage their glucose levels and other therapeutic data with the assistance of their doctors. As technology advanced, more requirements emerged for supporting different kinds of connected clients, like mobile applications.
The biggest pitfall of their old infrastructure was that it did not have a single source of truth. They made a separate web API for client applications while keeping the old website as it was, sometimes relying on different data sources.
Decentralized data channels increase overall complexity and require special care across different pipelines. Every source has its own set of validation rules, often making maintaining data integrity the most challenging task.
With each update, the two systems became so inconsistent that by the end, when a requirement arose for a new API feature already supported by the website, they got an irrational offer from their maintainers both in development time and cost.
All these issues raised expenses in all departments, from product management to customer support, and it increased frustration for the in-house development team responsible for client applications, not to mention the end users who had to get used to frequently delayed updates and bug fixes.
A single source of truth
Together, we crafted a thorough plan for a centralized API with some third-party systems to serve all the needs of the existing clients. The main goal was achieving feature parity while sunsetting unused features and making the new system consistent, predictable, and open for upcoming features.
In the following months, LevooLabs laid the foundation of the renewed diabetes cloud and its delegated authorization service. We also helped the in-house development team implement the specific endpoints required for the initial release.
In addition to the backend infrastructure, we were responsible for delivering a completely new web application where we had a strong influence on the final UI / UX as well.
While we weren't directly involved in the development of every client application, we still managed to help the Windows application team cut a huge chunk of their development scope and forthcoming maintenance with a completely new strategy for their 2.0 release.
Technical relief
During the development process, the in-house development team seamlessly migrated their native clients to the new cloud, meaning we successfully achieved the goals we were aiming for. They could also use our front-end solution as a stable technical outline for the administration panel they built for the customer support team.
The new architecture increased overall security and enabled more frequent service updates. All this allowed us to help our client become the first in the country to integrate with Hungary's official Patient Health Record (EESZT PHR) system.
The new ecosystem brought significant improvements to the diabetes platform. While some doctors took longer to adjust to the UI and feature changes we made, the overall feedback from patients and medical workers was highly positive, and the user base grew substantially.
