June 03, 2020
What are the consequences of both buying and building a commerce platform? Are you a leader or a follower? Get concrete tips on how to navigate away from the most common pitfalls during implementation and guidance on how to make a decision that matches your technical ambitions and capabilities.
The “buy vs. build” decision is one of the big strategic crossroads you’ll come to. Naturally, companies will want to be sure that they’re making the best decisions about their future commerce architecture, but buying and building both have benefits and drawbacks, and you want your decision to be the right one in the long term.
What Are the Consequences of Buying a Commerce Solution?
The primary benefit of buying an out-of-the-box solution is being able to reuse what someone else has already thought through before you. But if you plan to buy software, especially an entire product suite, you should first consider the following questions:
- Will you be able to change or add functionality later on?
- When it comes to the licensing model, will you get locked in or will you only pay for what you use?
- Will you be free to replace the solution at a later stage if you want to?
If the answer to all of those is yes, then it’s a good idea to buy, especially capabilities that could be considered a commodity.
However, if you decide to buy, I strongly advise you to verify that your needs and requirements are all definitely met. That way, you’re not forced to develop functionality you thought you’d already bought. Unfortunately, it’s not unheard of that clients end up in that scenario.
What Are the Consequences of Building a Commerce Solution?
Build is not really just “build.” It would be irresponsible to, for example, re-develop cart functionality from scratch. The build option I’m referring to is really a mix of buy, build, assemble and extend—where you build what’s unique to your business and buy commodity functionalities, like a shopping cart or search. Lego-bricks are often used to symbolise these solutions, whereas the buy-version would be Playmobile.
In the build scenario, it’s common to use inspiration from evolutionary architectures such as MACH—solutions based on microservices, communicate via APIs, are designed for the cloud and have decoupled the front-end from the back-end—can bring several benefits to the business: flexibility, agility, scalability and transformability to mention a few. You can buy commodity functionality and develop from the ground up what’s unique and gives a competitive advantage (i.e. buy the cart and standard catalogue as standard software but develop your own custom pricing and promotion engine).
Are You a Leader or a Follower?
Related to the decision to buy or build is to understand your business ambitions and capabilities and let that guide you in your decision. It has been proven over and over again how successful it is to be a follower. There are fewer risks and it’s more likely that your requirements can be covered by standard platforms. Followers can still have unique offerings that many out-of-the-box product suites still can support with their high level of customisation.
I think it’s crucial to know and accept which of the two categories your business belongs to and as a follower, not be seduced by the promises of agility and flexibility you get in the modern tech solutions, because they come at the cost of complexity.
On the other hand, if you see yourself as a disruptor in the market, then you probably need something more bespoke. You want to take advantage of the opportunity it gives you to present your offering to the market in a way that highlights what makes your business and offering unique. Remember the easier it is for others to copy, the shorter your marketing window will be.
Avoid Pitfalls Choosing your Commerce Solution
Engagement & Communication
It doesn’t matter how good your code is or how brilliantly you design a process or solution, the success of a project always boils down to people and communication. Involve the right people from the start; that includes the people who will be instrumental in building and integrating the new architecture, but also those whose jobs will involve interacting with it on a daily basis. Good communication from the start is vital and means that when you come across colleagues with a low level of tech savviness, you are able to ease concerns, educate and promote the benefits that this change will instil.
Organisation
Make sure that you are prepared to have the right organisation. A multi-services approach requires multiple teams working across multiple business streams. If you don’t have the option for multiple teams (the ideal set up), then make sure that your team is set up to work across multiple back-ends—e.g. a promotion might require the team to work across the CMS, eCommerce and A/B testing tools.
Commitment
You need commitment from the organisation. To make organisational change, it’s also vital to include senior stakeholders in the decision so that they are fully aware of the benefits and challenges that this process is going to throw up. Make sure you have the mandate to make the necessary decisions from the start.
Start Small
Prototype, test, learn incrementally and secure business value early on. Always keep in mind that the system architecture should support and reflect the desired organisational setup.
Summary
- The benefit of buying is being able to reuse what someone else has already thought through before you. But, if you do decide to buy, I strongly advise you to make sure that you intricately understand what’s included.
- The build option offers a pick-and-choose approach where you buy commodity functionality that you can assemble and combine with custom-built functionality. You get flexibility, agility, scalability and transformability,
- Reflect over your company’s ambitions and capabilities and let that lead your decision. Don’t strive for the latest & greatest if it doesn’t make sense, but ask yourself if you and your business will be better off with Lego or Playmobile in the long run?
When simplifying the arguments like this, the build option seems very attractive, but it doesn’t make sense for the majority of companies within the commerce domain to go for this option.
All the benefits come at the cost of complexity: There are more moving parts and dependencies, so there’s more focus on governance. Maturity and competency within the organisation are key to making sure you can deliver on your ambitions and many companies aren’t ready for that from a technical or organisational perspective.
I hope this article has pointed out what’s important to consider when making long-term decisions for your commerce architecture. I strongly believe that API-based commerce will be one of the most common architecture patterns for enterprise architectures in the coming years, and I see more and more clients making the transition. Global trends are also showing that companies are asking for MACH-ish solutions that will give them the speed, flexibility, differentiation power and support innovation that they so desperately need in these changing times.
Talk to the Commerce Experts
It’s really important to be realistic from the start about what making this decision is going to mean for your business. Whether you decide to build or buy, the best thing that you can do is seek expert advice—people who will be able to guide you safely through the process in a way that will maximise investment and boost your commerce business well into the future.
For more advice on how to make the right decision:
The Valtech Commerce team works alongside some of the world’s best-known brands to deliver best-in-class commerce solutions to transform businesses for the long term. With 3500+ specialists in 45 offices across 16 countries, whatever you need to achieve, our teams are here to help you succeed.
