Off Shore vs “Self Development”

What your talking about is outsourcing your core business. I would strongly recommend against it. By outsourcing you lose the level of control you need over your core business.

I suggest you read Rob Walling's Start Small, Stay Small, specifically chapter 3. An excerpt (but by all means, read the whole book - it's great):

Hiring someone to build your software is a good middle ground, as it allows you some control over the technical aspects of your product without sucking the coding life from your veins. The biggest hurdle when deciding whether to hire someone to build your software is that you think you can build software better than the next person. You don’t have to admit this to anyone, but every good developer I know thinks his/her code is the best code out there, and that by hiring it out they will receive a poorly-written product. If you’re going to hire out your software construction: You have to get over your desire to write the software yourself. You do. You have to accept the fact that the code is not going to be in exactly your style, and it may not be as good as if you build it yourself.

Walling, Rob; Taber, Mike (2010-08-04). Start Small, Stay Small: A Developer's Guide to Launching a Startup (Kindle Locations 1480-1488). The Numa Group, LLC. Kindle Edition.

He and Mike also cover this topic briefly in Episode 64 of their Startups for the Rest of Us podcast.

Having managed a small team of offshore developers for the past 4-5 months (and all my experience with other outsourcing companies), I can tell you that you do want to be careful. Most of the outsourcing companies I have worked with have produce sub-par code at best.

Even with the good outsourcing companies, you still need to make that the documentation, requirements, and directions you giving the outsourcing team are extremely clear otherwise you might not get what you expect.

You should also keep in mind that time difference and language barrier also impact on the effectiveness of outsourcing.

The best way to do it is work nights and weekends, get a Minimum Viable Product built, and use it to bootstrap or get funding so you can quit your dayjob.

But if you can't or don't want to do that, you can use outsourcing to build your MVP. Just remember the following:

• You will need to devote a large amount of time to communication, quality assurance, and planning, possibly more than if you just wrote it yourself.
• The result may not be what you intended, may be poor quality, or could have other undesired problems. You're taking a gamble, especially if you haven't worked with outsourced development teams before.
• Once you have your MVP, and start getting traction or VC funding, you will probably have to throw away all of the code and start from scratch.

It is possible to do this successfully. But it comes with its own drawbacks and costs.

Do not outsource the whole single project to a single company

If you have a clear idea of your project, and can document it, in specifications, U.M.L., or other documetns, and know hot to delegate it, to other people...

...then you may want to keep your full-time job, and use that small free time (lunch time, weekends, after job) to model (design) your software project, in a way that can be divided or separated in small parts, modules, libraries.

You may want to outsource only parts or sections of you whole project, to different people, and leave the main final integration to yourself.

Its a common practice, even with subcontrators, in the manufacturing market.

An example: Have you seen the first "Batman" movie ("Batman Begins"). The characters had to get all the character uniform & vehicles, from different parts of the world, in order to keep it secret.

Good Luck with your project.

I will start out my answer with a Bush-ism.
You don't know what you don't know.

Every product starts out as an idea.

9 out of 10 ideas, someone has already thought of.

Out of those 9 ideas, 8 have already been implemented. The one that wasn't was deemed a dud, not feasible, too expensive to implement. It was not one of the low hanging fruit.

7 of those 8 ideas were duds meaning that it cost more to make these ideas a reality than the profit from selling the actual product. Why?

1. Because that market niche was already occupied. i.e. Yet another CRM, office suite, database, web server, etc.
2. Because that market niche is legally defended by patents. i.e. If your idea is very, very similar to some patented specialized application. Heck, there are patent trolls going after legitimate companies where prior art has already been there for ages. Why? To intimidate these companies into paying up and settling on a case that has no legal merit.
3. Because there was market saturation already there. i.e. You want to sell software that everyone else gives away for free. Why would I pay for a web browser?
4. Because of consumer indifference. i.e. So you wrote another web server... Who cares?
5. Because of poor marketing, not having an established reputation. i.e. I've never heard of your company. We make purchasing decisions based on the reputation of our vendors. Our vendors are big companies that have been growing steadily for years. They'll be around to honor their support agreements. "You can't go wrong with (InsertBigVendorHere)". "No one ever got fired for going with (InsertBigVendorHere)."

Basically, what it comes down to is a process of elimination. The market is very good at this. There is a lot of stuff in the market. The market separates the quality from the quantity.

That said, if you truly believe your idea is the million dollar baby, do the following:

You need to architect/design the software first. The operative word here is 'design'. Write the user manual or draw out the screens (if it's a web system). Draw out the user interface flow. In other words, you will go from this screen to that by clicking on this link/button, etc. This in itself takes more time than actual programming. You discover all sorts of wonderful things at this stage. For example, that the tools you would have used to build the software would not meet the design requirements. You'll basically go back to the drawing board more and more as your idea hardens into an actual design. When you are confident you've got 99% of the design bases covered, you get to farm out the easy part --> the implementation. The more design you did, meaning the more time you spent on design, the easier it is to see what needs to be done in concrete terms. In other words, this button is tied to this module that calls on this screen that displays these buttons that map to these modules and so forth, ad infinitum. Break out the implementation into pieces. Give out the pieces to different companies that have no business ties. Never reveal the big picture to any one entity. Set up a modular firewall. If version 1.1 of modules A, B and C were completed by OffshoreRUs, don't give them version 1.2 of modules D, E and F! If they kept an archival copy of A, B and C, they've now got A, B, C, D, E and F. By setting up modular firewalls, you ensure that you've got the big picture and no one else has managed to reconstruct your modules from archival code.

That's my 2 cents!
Good luck to you sir!