A true story of good intentions, missing architecture, and a backend that almost took the whole system down.
The Setup
We were brought in to audit an internal logistics platform that had been under development for five years. The budget? Roughly €15,000 per month — totaling just under €900,000.
At first glance, everything seemed functional. But once we started digging into the code and infrastructure, we found a system on the edge of collapse. Not because of bad intentions — but because of years of well-meaning decisions made under pressure.
What Went Wrong
- The backend was a PHP monolith on a single server — no scalability, no failover.
- The frontend was built on Next.js, but with no structure, routing logic, or user flow. Users couldn’t find anything.
- The mobile app? Built by someone without mobile experience. No search, no filters, no UX — just chaos.
- The data sync relied on CSV files exported from Oracle 9, transferred via FTP, and re-imported daily.
- All logs were dumped into unpartitioned Oracle tables. Eventually, they grew too large to query — and rebuilding indexes meant shutting down the database. In production.
This wasn’t just technical debt. It was digital quicksand.
Why This Happens
We see this pattern often:
- MVPs that were never upgraded
- Legacy systems duct-taped together
- Internal tools that cost hundreds of thousands, but don’t actually solve problems
And always the same request:
“Can you build us an MVP in 3 months?”
Yes — but only if we agree what minimum and viable really mean.
What It Took to Fix It
Here’s what we proposed after the audit:
- Upgrade to Oracle 11 and partition the bloated tables
- Offload logs to an external system (ELK or ClickHouse)
- Rebuild the backend as a microservice architecture (Spring Boot, Docker, K8s)
- Implement real CI/CD pipelines
- Design a service API layer for all interactions
- Map out user journeys and business processes from scratch
- Secure the infra with encrypted VPNs, IAM, and zero-trust access
Not a quick fix. Not a cheap one. But a path forward that could actually scale.
We’re still working with this client today — not just rebuilding software, but helping them rethink how they operate digitally.
The Takeaway
Tech debt isn’t always the result of bad developers. It’s often the outcome of survival mode — building just enough to stay afloat.
But eventually, systems that were never designed to scale… don’t.
You don’t always have to rebuild. But if you do — do it right.
