Case Study - When nobody wants to fix what others broke

The Problem Everyone Knows But Nobody Talks About

You are renovating your house. You pay the crew. They start the work. Then one day, they stop answering your calls. The job is left unfinished. You look for another team, but everyone tells you the same thing: "We do not take over other people's work. Too many problems."

That is exactly what happened to Raluca with her Tirminator app.

She paid a development team to build her application. They worked for months. Sent updates. Said it was almost done. Then declared it complete. Collected the payment.

Except the app did not work.

Raluca is not a programmer. She had no way of knowing that what she was being shown in demos did not reflect reality. That entire features were missing. That the database was not properly connected. That deployment was a mess.

Alone in an Impossible Situation

When she realized something was wrong, Raluca contacted other development companies. The response was almost universal:

"We do not take over projects started by others."

"Too much risk. We would have to start from scratch."

"Other people's code is unpredictable. Not worth the headache."

Software companies have valid reasons to avoid such projects. Someone else's code can be a labyrinth. No documentation. Strange technical decisions. Hidden technical debt that explodes with the first update.

But for Raluca, this meant a nightmare: she paid for an app, does not have it, and nobody wants to help.

Why We Took On the Challenge

At Stirex, we know that behind every project is a person who poured their heart and money into that idea. Refusing to help someone in crisis is not who we are.

We agreed to do a complete technical audit. If the project was salvageable, we would save it. If not, at least Raluca would know exactly where things stood.

What We Discovered

The audit confirmed what Raluca suspected but could not prove.

1. Features declared "complete" did not exist

We found entire modules that appeared as finished in the previous team's reports but were actually just interfaces with no logic behind them. Buttons that did nothing. Forms that did not save data.

2. Hosting costs were absurd

The app was running on oversized, poorly configured infrastructure. Hundreds of euros per month for a project that barely had users. Resources that were not being used, duplicate services, production configurations on test environments.

3. Zero professional processes

No CI/CD. No staging environment. No automated tests. Every deployment was manual, risking breaking what worked. No documentation.

The Confrontation with the Original Team

One of the most difficult moments was the meeting with the original development team. Raluca asked us to be present to explain, in technical terms, what we found.

We came prepared with:

• Code screenshots demonstrating missing functionality
• Comparisons between what was promised and what was delivered
• Evidence of failed deployments
• Real costs vs. necessary costs

It was a tough conversation. But Raluca deserved to see the truth, explained in terms she could understand, not just technical jargon meant to confuse.

The Rebuild

After the audit, we got to work. The goal: transform a failed project into a functional, sustainable, and maintainable application.

Infrastructure Fixed

Beyond code issues, we also found unjustifiably high hosting costs. We completely reconfigured the infrastructure:

• Eliminated unnecessary and duplicate services
• Right-sized resources to actual needs
• Implemented auto-scaling for efficiency
• Optimized databases and storage

Monthly costs dropped significantly - but more importantly, the infrastructure now actually works.

Professional Processes from Scratch

We built what was missing:

• CI/CD Pipeline for automated, safe deployments
• Separate environments for development, staging, and production
• Test suites to prevent regressions
• Technical documentation for long-term maintenance
• Monitoring and alerting for production issues

Completing the Features

We finished the abandoned modules, properly connected the databases, and made sure every button does exactly what it should.

Results That Matter

What We Built

• Optimized Infrastructure: Cloud right-sized for maximum efficiency
• CI/CD Pipeline: GitHub Actions for automated deployments
• Automated Tests: Unit tests and integration tests
• Monitoring: Real-time alerting for issues
• Documentation: Technical guides for future teams

The Lesson for Anyone Paying for Software

If you are an entrepreneur paying someone to build your app:

1. Ask for real demos, not just presentations. If you cannot see the functionality in action with real data, it is not ready.

2. Ask about processes. A professional team has CI/CD, tests, separate environments. If they do not know what that means, run.

3. Check hosting costs. If you are paying hundreds per month for an app with no users, something is wrong.

4. If something seems too good to be true, it probably is. Get a second opinion before the final payment.

And if you find yourself in Raluca's situation—with an abandoned project and doors closed everywhere—know that teams exist that will take on the challenge.

Got a stuck project? Let's talk. A technical audit can show you exactly where things stand and whether it is worth saving.