There’s nothing wrong with responsibly using off-the-shelf software packages. Whether it’s a WordPress blog or a commercial shopping cart, they often represent an affordable way to avoid reinventing the wheel, both from a development and a user-interface perspective.
In addition, many of our clients also find that commodity shared hosting is a fair choice. Face it: if you’re operating a fairly light-weight site that’s getting a few hundred visitors per day, tops, you don’t need that much performance. There’s also a “too big to fail” aspect to being one client of many on a huge machine with a fast connection– odds are, if something fails on their end, you’re the 67th person to report it and they’re already working on it by the time you find out.
However, combining the two can open yourself to surprising difficulties.
Most shared hosting providers will regularly upgrade their software stack– typically replacing older versions of Apache, PHP or MySQL with ones that have fewer security vulnerabilities. It’s a well-intentioned move, but one that can cause you significant difficulties if you’re working with off-the-shelf software.
Many off-the-shelf packages only get “vetted” on a specific band of software versions that were current during the selling life of the product. For example, CS-Cart version 3 only supports PHP 5.1 to 5.3; some older versions of OSCommerce don’t support anything more recent than PHP 4.x. These were reasonable choices when the software was new. However, given that many users will keep their existing cart, without significant changes or upgrades, for five years, it becomes hazardous. The version that was “cutting edge” when first tested eventually rolls to “unsupported legacy” or “unavailable”, and suddenly your entire site is dead, showing just an angrily worded warning about incompatibility. Even worse, sometimes the incompatibilities are subtly hidden– rather than giving a simple warning, the site “looks” correct, but one page out of 75 calls a function whose behaviour has changed, so all of a sudden, you can no longer look up orders by zip code, for example.
In some situations, the vendor has tried to help. X-cart, for example, offers a series of “improve compatiblity” patches for older releases. However, even when they’re cooperative, they reach their limits. You have to have the software at one of a handful of specific “long term supported” versions to add the compatibility patches, and they don’t offer them for really old versions. Honestly, I don’t begrudge them this– they don’t want to spend the rest of their professional lives keeping a 12-year-old version of their software alive, which generates no new revenue, when they could be working on better, more secure, and more advanced versions.
So your hosting is a time-bomb, and one day your shopping cart will bluw up with a newly-introduced version incompatibility. What’s the alternative? You can take control over your own hosting. Spin up a VPS (virtual private server) or cloud instance, with YOUR choice of software stack on it. At that point, you can make your own judgement calls– are the bugs and security risks associated with running the old version less of a cost than the costs associated with upgrading or replacing an off-the-shelf shopping cart or CRM?
Even if you don’t want to do this permanently, it can be useful to buy you a few weeks or months to work out the incompatibilities on a test site, rather than having to scrape together something NOW just so people don’t think you went out of business.
You may be wondering: why I singled out off-the-shelf software for this warning? Won’t you have the same problem with a fully custom package? Yes and no. Of course, any developer can use a language feature or behaviour that’s about to be sunsetted. However, if you have a direct and ongoing relationship with the developer, rather than just being one client among thousands who purchased a canned package, you can probably expect ongoing support and retaining compatibility with your choice of hosting to be part of the deal.