I believe, at least anecdotally, that you won't find this to be even a rare occurrence. There's exceptionally low motivation to behave this way because writing a program is very disconnected from being able to make a business out of it. What you may find are many stories about developers holding code hostage for additional payment because the relationship was not properly established, but hijacking? There's very little value in that behavior.
While this doesn't exactly match David's question, I think it addresses the underlying concern. I agree with those that have already said that this is a rare occurrence. Most developers either don't want to deal with sales and marketing, or don't have the knowledge to do so.
I strongly disagree with Adrian's advice. Doing what he suggests is one sure way to have a mess on your hands. You will have several groups all pointing at each other as the reason for why it doesn't work correctly. The additional effort to integrate the various parts of the application come with an added cost. Healthcare.gov is a prime example of this. They hired several groups to work on different parts of the software. They spent $500,000,000 on software getting it to the first public release and it didn't work the day the market opened.
Edit: In response to Adrian Leishman's edit about my comment, my opinion is just that, an opinion. However, it is based on 30 years of developing software, managing development teams, and speaking at software development conferences and events. Yes, some shops do break out the front-end and the back-end. and in doing so, they have added additional complexity and communications requirements. You will often find finger pointing in these shops as well. Since shops that do this are often physically co-located and have a good budget to work with, they may be able to overcome this inefficiency.
A startup trying to get to an MVP wants to take the a fairly quick, budget-based approach to the MVP. The more friction added to the process, the less their chance of reaching their goal.
Paul and I generally see things very differently, but I completely agree with him here. In the first place, there are tremendous legal protections against that behavior all around the world. The only instance I've ever heard of involved China and Google, and that was more Tom Clancy than business.
There are quite a few instances where a project isn't exactly hijacked though. For example: Company A develops the tech, owns it, and they're forced to give the project to Company B by the Primary Client for one reason or another. For instance, the AR15 M4/M16 rifle was developed by Armalite corporation. The company wasn't really a military supplier and stability was an issue so they had to "sell" their design to Colt who could produce the weapon for the government.
If at all possible, break your code needs up and spread the work out to multiple developers/teams.
Never have one group do all of your DB/Interface/Backend code. They would basically own you at that point.
That being stated, you can probably trust the large development firms (in the US) to not rip you off but they're generally very expensive.
EDIT: To Joe Walling's comment, I'd like to point out that, even in one consulting firm (or in-house), the Front-end , Back-end, and Database work are usually done by different teams.
It's also important to note that Joe owns a software development firm (Walling Info Systems, LLC) so his perspective may be a little one sided.
I outsourced lens design to the largest company that makes optical design software. I shared the system and its application. And while they contracted to design our system, they filed patents all around our system. I didn't discover they were doing this until the patents published and we had finished our contract with them.
oth of the two recent responses point to the importance of having legal support and writing a contract that covers your concerns. With re-use of code, there's a difference from hiring for exclusive development and ownership of the product, versus delivery of a result. The price is different. Same with graphic design. If you want the source files, the cost is different, up to three times as much as simply delivering an end result.
For the manufacturing design and patent concerns, again it depends on a carefully structured manufacturing contract. If the mfr had to develop new processes or new tools to make the device, that might be their own IP depending on how your contract was written. If instead they stole your invention, rather than invalidate the patent, you could go through District Court for a correction of inventorship. Then you could end up owning the patent they paid to file.
I am not an attorney and you'd need one.
It's also possible that you could avoid going to court, if you have the evidence that you invented it before they did, and although you didn't file for a patent, you as the earlier inventor could be exempt from infringement. It wouldn't give you benefits other than being able to avoid licensing from the company that filed the patent. If their patent(s), as you worded, were merely based on your contract requirements, it may be within their rights. Again, talk to an actual IP attorney.
For example, if they developed a process to make your device and patented that, you may not be able to use anyone else to manufacture it. A new manufacturer would be barred from using the same process without a license, inflating the cost either to find another process or licensing the one that was developed. Manufacturing contracts should always have legal review for these types of reasons.
Paul Garcia brings up a critical point that is relevant no matter where you do development: Well crafted IP agreements and statements of work. While it is never a perfect outcome, in the presence of such, developers may be less inclined to re-use your proprietary code elsewhere.
If you do not address this, then they are free to assume its ownership and reuse. This is true in the US as well as globally. Ironically, the only time I have had to deal with this retrospectively was when a company I was recruited to lead had an "industry leader" in the US file a patent with his name as the inventor.
The greatest risk you will find is in small outsource companies who do not have strong experience in building code for more mature companies and either have not had the issue arise so do not have clear WFH agreements in place as part of their model.
I agree with Paul and Thomas. However, your risk is not the dev team, but some "business" person they know or you have worked with. In one case, a company I was involved with as a Director had the lead sales person walk out with the top salespeople and start a competing firm in the same space. They took the data of customers and inventory, had another developer build the site, and then went head to head. It was unsuccessful because they did not offer value, but the complication was there for the company I was helping to deal with. Knowing why a company does something is far more valuable than knowing how it does it.
Paul and Thomas are pretty spot on. One valid concern I'd add to the mix however, is devs retaining and re-using code developed for your business. A lot of overseas dev shops will actually re-use part or all of your code for projects with other clients, or re-sell the whole codebase as a software package to competing firms, because there's very little you can do to them in terms of litigation. For this reason, I refuse to outsource anything to a firm that resides overseas, nor will I outsource to any US-based firms who are actually just fronts for the same overseas dev shops.
Do your homework, be vigilant, have an ironclad contract with them that establishes clear code ownership and prevents them from re-using all or part of your code for any other purpose, outlines litigious relief, et cetera.
Holding a project hostage can easily be prevented by making sure all your developers submit their work to a private GitHub repository owned by you.
Your developers having a full copy of your system is almost inevitable.
I usually make sure not to share the overall picture of the entire project to new developers I hire and have them start with smaller function development tasks. This allows me to get to know them better and also find out about their loyalty and reliability. I am able to feed my developers one small piece at a time because I have a strong tech and project management background and this helps me be sure not to miss out sharing any vital information that would cause a bigger problem down the road.
Eventually, you'll have to find developers that are committed and you can trust and then present them with the complete concept and make sure they feel they are part of something bigger. One of my mentors once told he tends to trust people when possible because overall, it costs less to trust than to always hold back. I like to keep it balanced.