A lot of the companies that call us arrive with the same uneasy feeling about their software. They can’t always name it. Deadlines have moved a few times. The budget has grown. Updates from the development team are getting shorter and vaguer. They assume they have a software problem, and they’re usually wrong. In most of these cases you don’t have a software problem; you have a team problem.
The mechanic test
When your car breaks down, you take it to a mechanic. You may not understand the repair, but you still have clear expectations. You expect the mechanic to find the cause, stick to the quote, keep you informed, finish on time, and hand back a car that runs.
Software isn’t different. You don’t need to read code to know when something is wrong. If you’ve paid for months of work and what you’re getting back is explanations instead of results, the explanations are the problem. Here are the five signs we hear most often.
Red flag 1: the same bugs keep coming back
Every system has bugs. A healthy team fixes them once. Watch for:
- Defects marked “fixed” that reappear in the next release
- A wave of user or customer complaints after every update
- Your own people spending more time reporting problems than doing their jobs
This usually points at missing automated tests, no real code review, or a team that patches symptoms because nobody on it understands the underlying design. None of those get better on their own.
Red flag 2: deadlines move and nobody explains why
Slipping once is normal. Slipping every time is a pattern. Be wary if:
- Release dates keep sliding by “a couple more weeks”
- Small features and fixes take months
- The team is always almost done and never done
Behind this is usually one of three things: estimates made to win the work rather than to plan it, a team that’s overcommitted across too many clients, or people who aren’t qualified for the job they were sold as. The fix is different in each case, which is why you have to find out which one it is.
Red flag 3: the software is costing you business
Software should be an asset. If it’s the reason you’re saying no to opportunities, that’s the most expensive red flag on this list. It looks like:
- A new customer you can’t onboard because the system can’t handle their requirements
- Competitors shipping capabilities you asked for a year ago
- A process change the business needs that the software can’t absorb
When this happens, the development team has drifted away from what the business is trying to do. Sometimes that’s on them. Sometimes nobody told them. Either way it’s a team problem, not a technology one.
Red flag 4: communication has broken down
Good software work is mostly communication with code attached. Warning signs:
- Frequent misunderstandings about what was supposed to be built
- Status updates you have to chase, and that don’t say much when they arrive
- The sense that your input goes into a hole
A team that has stopped communicating has usually stopped being honest about where the project stands. The silence is the report.
Red flag 5: they don’t understand your business
The best development teams are not order-takers. They ask why. Be concerned if:
- The solutions they propose keep clashing with how you actually make money
- They never suggest a better way to do something
- They’ll argue about a technical detail but never about whether a feature is worth building
You end up paying for features that don’t matter and missing the ones that would. A team that only builds what it’s told will build the wrong thing very efficiently.
Check yourself first
Before you blame the team, look at your side of the table. The most common client-side causes of the same five symptoms are: no single person with authority to make decisions, a scope that changes every week, and requirements that live in someone’s head. If that describes you, a new team will inherit the same problems. Fix the ownership question first. We won’t take on a project without a decision-maker on the client side, and we’d say the same to any firm you’re considering.
What to do about it
Don’t confuse software issues for team issues. And don’t let a team issue run for another year because switching feels expensive. The cost of a stalled project is the business you’re not doing while you wait.
The practical first step is a second opinion from someone who isn’t invested in the current answer. Ours is a System Evaluation: one to four weeks, fixed fee, in which we read the code, talk to your team, and tell you in plain English what shape the system is in and what your options are. Sometimes the result is that the current team is fine and the problem is upstream. Sometimes it’s that the code is salvageable and needs stabilization before new work continues. Occasionally it’s that you should stop. You’ll get the honest version.
If it comes back as a rescue, that’s a service we’ve built specifically for this situation: Project Rescue. And if the system is your own team’s work rather than a vendor’s, the same symptoms and the same evaluation apply. We wrote about that side of it in When your custom software stops working for you.
Your business deserves software that works, and a team that can deliver it more than once. Start with the evaluation. It’s the cheapest way to find out which one you’re missing.