How nearly €900,000 disappeared into an app no one really used

We were invited to evaluate an internal platform built for a logistics company. It had been in development for five years, with a monthly budget of around €15,000 — which brought the total investment to just under €900,000.

At first glance, it looked like the system was functioning. But the deeper we went, the more we saw the same pattern: decisions made with good intentions, but without long-term thinking.

The backend was built on PHP and deployed on a single server. It couldn’t scale, and there was no way to run multiple instances. If that server went down, so did the entire system.

The frontend was technically based on a modern framework — Next.js — but it was built without a structure or plan. Navigation was confusing. There was no design system, no logic. Even basic things like filtering products were missing. Users couldn’t find what they needed, even if the data was there.

The mobile app was built in-house by someone without mobile development experience. It was more of a catalogue than a tool — no search, no filters, just categories with dozens or hundreds of products listed in random order. Some categories were completely empty. There was no logic behind the content or the user experience.

But the real issue was deeper — in how the system was connected to the company’s core infrastructure. They were still using Oracle 9, and each night the system would generate massive exports: product prices, orders, delivery data, account balances. These were dumped into CSV files, uploaded via FTP, then downloaded again by a PHP script and parsed into another database that powered the actual app.

If everything went smoothly, a single update would reach the users once per day. But that wasn’t guaranteed.

To make things worse, all logs were being written into giant Oracle tables — without any partitioning or optimization. Eventually, the tables became so bloated they stopped responding to queries. The only way to rebuild indexes was to shut down the entire database — for a full day. And all of this was happening in a production environment, supporting real teams and real customers.

There were no bad people in this story. No one was careless. But the system had grown into something unmanageable, the result of years of decisions made under pressure, without the time or support to step back and rethink.

We see this more often than you might expect. Legacy systems that grew over time without architecture. MVPs that were never meant to last but never got replaced. Internal tools that cost hundreds of thousands — but don’t really help the people they were built for.

And still, we hear the same question: “Can you build us an MVP in 3 months?”

Sure. But only if we agree what “minimum” and “viable” actually mean — and make space for decisions that won’t cost €900,000 later.

So what would it take to fix it?

After the audit, here’s what our senior backend engineer recommended:

Upgrade the database to Oracle 11
Rebuild tables with proper partitioning
Move all logging outside the DB
Rewrite the backend using a microservice architecture (Spring Boot + Docker + Kubernetes)
Implement CI/CD pipelines
Define a complete functional matrix
Map user journeys and business processes
Design interfaces for desktop, Android, and iOS
Build an API service layer for all interactions
Secure the infrastructure: encrypted VPN, access control, and IDM system

Not a quick fix. Not a cheap one. But a path forward — and one that would work.

We’re still working on this project today. It’s a long-term collaboration — rebuilding not just the code, but the foundation for how the company operates digitally. Out of respect for our client, we won’t name them here. But their story isn’t unique.

The truth is, a lot of businesses are in the same place: systems that feel too big to fix, but too fragile to keep.

In the end, the choice always belongs to the client. Some choose to patch. Others decide to rebuild.

We’re here for both — and we’ll always be honest about what it takes.