A founder I worked with hired an agency to build a customer portal. The scope was clear, the contract was $85,000, and the timeline was three months. At the one-month check-in, the agency showed polished mockups and said everything was on schedule. At two months, they demoed a login screen and a dashboard with placeholder data. "We're about 70% done," they said.

At month five, she'd spent $130,000 and the portal still couldn't process a single real transaction. When she finally brought in an outside developer to review the code, he told her the backend was maybe 30% complete. The pretty screens were a facade.

She told me afterward: "I didn't know what to look for. Every update sounded like progress."

That's the problem. Software projects don't blow up overnight. They erode. The warning signs are there early, but they're easy to miss if you don't know what "off track" actually looks like from the outside.

The updates are getting vaguer

Early in a healthy project, your dev team gives specific updates. "We finished the user authentication flow. Next week we're building the payment integration with Stripe." That's concrete. You can track it.

When a project starts sliding, the language shifts. "We're working through some technical challenges." "We're making good progress on the backend." These sound like updates, but they contain zero information.

The shift from specific to vague doesn't happen because the team forgot how to communicate. It happens because they don't have good news to report and they're hoping to catch up before you notice.

Here's a simple test. After every status update, ask yourself: could I explain what was accomplished this week in one sentence to my co-founder or board? If the answer is no, that's not a style issue. That's a red flag.

You can't see it working

This is the single most reliable diagnostic I know, and it requires zero technical knowledge. Can your dev team show you the actual product doing real things? Not mockups. Not wireframes. The real software, processing real data, doing what it's supposed to do.

A healthy project produces working software at regular intervals. At two weeks, maybe you can see a user log in and land on a real dashboard. At four weeks, maybe basic transactions work end to end. The features don't need to be polished, but they need to be functional. If your team is three months in and the only thing they can show you is screens with hardcoded data and buttons that don't connect to anything, you have a problem.

The founder I mentioned earlier fell into this exact trap. The agency showed beautiful UI every two weeks, but the login screen didn't connect to a real database and the dashboard graphs were static images. She assumed visual progress meant engineering progress. It didn't.

Ask for a live demo every two weeks. Not a slide deck. Not a screen recording they polished before sending. A live, interactive walkthrough where you click around and see what happens. If the team resists ("it's not ready to show yet," "we're focused on the infrastructure right now"), pay attention. Infrastructure work is real, but it doesn't take three months before anything is demoable.

The timeline keeps moving but the explanation doesn't change

Delays happen in every software project. That's not the red flag. The red flag is when the timeline moves and the reason stays the same.

"We hit some unexpected complexity in the integration." That's reasonable once. If you hear the same explanation three times in a row, the issue isn't unexpected complexity. The issue is that the team underestimated the work and hasn't revised their approach.

I worked with a startup building an inventory management system. The dev team said the API integration with their supplier would take two weeks. Four weeks later, it was "almost done." Eight weeks later, same answer. Same explanation every time: the supplier's documentation was incomplete.

The actual problem, which came out only after the founder demanded a detailed breakdown, was that the developer assigned to the integration was junior and had never built a third-party API integration before. The two-week estimate was based on how long it would take a senior developer. Nobody told the founder that's what was happening.

A healthy team adjusts. "This is taking longer than we estimated. Here's why. Here's our revised timeline." That's accountability. Compare it to: "We're still working on it. Should be done soon." That's not a plan. That's hope.

The team says yes to everything

This one is counterintuitive. A team that agrees to every feature request and never pushes back seems responsive and accommodating.

In practice, a team that never says no is a team that's not managing scope and not being honest about tradeoffs. Every "yes" to a new feature is a "no" to shipping on time, and a team that won't tell you that is building a project that will go over budget.

The best technical teams I've worked with push back regularly. "We can do that, but it'll add two weeks. Do you want that more than launching on time?" "That feature is a nice-to-have. Can we ship without it and add it in v2?"

If your team never has that conversation with you, either they're padding the timeline so aggressively that every addition fits (you're overpaying), or they're silently absorbing scope and the timeline will eventually collapse under the weight of everything they agreed to.

What to do when you spot these signs

Start by asking direct questions. "Can you show me this working in a live demo?" "What specifically got done this week?" "Why has this estimate changed three times?" "What would you cut if we needed to ship in four weeks instead of eight?"

If the answers are clear, specific, and honest (even if the news is bad), you're probably working with a good team that hit a rough patch. Bad news delivered early is manageable.

If the answers are defensive, vague, or keep changing, consider getting an outside opinion. A half-day code review from an independent senior developer costs $500 to $1,500 and can tell you whether the project is salvageable or whether you're pouring money into a hole. That's the best insurance policy in software development, and almost nobody buys it until it's too late.

The hardest part isn't spotting the problems. It's acting on them before the sunk cost feels too large to walk away from. A project that's $40,000 over budget and three months behind doesn't get better by spending another $40,000. Sometimes the right move is to stop, assess, and change course. That's not failure. That's the same judgment you apply to every other part of your business.