Self-Hosted or Third Party? The New Buy vs. Build Debate
Over the past few months, I’ve watched as one particular e-commerce business make decisions about adding new features to their website. In an effort to increase revenue, they’ve spent time and money on conversion optimization testing, speed and performance testing, a hosted reviews system with more bells and whistles than their previous customer reviews package, a personalization package, two different analytics tools, a hosted video package, and the common ScanAlert and BizRate medals. All in all, when looking at the site, I see 11 different sources of elements on their homepage alone.
I’m reminded of the old Buy versus Build debate, largely focused on cost, where companies argued over whether to build a feature in-house or to buy it from another company. Instead, we’re now looking at a Buy vs. Build vs. Host vs. Outsource debate.
In this day and age, you don’t usually buy a service; you lease it, meaning you pay for it monthly. In a lot of cases this makes sense financially, especially when you only consider the base price – how much would it cost you to build the same thing, versus paying for it monthly?
What business stakeholders don’t always see ahead of time, though, are three important costs:
- Maintenance – rarely does a company list its requirements, hire a firm to build its website, and then sit back to watch the money roll in. We’re always tweaking websites, adjusting the user interface or adding new features in an effort to attract more buyers, increase order values, and measure the return on our investment. Every piece of the puzzle that is your website needs to be retested when you add another puzzle piece. If your site has ten different pieces, and you add an eleventh, not only do you need to make sure piece #11 works, you need to make sure it hasn’t broken pieces #1 through #10.
- Downtime – every new piece of code is one more point of failure. And when the code is hosted elsewhere, not only can the code fail, but the network that supports the software has to be reliable too. If your site relies on code from ten locations, then not only does your server need to be functioning and accessible, so do those other ten locations.
I’m not saying that the decisions this company made were wrong, and I wasn’t involved in the decisions so I’m not even commenting on how they were made. I’m not picking on this one company, but they are a good example of the kinds of problems I see too regularly. I will state that generally, business owners make the decision to add new features based on their own personal desire, what they see competitors doing, and by considering only the cost of the new feature itself. Instead, when considering whether to take a new step with your ecommerce site, business owners should research answers to the following questions:
1. Will my customers really benefit from this, and will it increase the amount they order, the frequency with which they reorder, or reduce the number of returns or support calls our business receives from them? This is not a question to guess at. Talk to your actual customers. Speak with key customers individually, and take a survey of a subset of your customer base to see what they think. And don’t just find out if they think it would be cool – find out if it would make them more likely to give you their business.
2. How reliable is the company behind the product I’m integrating? Do they have a lot of happy customers already? Do they have positive or negative press (check Google) or none at all? Where are they hosted, and what kind of network redundancy do they have in place? Do they offer a Service Level Agreement (SLA) and what is my compensation if they don’t meet the agreement? What happens to the rest of my site if their component malfunctions?
3. How much will it cost my IT team or my web developers to integrate and test the new feature? Do I have the framework for integration and testing without affecting the end users – in other words, is there a development platform I can use for adding the component and testing it, without bringing down the live site? Who is available if a problem becomes known after hours, over weekends, or during a holiday?
4. How will this affect future development efforts? Am I giving my data to a third party, and if so, do I still own it or do they? How can I access that data? What happens to the data if I cancel my usage of the service? Can I easily share the data from one company with another?
A final consideration will lead me to my next post, Too Many Cooks in the Kitchen. Consider whether your company has one owner who can both authorize and deal with any problems that arise. In many cases, I’ve seen non-tech savvy companies hire multiple, independent developers who don’t have the means to effectively communicate with each other, and are managed by a non-technical person who doesn’t understand how the pieces fit together. If the best understanding your internal staff has is “the website stopped working”, you’re probably in trouble. Next time we’ll discuss the need to have a dedicated technical resource (one person or department) to oversee website technical development.