When you are looking for a new e-commerce solution or platform, there are terms often used as arguments for why you should pick that particular vendor. The labels are many: accelerator, framework, boilerplate, starter site, storefront, kick-off code base and so on. Let us try to untangle what they are and why they exist.
When you are looking for a new e-commerce solution or platform, there are terms often used as arguments for why you should pick that particular vendor. The hope is that you as an e-commerce operator will feel secure and that you are buying a very cost-effective solution. Here we are talking about the fabled "starter platform". The labels are many: accelerator, boilerplate, starter site, e-commerce framework, storefront, kick-off code base or similar. But let us use the general word "starter platform" in this article for simplicity. Potato, potato, and yet not.
"I am buying an e-commerce platform, why does that not solve all the complexity for me? Why do I have to have a starter platform too?", you might think as an e-commerce operator. And that is a very fair question.
E-commerce platforms can, in broad strokes, be placed in two categories. At one end of the spectrum we have platforms like Shopify where you should be able to click together a fully functioning e-commerce operation in a few minutes. At the other end of the spectrum we have for example commercetools which is "just" a number of APIs you use to build an e-commerce solution. With Shopify you get going incredibly fast, but you are very limited in what customisations you can make. At the other end of the spectrum we have for example commercetools where you can make basically any customisations, and you have to make sure your agency or your own development team builds everything that should call the APIs.
If you need more flexibility, you pick a platform that resembles commercetools more than Shopify, and because your flexibility requirements are not exactly the same as other e-commerce operators, the platform cannot have everything ready for you.
And this is where the starter platform's value comes in. Very few e-commerce operators of any standing see themselves as 100% non-unique and can run on a platform like Shopify. Customisations therefore need to be made, and they cost money. Sometimes a lot of money. A starter platform can help you get a shorter project, at lower cost and higher quality. Great, right? Absolutely, but it is also important to understand what incentives your agency has in producing the starter platform, and how you avoid the most common pitfalls in implementations.
There are three main reasons why an agency does this:
Become more efficient as an agency
Increase quality
Create loyalty to the agency (aka lock-in)
Let us look at these reasons in a bit more detail and see how you as an e-commerce operator can work with this and avoid common pitfalls.
Having a lot of finished code that can create working solutions for simpler standard problems every customer has, means the agency does not have to spend as many hours on the project. In the best case it means you as a customer do not have to pay for reinventing the wheel yet again when a homepage, product page or footer has to be created. Instead you pay to customise what already exists and to build new things not already there. The hope from the agency is that it should cost less to produce, so they can sell the project cheaper and thus have a better offer than their competitors. Or they can sell fixed-price projects with a higher margin.
The hard part for the agency is to really understand what future customers and e-commerce operators want and need, and what that means in terms of customisations to the starter platform. Do features have to be entirely rebuilt for the unique business needs, or is it enough to change the logo and a few colours? To solve this problem, many agencies try to develop clear feature lists to compare sketches of the desired e-commerce site with a demo site where you can practically show what has been pre-built with dummy content. Many also have starter-platform-anchored wireframes with design (read: Figma) to change and annotate in. Bringing an architect or UX designer who knows all the parts of the starter platform very well usually also helps.
The problem is just that a generalised starter platform will never solve all a customer's problems sufficiently well. It is a bit like PowerPoint's own built-in templates; they work OK for most people, but not really well for anyone. The big risk in a procurement then becomes that an agency estimates a project based on the assumption that the starter platform's parts can be used straight up and in their entirety. And when customer-unique wishes appear, the agency's project manager starts sweating because the estimates do not correlate with reality's requirements. Assessing this inherent conflict between the agency's starter platform and the customer's real needs requires both technical competence and experience of e-commerce processes. (BTW: this is where we at Commerce Mind come in.)
The downside of a large starter platform is that as a customer you can feel creatively locked in by what already exists. You want more freedom when it comes to, for example, design, UX and business rules. The dilemma you are faced with is whether you want to take what exists "out-of-the-box" cheaply, or pay a lot to modify or create new uncertain code. It is often hard as a customer to understand why anything costs at all: "you said everything is in the starter platform and we just want a few new colours"…
What can be hard to understand is that customisations still always have to happen, regardless of how faithful you are to the starter platform. The product model is one such area that almost always needs to be customised, and that drives consulting hours. There are basically no e-commerce operators who do not have unique needs for, for example, product attributes, bundles, product levels and so on. The product model cuts through the whole system and product cards are everywhere, from homepage to category pages to campaign pages to mini-cart to checkout… Suddenly there are 20 page types that have to be adjusted. Seemingly small changes can have big consequences that drive cost and complexity.
But if you can keep yourself reasonably within the starter platform's boundaries, you can get fantastic efficiency in your project. Make sure you as a customer get to share in that efficiency in your contract with the vendor.
By having standardised the code base and the way of solving common challenges, there is a model for developers to follow. Instead of ten different developers solving a problem in ten different ways, there is now one (1) standardised way. That means developers can more easily move between engagements (good for the agency) but above all that bugs are cleared out early and the fundamental architecture in the solution becomes stable and well-proven after a few projects. The precondition for this quality is of course that the agency actively works on feeding experience back and improving the starter platform continuously…
The experience from starter platforms that we at Commerce Mind have worked with is that the development team can to a higher degree focus on new functions when starting from proven code. That hopefully means you get more value for your consulting money, and the vendor's developers have more fun at work. But we will never get away from the fact that bugs and problems will arise in daily life. A good starter platform is no miracle cure against such dull daily grinding.
Really complex e-commerce solutions can require a really complex starter platform. The risk with an overly advanced starter platform is that it is the agency's only "super architect" who built it, and it is so advanced that no other developer dares change it. That creates a dependence on the super architect and their availability to solve basic problems with the starter platform.
In all relationships there is a lock-in effect. So too in the relationship between e-commerce operator and agency. Switching agency will always be expensive because structural capital, knowledge of each other, knowledge of the solution is lost and has to be rebuilt.
An agency-unique starter platform can increase that lock-in effect, but in most cases it is still worth paying the price. We at Commerce Mind have never encountered a case where it has been practically impossible to switch agency because of the lock-in effect in a starter platform.
"Increasing loyalty" with you as a customer (aka lock-in effect) is always a factor agencies have in mind when developing a starter platform. It may not be the main argument for most agencies, but it is guaranteed something sitting in the back of their mind.
If you were to want to switch agency, the normal scenario is that you just get a copy of all your code, including the starter platform. In your contract with the agency it may say that you have full rights to use and the right to change the code, but you may not sell the code to another party. That is usually fully acceptable for most customers.
Possibly you have a licence agreement on the starter platform, with or without a monthly or annual subscription cost. That can be both good and bad. Bad because you may then not be able to cut all ties with your old vendor. Good because your old vendor seems to see the starter platform as a product that can continue to be delivered even if they are not selling consulting hours to you anymore.
The above only concerns the relationship and the lock-in to your old agency. Another, often overlooked, "lock-in effect" can be the new agency's reluctance to accept working with code and a starter platform they did not build themselves:
They are going to take over code and a starter platform they did not build themselves, and anything not built themselves developers are often fundamentally sceptical of. "Not invented here" is real.
If the solution contains packaged parts, they may in the worst case have to help maintain a competitor's solution. That is usually not liked.
Few agencies will want to take over existing code, instead they will do everything to have it replaced with their starter platform. There are degrees of hell here, but the more tightly packaged the solution you try to bring with you, the more likely it is you will have to abandon it and start on something new. Quite simply because no one wants to receive it.
In its simplest form it is a code base based on previous projects that has been cleaned up more or less with previous customers' special hacks removed (hopefully), and you get your own copy that you code from. The most locked-in is a specially built, tightly packaged solution with lots of components that all require their own licensing and perhaps also licence fees you have to pay even if you take the solution to a new agency.
But in the end it is not a question of whether you should have a starter platform or not, because everyone has one in some form. The question is whether they can explain the value of it to you. And whether it limits what you want to do or makes it easier.
If you want help trying to assess architecture, technology and value, feel free to get in touch with us at Commerce Mind. We help companies through independent support, always on the customer's side.
Related articles
AI does not only make development faster, it moves the capability out into the whole organisation. Suddenly anyone can build and change things in the systems. It is enormously powerful, but combined with old ways of working it leads to either chaos or no effect at all. Here is how you lead the shift from tree-tender to forest ranger before entropy runs away from you.
Technical debt is more than a technical concept, it is a business-critical reality that affects everything from time-to-market to customer experience. In e-commerce, where every millisecond and every click counts, the choices you make in your technical platform can have far-reaching consequences. When quick fixes are prioritised over long-term durability, an invisible but growing debt is built up. It affects not only development speed and stability, but at worst can slow the company's ability to innovate and compete. To face the future the right way, technical debt has to be understood, quantified and managed as the strategic investment it actually is.
For Swedish retailers there are plenty of ways to meet this threat by building on what the Chinese giants cannot offer: strong local brand stories, product safety and sustainability as competitive advantages, and a presence that ties digital and physical commerce together. Temu has no stores. Yet.
