Building a new technical core for an online store: from the limits of WordPress to a modern architecture
The first version of the it-shop.rs store grew on WordPress for a year and a half and ran into the ceiling of the platform. Here is why we rewrote it on a core of our own, and what that gave the business.
When building an online store, companies often choose a ready-made content management system. That approach shortens the initial launch and lets them reuse functional modules that already exist. As a project grows, however, a standard platform can become a source of serious technical limitations.
That is exactly the situation we ran into while working on the online store it-shop.rs for a trading company in Serbia.
Limitations of the original solution
The first version of the online store was built on WordPress. Creating it and then adapting it to the needs of the business took about a year and a half and a considerable budget.
A large number of third-party modules and bespoke modifications were used to deliver the required features. As the project developed, its technical architecture became ever more complex. Conflicts arose between extensions, and updating individual components could disrupt the operation of the whole system.
Non-standard requirements proved especially labour-intensive to implement:
- a bespoke structure for product pages;
- integrations with internal information systems;
- marketing tools;
- special checkout scenarios;
- additional features absent from the standard modules.
Despite lengthy development and optimisation, the online store could not be brought to the performance and stability it needed.
Why further optimisation made no sense
The performance of WordPress projects can be improved through caching, database optimisation and additional server resources. In this case, however, the root of the problems was the architecture of the system itself.
Every additional extension increased the number of dependencies, database queries, scripts and interface elements. Even relatively small changes could affect several interconnected components.
As a result, a significant part of the team's resources went on maintaining the existing system, resolving conflicts and restoring it to working order. Further optimisation would have brought only temporary improvements, without removing the fundamental limits of the platform.
Where the real difficulty of the project lay
The distinctive thing about this project was not the design or the set of pages but the internal mechanics. The company had set an ambitious goal: to gather into one store a very large catalogue combining the products of more than ten local suppliers.
Every supplier passes on its data in its own way. Product matrices with prices are exported in different formats, with different structures and under different rules. All of it had to be brought to a single form: the data on every product page aligned so that identical products from different suppliers would be matched reliably and merged into a single page.
Pricing was a task in its own right. Every supplier has its own system of discounts and a complex tariff grid, and all of that logic had to be reflected correctly in the final price shown to the customer.
Multilingualism added another level of complexity. The site was conceived from the outset — and is now built — as multilingual: every product page and every product description exists in three languages, Serbian, Russian and English. Supplier data also arrives in different languages, most often English or Serbian. That made the internal conversions particularly difficult, and the data-processing mechanics were created specifically for this project.
Building the new technical core
Having analysed the project, we decided to rebuild the online store completely, using a modern technology stack.
The new core was designed around the company's specific business processes and requirements. We gave up excessive universality and included only the functions that were genuinely needed. The architecture was prepared in advance for connecting external services, extending functionality and taking greater load.
That approach produced a clear and manageable codebase. New capabilities can now be introduced one after another, without the risk of disrupting unrelated components.
Results of the move to the new platform
After the new core went live, the speed and stability of the online store improved significantly. Pages began to load faster, and the interface started responding promptly to user actions.
Better performance has a positive effect on the user experience, on conversion and on the site's visibility in search. Fast page loading reduces the likelihood that a potential buyer will leave the online store before completing an order.
At the same time, the demands on the server infrastructure went down. The new system is able to serve a larger number of requests using fewer computing resources.
Further development of the project also became substantially simpler. The team can change product pages faster, connect new services, introduce marketing tools and improve the checkout process.
It is worth noting separately that, after the move to our own technology, all the complex processes — merging the catalogues of dozens of suppliers, matching products, calculating prices and converting between languages — were taken into account and made markedly easier. They now run on the side of the new core and have practically no effect on the speed of the site: the project has reached an entirely different technical level.
Project outcomes
Moving from WordPress to a technical core of our own removed the main limitations of the original system.
Instead of an online store that was hard to maintain and dependent on a host of third-party modules, the company now has a fast, stable and scalable platform. The new architecture solved the immediate technical problems and created a reliable foundation for the further growth of the business.
The experience of this project shows that ready-made content management systems are well suited to launching standard solutions quickly. Where there are non-standard requirements, a large number of integrations and long-term plans for development, however, building a dedicated platform can prove the more effective and the more economically sound decision.