When planning a new ecommerce website, you most likely have a budget. And of course you want to spend you money wisely, in order to get the most value in terms of design and features that will help you reach your goals.

Typically, when evaluating different platforms, it then makes sense to ask the question: “What do we get ‘out of the box’?”. And that is a perfectly valid concern. Anything that you can get included from the platform vendor logically means that you don’t have to pay your developers to write the same code.

But choosing to use those “out of the box” features might come a a different kind of price, depending on the the layer of the application they exist in. Let’s try and take a look at some examples.

Infrastructure features

By infrastructure, I mean things like databases, programming language, integration points, scalability and replication options.

This is typically pretty set in stone when choosing a platform, and is usually a big part of why you pick that particular vendor. They might come with a specific infrastructure for searching, and that is ok, since you can spend a lot of money writing your own search implementation.

Management tools

All the tools to manage your store, you will most likely also want to be included in the platform. However, depending on your product source, you might not need a fully fledged product catalog management tool. If you already have a PIM system, then the integration will probably handle most of that for you. But there is often no need to develop your own interface for managing tax rules etc.

API functionality

This is where you want to focus a lot of you energi when establishing what features the platform can give your customers. Does the platform supply you with a high level API that makes it easy for your developers to access data and perform filtered searches. Does the API enforce the business rules that can be configured in the management tools? To what degree can you extend the behaviour, and add you own custom data if you need it?

The API is also the natural boundary between your application, and the vendor platform. You typically cannot change the API, and because of that, the vendor can release new versions of it, and you can adapt your application to leverage any new features that might be there.

Frontend application

Many vendors have created sample applications that run on top of their API. They do this for several reasons. First of all, it is really helpful when pitching a platform in a sales meeting, that they can actually show something to you. It is also very easy to make the argument that you will hit the ground running by just taking their sample application, and adapt it to your needs.

Now, this is where you can get into trouble. The application is the place where you can make a difference. Every business is different. Some have a strong story, and some are all about the price. Some have unique products, others are in strong competition. At the end of the day, the website needs to reflect your business, to serve your customers in the best possible way.

If you use a sample application as a starting point, you will not just get a bunch of code for free. You will also inherit all the technical debt that is contained in that code. You will also inherit assumptions made in the application, that might not fit your business, and complexities that account for scenarios that will never happen in your shop.

Some points to consider before accepting a vendor application as a starting point:

• Quality of the code. Who wrote this sample application? Was it written by specialists with a lot of experience, of by interns working for the sales department?
• Production ready. Is the code battle tested? Can it handle the traffic your site will get? Has it resolved all the bugs that might be in there?
• Readability of the code. The vendor wrote it. But your developers will be the ones working with it. Will they be able to figure out and accept the architecture in it? Is it all wired together with duct tape and secret css selectors, or is there a clear structure following a best practise.
• Is it SOLID. Does it follow the SOLID principles, or will changing one thing cause another to break, without you knowing it?
• Does it have a test suite. Having some sort of automated test suite, or at the very least documentation, will help understand the intention of the code written.
• Does it fit your business. If the sample application is written as a clothing store, and you sell electronics, maybe it’s not a good starting point.

In the short term, a sample site might get you started quickly. But in the not so distant future, you will inevitably run into trouble, just because the developer writing your application did not actually write it, which means there is a good chance he has no idea what is going on in this code.

When the underlying API then changes over time, then it is up the your developer to adapt someone else’s sample code. No easy task.

What can I get “Out of the box”?

In summary, I would advise you to evaluate your vendors “out of the box” features from the API level and down. Do not rely on them providing you with a lasting value in a sample/reference application that you will be maintaining yourself. You will most likely inherit an unknown amount of technical debt, and your developers will not gain the knowhow they would by building the application from scratch.

The exception to the rule would be SAAS platforms where you don’t actually maintain the application code yourself, but only put a design skin on top of it.

Do you know any platforms that provide a valuable starting point for an application? Or have you experienced problems when having to maintain the vendors code? Leave a comment.