First, if your business is the program itself, then you should ideally bring it in-house, because you don't want your entire business to be out of your control. That being said, you may not be able to do this in practice.
The benefit to outsourcing, when done properly, is that you can gain access to a diverse set of skills that you may not be able to hire in-house. As an example, and I run the risk of over-simplifying, you may need a high-end DBA for some work, but not have enough work for that person to justify hiring them full-time. If you outsource the project, that's not your problem.
The problem, however, is in controlling the quality being produced from an outside vendor, which you may be required to support later on. I have had the misfortune to work on a project built this way (as the later support) and we ultimately replaced the entire code-base. Communication with the development team is one of the key issues, and failure to recognize lapses in quality early on can sink an entire project, even when it doesn't have to end up that way.
However, I have worked with clients who for a variety of reasons did not want to build an entire team in-house (price, cash flow, finding a qualified team, risk management). What I advised those clients to do is to find a third-party to manage the team, and outsource the development from that team manager. The third-party (in those cases, my company) acted as quality control over the companies who were actually doing the programming.
In reference to a comment made previously here, an outside team can outperform an internal team if you don't have the ability to hire effectively. This is one of the biggest reasons to have a technical partner - because without the right background, it will be that much harder to manage this kind of risk.