Build it or buy it? Which should your #startup do?

Hoping to accelerate the time to get his service business going live,  one of the entrepreneurs I'm working with recently asked me whether he should have developers build software, find a third party who could deliver something sooner, or find open source software that the developers could customize. 

Of course, I said it depends. 

Obviously it depends on cost versus the benefit of time to market, but there are other considerations including impact on your staff, your support plans, and perhaps most important, your exit strategy. 

Although most entrepreneurs are faced with this decision at some point and most have no problem making a good decision, I thought I'd jot down a few considerations just in case there's something you might not have thought of. 

Build it yourself

I must admit that in all of my companies, we built our own products.  This was largely because our initial products were 'under the covers' - inside operating systems and invisible to users.  At the time, there really weren't any off-the-shelf solutions that we could use as the basis for what we were building.  In fact, most of our products were these tools that others could use to build their products. 

This approach worked well for us for the following reasons:

---

• We had complete control over the features and implementation of the products.
• We understood the products completely so our support efforts were reduced.
• Because of our modular development, the products were easy to enhance.
• At the time of our exits, there were no questions about the ownership or licensing of our products
  

Of course we had to pay for development and it took more time to get to market, but for us, this approach worked out well.

Using Open Source Software

In my last company, we moved from tools to end-user products and since we weren't the strongest in building beautiful user interfaces, we took advantage of publicly available open source software that was subject to the GNU public license (GPL).  This sped up our development substantially, and since we had a solid proprietary base, the addition of the open source code presented little risk to our products.  We kept the code modularly separate from our main code so we were able to avoid some of the more restrictive aspects of the GPL.  The main advantages to this approach were:

• It saved us a lot of development time.
• The code was open source so we could change and modify it at will - we had complete control over the code.
• The user community helped us with support issues.
• It was free.
  

The way we handled it presented minimal risks, but there were disadvantages:

• The GPL required us to publish and make available all changes we made to the code.
• There were some occasions where the user community couldn't help us with support issues.
• Upon acquisition, the acquiring company had to do a careful examination of all GPL code we used, the changes, and the interfaces to our core software.  They needed to ensure that there was no exposure to their products which would incorporate ours.

Because we were careful and knowledgeable in how we used the open source code, it worked to our advantage, advancing our time to market while preserving our control of the code, and presented only minor issues during our exit (acquisition).

Buying/licensing from a third party

Although we never bought components from a 3rd party to incorporate into our products, we were one of the third parties that sold components and tools to others to help them get to market quicker.  Our products were closed to the buyers.  That is, they bought functionality and we provided external interfaces.  We never supplied source code and they never needed it. 

From our perspective (and theirs since they paid us), buying from us had the following advantages:

• Very rapid time to market.
• A professional organization who guaranteed responsive support.
• No requirement to hire expertise they didn't have or want to have longer term.

As it turned out, well more than half of our customers were acquired by larger companies.  Because we had assignment clauses for our licenses with clear explanations of what that meant in terms of fees and rights, all of these deals went off without a hitch.  And of course, we were happy to welcome these much larger companies as our new customers. 

So, if you're faced with the choice of build it yourself, use open source, or buy from a third party, each can work:

Build it yourself if you have the expertise and can afford to take the time to debug before getting the product/service to market.

If you need quicker time to market and have some expertise in-house, try for open source.  Be sure to keep the open source separate from other components of your offering if at all possible and to follow the GPL rules about publishing.

If you need to get to market as soon as possible, and don't have a lot of expertise in development, consider licensing from a third party.  They can give you a leg up.  Ensure that you have solid enforceable agreements for customization and support, and that assignment clauses are clear and wouldn't scare off a potential acquirer.  Also, vigorously negotiate the license fees.  Most companies are more flexible than you might imagine and many are willing to 'invest' in new ventures for back-end payments upon success.  If possible, get source code/designs.  In the worst case, ask for an escrow in case the company should go out of business. 

But whether you make it yourself, get a leg up from open source, or license a product, ultimately the packaging and presentation is yours.  You're also the face on the support.  From the public's point of view, this is your product/service.  Own it!

First Startup Post

#Startup - When Should you Throw in the Towel?