skip to Main Content

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.

Tim Peter is the founder and president of Tim Peter & Associates. You can learn more about our company's strategy and digital marketing consulting services here or about Tim here.

This Post Has 0 Comments

  1. My company is currently dealing with the buy v. build question, but in our case we have already built. We have existing B to C and B to B websites which are meeting our needs rather well. As with all products we have a list of feature requests and bugs which need to be addressed, but these are basically mature products.

    In spite of this, our CIO is reading the common wisdom out there that it makes more sense in general to build than to buy. Does anyone know of any research that has been done with companies that have existing solutions in place? It seems like a very different situation with a different ROI.

  2. Hi James,
    It’s a great question as to what to do when you’ve already got something in place. I believe that a website – as a primary form of customer contact – represents a strategic part of your business.

    When choosing whether to buy or build, a key question is whether the requirement you’re looking at also represents a strategic business component or whether it’s a commodity. Ignore what you’ve invested. Sunk costs are just that. Look instead on what you’re planning to add and evaluate it critically the same as you would any new development. If it’s a commodity, you probably are better off buying. If it’s not and it’s strategic then you should look at building.

    Obviously, the devil is in the details with these questions. Forrester, eMarketer and Gartner often provide good places to look for research on specific marketing/technology topics and may help you answer your specific needs. Or drop me an email (on the About Tim Peter page) and I’ll see if I can help you out.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back To Top
Search