Most software projects don't fail for technical reasons.

Talk to anyone after a project falls apart and you'll get the tour. The framework was wrong. The vendor overpromised. The scope kept moving. The last team left a mess. All of it sounds convincing, and some of it is even true.

Here's the part that rarely comes up. In most of the failed software, AI, and automation work I've been close to, the technology did exactly what it was told. What went wrong happened way earlier, before anyone wrote a line of code, back when the team never got clear on the actual problem. The build was fine. It just faithfully delivered the wrong thing.

Think about how these projects usually kick off. Someone decides you need a system to do X. The requirement gets written down as if X is obvious. Everybody nods. The build starts. And three months in, the questions show up that should have shown up on day one. Who actually uses this? What are they doing right now instead? Why does the current mess exist in the first place? What about the twelve edge cases nobody mentioned? By then you've built around beliefs that were never true, and unwinding them costs a fortune.

Good engineers can't save you from this, which is the uncomfortable part. Point a strong team at a badly understood problem and they'll hand you a beautiful, well-architected, thoroughly tested solution to the wrong thing. Their skill just gets you there faster.

I've seen the reverse too, and it's more encouraging. Teams that spent what felt like an uncomfortable amount of time up front just trying to understand the situation. Talking to the people who'd actually use the thing. Poking at why the current process worked the way it did. They looked slow for two weeks. Then they built the right thing once and moved on, while everybody else was on their third rebuild.

So when you're about to greenlight a build, or you're staring at one that's wobbling, skip the argument about tools for a minute. The stack is almost never the real conversation. Ask a plainer question. Do we actually understand the problem we're solving, or do we just have a solution we're attached to? Can someone here describe what the person on the other end is trying to get done, in their own words?

If that's fuzzy, no framework is going to rescue you. Get the understanding right and the technology mostly sorts itself out. Get it wrong and the technology just helps you fail faster.