It's not unusual at all. If you do outsource, try and make sure you have a project lead that you can trust. Once revenues get up to a certain point they might want to see the project through and come on board full time OR they will have enough pride in their work to make sure a proper transition takes place.

As far as security, make sure you have an airtight non-disclosure/non-compete agreement with a penalty clause that includes financial remuneration.

Instead of outsourcing development, take those people on directly as remote employees. If you're doing anything more than a multi month project the costs are significantly cheaper (2-3 times cheaper than outsourcing it to a firm) in comparison to taking those developers on full time. I personally would not 'outsource' core development as you'll need them for years afterwards. Let them stay remote but take them on full time.

Christopher provides an excellent answer. The one thing I might add is: be wary of dev shop claims to understand what an MVP is. Despite the success of Lean Startup, I'd argue most dev shops still don't know how to build and iterate MVPs. It sort of runs counter to their business model.

The security concerns should not be your main focus. It's getting the thing to work. I have seen countless times agencies overpromise and underdeliver. The contract needs to be structured in a way to prevent them wasting months of your time promising a product they can not deliver. The other main point to remember, is that likely you will need to hire full time, in house, developers to transition the software if you start to get traction. Most of the times agencies build code which does not scale well. Usually this is due to a tradeoff between speed of development (getting the software to you) and efficient, well architected code.

My advice, whatever it's worth is if you can afford it, build it in house from the start. You will most likely end up rewriting the code once you bring in a CTO. This has happened to almost everyone I know who has worked with an agency.
If you can't afford it, get as many references as you can from completed projects, structure the contract in a way to prevent garbage code, and think through your software from the start to prevent feature creep, agencies hate this, and will make your final code less efficient if you keep springing new features as the build progresses.

Some great responses here that I won't try and reiterate, but the one model that hasn't yet been mentioned (at least from my reading) is a hybrid model built on the ages-old business advice around keeping your core capabilities internal and outsourcing the rest.

If I were in your shoes, I would be hiring or partnering with a technical architect who can craft the design of the technical solution with aligned interests in mind (being a member of your team). Then, you outsource the engineering work based on whatever model works for you (personally, I would have the technical architect hand-pick resources), and use them surgically to deliver parts. This way you have the best talent to deliver the work they are best at, and your distributed model reduces the risk of theft of IP (although IP ownership is usually covered in a good contract).

You also need to decide if what you are building is actually an MVP, or if you intend on the resulting solution to form the foundation of your eventual product. If it's disposable, you don't need to spend a lot of resources getting to something that can communicate a concept. In fact, what you probably need for that is just a good UI designer who can build wireframes. Don't get too hung up on a fully functioning MVP. My best and most useful conversations have come from customers who see nothing working yet but can visualise the concept enough for me to get information on whether to stay the course, or pivot.

Wow! Lots going on in this query - let's unpack a few:

1) Ries intimates in his book that ideas are plentiful, it's the execution that is difficult, and that's why he suggests to relax about people stealing them.

2) If you hire an outside agency, you'll enter into an IP agreement which either has you owning or sharing the rights to the solutions that are developed. You can/should specify the ideas as being proprietary in these agreements. Consult a lawyer.

3) To test an MVP, you don't necessarily need to create a working app - you could validate the assumptions you're making using other mediums. I've seen MVPs for solutions/services that were first enacted using people, cell phones, clip boards and paper. You want to validate the IDEA to see if it has a customer.

4) Consider learning how to code yourself. Since you'll be building an MVP, you just need to learn enough to demonstrate the core idea(s) and get them in front of customers and maybe even investors or crowd-funders.

5) Consider attending Lean Startup Machine, Hackathon and Lean Coffee events and user groups in your area to meet and network with potential candidates to help you build your MVP and maybe even join your nascent team.

6) Start using the words "yes, and..." more and "yes, but.." less when thinking about what you can do. It helps to unlock latent ideas and strategies.

Good luck!

I've built several successful MVP's with contractor labor and I've worked at an agency where we built prototypes for entrepreneurs and companies. My experience is that working with any form of agency is not advisable for an MVP, but not because of security concerns (as others have already addressed).

An MVP will inevitably require multiple iterations to achieve product/market fit or provide you enough data to run a different experiment.

I built the site http://www.tellyourbossanything.com for less than $5,000 in contractor expenses and was lucky to get a ton of high quality press the first few days of launch that brought a few thousand users to us in the first week.

From there, we invested more money to iterate and build. No agency would have been able to iterate fast enough or efficiently enough post MVP.

I would advise that you look for a contract designer and a contract engineer (or two) to work with you. If you're unsure of whether you're qualified to manage these resources or where to look, happy to do a call with you!

Always protect the "core" of your business. It really doesn't matter who the developers are. Your first responsibility is to ensure that whoever is writing the source code has a strong and long term relationship with you and your business.

Take the selection process very seriously and check referees, talk to previous clients or employers and complete due diligence very thoroughly. Good coders, for example, should make plenty of comments within the script so that anyone who comes after can pick it up and run with it quickly. I have seen many businesses suffer because of a fall out with the coder who didn't do this. A new coder comes in and wants to rewrite!

As the former CEO of an outsourcing marketplace, I have a different perspective than many of the people who answered here. I've seen firsthand too many entrepreneurs not understanding the nuances of outsourcing, and finding that their developer sells an exact copy to a competitor, runs with the idea themselves (ask the Winklevoss twins how their outsourcing of Facebook to Mark Zuckerberg went for them!), or goes to work with a better funded competitior (after learning on the entrepreneur's dime!). A key factor in the decision of whether to outsource or not is which country you're using. If your provider is in a country with weak intellectual property protection laws, then you need to understand that you probably have no recourse if any of the above bad things happen. Now, perhaps that's okay because cost is the most important thing to you, and the risk is acceptable. Or perhaps it's not, in that case you will want to keep some of your development in a country with strong laws. Some companies go with a hybrid model where the master integrator is in a country like the US, but the majority work is done by individuals in cheaper countries... none of whom have access to everything. I hope this helps. If you need more tips and techniques on how to outsource safely, just let me know.

Considering that you mentioned MVP in the context of Eric Ries work, I will assume that you are not referring to a small version of a big product, and instead to a hypothesis that is presented in the form of a very simple materialisation — sometimes it's even fake.

Therefore, an MVP, as a tool to test hypothesis is probably not the element that holds the value *in it* — it may actually be a gate so that values are stored somewhere else, perhaps on the network and storage side.

In other words, consider that you hire agency AA to make an MVP A and agency BB for an MVP B. I will force this illustrative situation to say that A is a thesis and B is an antithesis. Both MVPs in execution would generate data intelligence to your learning backstage. Thus, if BB decides to clone B they would end up not in a great advantage position. This illustration is to make a case that the intelligence is the backstage, or that it can be placed there.

It should also be reminded that your advantage is strategic and can be fragmented, also in the backstage. In the historical case of Airbnb, they faced a competitor with larger resources (10x $) that claimed they would clone them entirely really fast. Airbnb kept alive due to their stronger community and other core values that were not in any source code.

Of course this whole question makes more sense with more specific context and clarity. Anyway, my case here makes an alignment with what I think is the view presented by Eric, that the "core business" can be in fact more like a core business advantage of leadership. Is the first move to interpret the MVP that makes the team ahead of the game. It's the move of having a great community, for example.