Most software developers love to deliver. If the overseas contractors have slowed down to a crawl, it's probably not that they aren't "aligned" or willing, but

Most software developers love to deliver. If the overseas contractors have slowed down to a crawl, it's probably not that they aren't "aligned" or willing, but that they can't. If they had the ability to fix the project themselves or their process, they would have. The usual non-technical customer approach would be to demand or plead for the developers to work harder. I've never seen this turn a problem overseas project into a successful one. To unstick, you've got to first is to figure what is wrong, and secondly fix that. But at this point, you don't know what is wrong, and developers don't know what is wrong or find it culturally impossible to communicate the problem. I'd recommend getting some skilled local technical talent to take a look at the code and the recent commits to get a feel for what the underlying problem is. - Off the top of my head, the four mostly likely problems would be: 1. Frameworkitis - Many frameworks, when doing something the framework is not designed to do, require far more code than would normally be require. This even ends up hitting harder since often these overrides must be done in ways that either can't be reused, or must be done in one place, tangling everything together. 2. Overwhelming technical debt - Spaghetti code, untested business logic, the usual. 3. Too much business complexity in the code - Given that the cofounders are not technical, they may have been asking for things that make for a lot of complexity, and the development team may not have pushed back. This can kill later development, since adding new features to complex systems is usually much more difficulty. Alternately, since this is a new business, it's possible that the requirements have been changing, leaving the system more complicated than it needs to be. 4. The developers could simply not have the skills required - A company had me see if I could speed up their application. It was days away from launch. The home page took EIGHT MINUTES to load. (with no customers using the site, only 50,000 records in the database, and static data that only changed every couple months.) Eight minutes to generate a single page! The customer had been telling the overseas developers that this was a problem for weeks. The overseas developers were unable to figure out why, for weeks. After tracking down the problem, I added a cache in front of one piece of code, and took the site from an eight minute page generate time down to under a second. The speed problem was not just due to a terrible architecture, nor a complete ignorance of what the frameworks involved were doing under hood, but mostly that not one person on the overseas team - even the "senior" developer - know that it was possible to find out which parts of code are slow. - To summarize again, probably the contractors cannot fix whatever is currently wrong, and outside eyes are needed.