Build vs. Buy: Which works best? (Guide to Small Business E-commerce)

While we’ve been taking a look at what to do as part of your e-commerce strategy, it’s also important to look at how to do it. By far, the biggest question for businesses is whether to build or buy in your e-commerce investments. My answer: Both.

Assuming it’s one or the other is what logicians call a false dilemma. I call it BS.

Almost all investment will require your time and people to make it fit your business. While some off-the-shelf solutions, such as editors like Jimdo and Weebly, or analytics packages like ClickTracks or Google Analytics work “right out of the box,” fitting them to your business requires at least modest investments of time to get the greatest benefit. For instance, getting the most out of Google Analytics requires setting up filters and goals – definitely worth the time, but requiring time all the same.

By contrast, building should never be from scratch. Too many good open-source or paid solutions exist to allow a developer to start with a blank slate.* At a minimum, you should see if your industry has defined open XML specifications for things like inventory management or content sharing. Then, any build efforts you undertake can comply more easily with industry standards without locking you into a custom solution later. Groups like OASIS and its companion XML.org website detail standards across many industries. Make sure your developers know about them and that you require their use where possible.

So, what process is best for deciding how much to build and how much to buy? Here are 6 steps to figure it out:

1. First, define your problem in real terms. For instance, don’t say “I need a content management system.” Say, “I need to be able to post content every Wednesday outlining my weekend specials and have those specials automatically come off my site every Monday. And I don’t want to have to learn HTML. And I need it to integrate with my inventory system.” While not as robust as a fully blown spec, this process allows you to understand your needs without limiting your options as to solutions.
2. Next, take a look at the marketplace for products that might potentially meet your need. Be skeptical of “out of the box” solutions will “meet all your needs with no effort on your part.” Sometimes sales folks can be… overzealous. But don’t eliminate expensive “out of the box” options out of hand. And don’t assume that all solutions cost “too much.” Development is expensive and many open-source or less expensive options exist of even the most robust commercial products. Even if you can cover half your needs with a commercial or open-source offering, you’ve limited the amount of development you need to do.
3. Third, before negotiating pricing for a purchased tool, have your development team – or your outsourced developers – prepare a quote for what it would take to build out the functionality from scratch and for enhancing the third-party solution. Make sure the quote covers enhancements for 24-36 months. And make sure they account for training and developing documentation. Better yet, get two quotes: one from your incumbent vendor and one from the folks most recommended by your friends.
4. Fourth, get a detailed quote from the packaged solution vendor or open source integrator. Make sure you’re comparing like-to-like with what your development folks quoted, so include items like training and full documentation.
5. Next, compare those quotes. If they’re within 10% of one another – in either direction – you’re probably better off with the purchased solution. If they’re more than 10% off, go back and double check your assumptions, then go with the better deal.
6. Finally, try piloting the selected solution for 60-90 days and see how it works in your world. Obviously, if you’re going to build, that’s harder, but see if you can get a prototype running in a few weeks so you can compare. It may not tell you everything. But it will tell you a lot about what works and what doesn’t.

This method is by no means fool-proof. And it certainly is biased in favor of buy. There’s a reason for that. Building products to meet your needs can be incredibly rewarding and generate excellent returns for your business. But it can also be a bottomless pit into which you throw money for long periods with nothing to show for it except for loss of focus on the business you’re really in. Buying usually gets you part way there quicker and cheaper. And piloting provides an excellent opportunity to learn what you really need in a low-risk environment.

A great strategy poorly implemented is never a great strategy. When you look at where you build, where you buy and where you build and buy carefully and make educated decisions about which works best for you, you’re well on your way to a well-implemented strategy.

* Unless your business model is to create tools for websites. And even then, you probably reuse design patterns, AJAX frameworks and the like. Or you should.