Bad developers are bad developers. Screening them out through references, etc., is critical but imperfect.
More often I've observed the case is usually explained less by the individual capabilities of the developers and more by a dysfunctional dynamic between the developers and the product lead guiding them. Even the greatest developers cannot succeed in a garbage-in/garbage-out scenario. Like any interpersonal business relationship, it takes two sides to succeed and just one to fail.
The same is true with problematic relationships with employees. In some cases, you can -- and should -- fire the person on the spot. But more often it pays to question what role you are personally playing -- or more importantly, what role you are not playing -- in their success or not.
Unless you have good reason to presume complete incompetency on the developers' behalf, some self-evaluation of your own contribution to the problems is worthwhile before adopting the nuclear option.
Luis, it could be a SA but the function would be different than creating a new system from scratch. It would be someone who has experience with consulting and outsourced (or even in-house) development and could assess the situation, make recommendations, and optionally help manage the developers to hit the targets - or perhaps code a bit themselves to get things back on track.
@Luis: Spaghetti code can certainly be the result of bad, poorly screened developers.
It can also occur as technical debt resulting from rushed projects with overly critical time-sensitive priorities: a lot of buggy code is the result of shifting the costs of development on to the costs of operations -- often at a higher TCO overall. For a start-up, the operations may not be as critical a cost if you're out to test your market thesis. But if you plan on living with that code for a while, you're going to be hurting. Tradeoffs always have a price.
My main point about potentially needing to examine one's own (non-developer) role in contributing to a buggy or bad product is that swapping out the development team and starting over could just recreate the very same problems with a different development team. That's a very expensive and wasteful way of discovering that you were part of the problem to begin with: you will have just burned through two implementations with two different teams to finally find that out.