Every few weeks someone calls us frustrated with the custom software their business runs on. An HR consultant, a food-service CEO, a mortgage-lending executive, a founder whose MVP was generated by an AI tool — different industries, same conversation. The software was supposed to be an advantage. Now it’s a liability, and they’re not sure who to trust.
The symptoms are remarkably consistent.
The four symptoms
Recurring and increasing bugs. The same issues keep coming back. Each fix seems to break something else. Your team has started keeping a list of things not to touch.
Lost opportunities. One CEO put it plainly: “If our software had been stable, we could have added the features a new, large account needed and won their business. Instead, we missed out.”
Communication problems. “I explain to my team what needs to happen, and they build the wrong behavior.” Requirements go in, something else comes out, and nobody can explain the gap.
Missed deadlines and releases. Dates slip. Then the next dates slip. Eventually there are no dates, just “soon.”
You can feel the frustration through the phone on these calls. And the hard truth is that this happens all the time. Software that employees and customers rely on every day — software that’s critical to the mission of the business — quietly rots for months, sometimes years, while everyone works around it.
What we find under the hood
We’ve done enough of these that the causes are predictable. When our senior engineers take a look at a struggling codebase and the infrastructure it runs on, the findings cluster into four groups.
The project has changed hands too many times. Each developer brought a favorite library or framework. Nobody documented anything. There’s no coding standard, because the code was copied and pasted from person to person, and the result is a codebase that’s hard to read and harder to support.
The core technology is old or was never right. It only runs in one browser, or one operating system, or one developer’s machine. It’s hard-coded to a specific environment. It has security vulnerabilities nobody has looked at because nobody wants to open that door.
Too many third-party pieces. Every problem was solved by adding a library. Debugging takes longer because the bug could be anywhere. There’s no single, cohesive architecture — just layers of over-engineering added to compensate for the layer beneath.
It was generated, not designed. This one is new. A growing share of the systems we’re asked to look at started as an AI-generated prototype that worked well enough to sell, then hit a ceiling. The demo was real. The architecture underneath it was never there. We’ve written about that separately in Project Rescue.
The crazy part is how long these problems persist. In most cases we’re talking about tools that employees and customers depend on every single day. You need that software to just work — today and for years to come. Your people, your customers, and your margins depend on it.
It’s almost always salvageable
Here’s the good news, and it’s held up over a decade of doing this: almost every one of these systems can be saved. Usually there’s a stretch of cleanup and stabilization before new development can restart. That’s a small price for software that’s reliable and built to last. And in the rare case where the honest answer is “start over,” you want to hear that with a number attached, not discover it six months into a rescue.
Which brings me to the only advice in this article that matters.
Get an honest evaluation first
If you’re seeing two or more of the symptoms above, let an experienced firm look at your system before you spend another dollar on it. I don’t even care if it’s Frogslayer. Someone you trust should take a real look at the code, the architecture, the infrastructure, and the process, and give you their professional opinion in writing.
That’s what a System Evaluation is. Senior engineers, a fixed fee agreed up front, and you get findings, a prioritized plan, and a proposal for the next step — whether that’s stabilize and extend, modernize, or take it over. You’re under no obligation to take the proposal, and some clients execute the plan in-house or with another team. We’d rather you decide with real information than with a pitch.
For most companies the next step is Modernization & Enhancement: keep what works, fix what doesn’t, and build the headroom for the next five years. For the ones that are truly off the rails, it’s Project Rescue. Either way, something has to change, and the change starts with knowing exactly what you’re dealing with.
Until we started doing these evaluations, I didn’t appreciate how big a problem this is in our industry. Too many good companies have been burned by teams that shouldn’t have been building their software. If that’s you, the situation is more fixable than it feels right now. Start with the evaluation.