5 stumbling blocks you’ll face when developing your commerce site

Many companies are convinced they’ll achieve good results faster and easier if they develop their frontend themselves. However, Qafoo founder and commerce application development specialist Kore Nordmann has already seen several projects fail in this area. Developing the prototype is simple, so it’s reasonable to think that every other step will also be easy. But this isn’t the case, and companies are often not aware of the pitfalls that such a project involves. The Software Expert repeatedly encounters 5 stumbling blocks that should be considered before heading down the 100% build path.

When building a prototype, it’s usually just a single developer working on it. But when you start working on a full-blown solution, you’ll need more than that 1 Developer. And that’s when the problems start. All the software on each of the developer’s machines needs to be in sync to make sure they’re all working on the same thing. Plus, you also need to make sure your production and staging systems run on the same software versions as everything in your stack, or you’ll find bugs at every turn. It’s a huge job to do this, so you’ll need a team member who’s responsible for it. And while some systems promise to solve this issue, such as Kubernetes, you still need a dedicated person in the team who understands how that system works as well as how to implement it.

If you solve this challenge, the next thing to think about is how to release new software without any downtime to ensure your users can continuously access your site. Usually, you’d have hot replacements in the load balancer, but there are various other solutions to this problem. But again, it needs people who know what they’re doing to keep it running.

A similar problem arises when your platform suddenly receives a lot of visitors, maybe because of an advertising campaign. To manage sudden high loads, you’ll have to make sure the production servers automatically scale without manual interaction. And again, this will need at least a dedicated team member to manage and optimize, as well as a budget to cover costs for increased server usage.

Performance is key for all sites. Not only does it improve SEO, but it increases sales and customer happiness. But companies must recognize the challenges that are involved. For example, the optimization of the frontend assets usually involves continuously optimizing build processes and splitting data. And it’s almost impossible to find developers who have a solid background here.

If you want to embed and show data from multiple data sources, like recommendations, you have to make sure that this data is fetched, cached, and prepared, in parallel for the frontend. And this is a complex task.

If you want your marketing team to change the content in your landing pages for your commerce site, you’ll need to invest in a dedicated interface for this. If you don’t make this investment, your development team will continuously be tasked with making minor changes to the live platform, which takes time away from developing the core platform. It can affect not only the performance of your teams and their effectiveness, but it impacts their job satisfaction.

Even if your marketing team is able to manage content or even change the structure of pages within a Content Management System, they won’t be able to see how their changes will look when they’re published. To solve this problem, you’ll need staging systems or realistic previews to prevent published content breaking the production site.

Developers usually enjoy creating new frontend components, designing the frontend, and updating user flows. Sometimes they really enjoy creating another good framework that powers data flows, too.

If you’re building a headless commerce architecture, the integrations you need to think of aren’t only between the frontend and the backend. Depending on the complexity of your solutions’ architecture, you’ll have other tools to integrate as well. Think of specific tools for search, personalization, marketing analytics, content management, ERPs, and so on. From a development point of view, you’ll have to create them from scratch if you opt for a bespoke frontend. But more importantly, your developers will also have to keep on maintaining these integrations, as they power a network of services working seamlessly together, all the while keeping the entire solution stable and scalable.

While it’s possible to do that with a bespoke frontend, make sure it’s the best use of your scarce developer resources, now and over time, too. Because why should they create all the integrations for tools like Google Tag Manager or backends like headless Content Management Systems themselves if they already exist?

Building a Proof of Concept for a bespoke frontend for your headless CMS or Commerce solution can lead brands and merchants to the conclusion that developing their own frontend from scratch is the fastest and cheapest way to get exactly what they were looking for. And, of course, everyone loves building something entirely by themselves. You get it exactly the way you want, to your requirements.

But from a development point of view, it’s in the details, and what seems like a quick win in the short-term shouldn’t be the deciding factor for a long-term project. Building a high-performing frontend that’s both stable and scalable, while easy and efficient to work with for marketing teams and developers isn’t a small project. And what may start as something that’s easy to build, will quickly become something that takes up a lot of time and resources.

You need to make sure you know what you’re getting into. You’ll have to decide on the setup of the development environment (framework, tests, Continuous Integration) and the hosting environments (along with deployments). Then who will be responsible for each task? Is your development team big enough to handle the complexity? If not, do you have the budget to get new hires? How will all your data be mapped? How will errors be handled? What will happen if your site goes down? The questions go on, and you need answers for all of them. And that’s just for the in-house stuff.

The building and maintaining of an architecture and infrastructure with multiple microservices communicating with each other requires another level of expertise and the resources that come at a high price. Remember, if you’re building your entire frontend, you need to make everything that goes with it and that isn’t easy.

Ultimately, the decision between a fully bespoke frontend and building on top of a Composable Frontend Platform has to be based on the business’s needs first and foremost. Then, carefully map out the initial investment levels for the development and implementation of a bespoke frontend versus a Composable Frontend Platform. Add in the operational efforts (infrastructure, people, opportunity costs) for both solutions and also assess mid-term and long-term effects on efficiency and effectiveness for your development teams.

These considerations will help to come to a decision that not only meets your business needs now but also future-proof your architecture in the long run.