Client
Inventive Retail Group is a major operator of online stores and retail chains in CIS (re:Store, Street Beat, Samsung, Xiaomi, Hiker, UNOde50, "Mir Kubikov," and others), a distributor and supplier of business solutions in the premium segment.
As of 2023, the company owns 365 retail outlets in more than 30 cities across CIS. Revenue for 2022 amounted to 71 billion rubles. It is part of the Lanit group of companies.
The goal: build an online storefront for original products of foreign brands
The client came to the KT.Team team with a request to develop the Brandly online store. The store's catalog consists of original products from brands that left the CIS market. The store buys original products abroad and delivers them to CIS. At the same time, customers enjoy familiar conditions: paying for orders with CIS cards, warranty and replacement of defective items, and confirmation of product authenticity.
To keep the store running, Inventive Retail Group built infrastructure including outside CIS. Brandly's logistics are supported by several warehouses based on major global logistics companies, and the company opened an office in the UAE specifically to operate the platform.
KT.Team was responsible for Brandly's frontend development. It was necessary to develop the entire frontend of the store: the home page, brand pages and product cards, search and comparison pages, the user's personal account, cart, favorites, and so on. The tasks included developing not only the appearance of the pages but also the logic of user behavior: how a user reaches each page, what they can do on it, and where they go next.
Tasks related to the backend and the PIM system remained on the client's side.
Project context
At the start, the KT.Team team received design mockups of the sections and a brief specification from the client. During the work, KT.Team's project manager and developers, together with the customer's team, refined the product functionality, improving the user journey. By launch, the teams managed to resolve several bottlenecks that could have worsened the shopping experience for the store's customers.
Several teams worked on the project simultaneously: the frontend on KT.Team's side, the backend on Brandly's side, and so on. Desynchronization in implementing store elements was avoided through open communication between the teams.
For each category, we had to provide specific filters, design the look and content of the product card, and correctly account for attributes such as the availability of a service warranty for some product categories and different rules for processing returns or replacements.
- We evolved the project together with the client while it was still in development.
- We synchronized with several development teams.
- We accounted for the specifics of several product categories.
Result 1: built a flexible architecture that makes it easy to add and change features
The online store backend is built on the Magento 1 e-commerce platform. The client uses the Elasticsearch search engine and the Redis database management system.
The KT.Team team faced the task of building a frontend architecture that would be compatible with the chosen backend. An important requirement was the ability to break development into small tasks and develop (refine) features in iterations.
At the start of the project, the KT.Team team had nine years of experience delivering Magento projects (some cases can be reviewed here→). Given the platform's specifics and the requirements for maintaining the project, the team proposed adjusting the stack. For frontend development, open-source tools were chosen — the Next.js meta-framework based on the React interface-building library. To connect user requests with the backend, an API was built on the Express.js framework.
This made it possible to automate page loading. For example, a user types a query into the search bar: "crocs." Even before pressing Enter, mini product cards matching the query load beneath the search bar. The frontend queries Elasticsearch, which holds all product indexes and selects them according to the defined rules.
Product card generation is also automated. The KT.Team team refined the product card structure for different categories. When a new product is added, the system "recognizes" which categories it belongs to and selects the appropriate template.
Many elements of the online store can be changed through the Magento admin panel without the help of developers:
KT.Team developers made these fields configurable. To change their content, a content manager only needs to edit the relevant text and swap or add widgets following the instructions. The frontend is built so that changes to these sections and pages blend naturally into the existing design.
The product testing stage was not separated from development. As soon as a feature was ready, the KT.Team and Brandly teams tested it, gathered feedback from the systems, and cleared out bugs. This allowed the implementation to be broken into small tasks and avoided rollbacks to previous versions.
The development stage took less than seven months: the project started in early September 2022, the online store was fully ready on May 1, 2023, and on May 12, 2023 it was launched and welcomed its first customers.
- the content of the home page (banners, categories, product selections);
- "Sale" blocks (presence and content);
- ticker lines;
- widgets;
- the "About Us" page — texts, delivery and return terms.
Result 2: enhanced the personal account functionality to improve the customer experience
The most labor-intensive stage of frontend development for Brandly was working on the personal account. The client's initial mockups envisioned two sections: user information and data on the delivery address and quantity of goods.
KT.Team's e-commerce development experience showed that this structure did not account for all common user scenarios. Since the KT.Team team was responsible for the clarity and usability of the online store, an important part of the project was analyzing the logic of the user's path from the home page to tracking the order status.
The team described possible scenarios and user behavior logic, identified where this logic did not match the functionality specified in the requirements, and agreed on changes with the client.
As a result, the user account grew to five tabs: "Personal Information," "Product Information," "Reviews," "Order Status" and "Returns." Based on various customer scenarios, we expanded the user account functionality together with the client.
- We added the ability to specify additional names and addresses in addition to the customer's primary ones. This allows, for example, arranging delivery of a gift — whether to the house next door or to another region.
- We separated the delivery information for goods within a single order.
- We offered additional services for some products. For example, when buying a laptop, you can add software localization, insurance and an extended warranty right in the cart.
Review a similar project with an architect
Result 3: the customer clearly understands the status and delivery date of each item in a composite order
The original logic assumed that when several products were ordered, statuses and delivery times were calculated for the entire order as a whole, based on the "slowest" product. Yet delivery times for products could differ by several weeks, since products are stored in warehouses in different countries and arrive in CIS separately.
After analyzing the drawbacks of this mechanism together with the client, the KT.Team team proposed tying statuses to each individual shipment rather than to the order as a whole. This increased transparency for customers and eliminated situations where the order status in the personal account (for example, "at customs") differed from reality (a courier with part of the goods ringing the doorbell).
Result 4: many behavior scenarios were worked through, which helped avoid bugs and give users more options for purchasing goods
An important part of the project is asking questions about functionality. For example, when developing the product comparison page, the KT.Team team explored:
The KT.Team team identified these scenarios, documented them (and the desired outcomes), approved them with the client and took them into development. This made it possible to work through many non-obvious requirements before the online store launched.
- how products get onto this page;
- how the comparison should be displayed;
- what happens if products from different categories with different product card structures are added to the comparison;
- how the user can remove or add products to the comparison;
- what if the user wants to add a product to the cart directly from the comparison page?
Result 5: the site handles a consistently high flow of users
The KT.Team team chose the project stack with high loads in mind and drawing on prior e-commerce development experience. That is why the Next.js framework was chosen, which performed well under load and does not consume many server resources (CPU/RAM). Several application replicas can be deployed simultaneously, which makes it possible to sustain high traffic without failures or slower load speeds.
As of mid-June 2023, 42 replicas are deployed. User requests are distributed among them, and each replica has to handle fewer requests. The site runs fast even during large traffic surges. For example, on launch day the number of users reached up to 1,000 simultaneously, and there were no lags.
Autoscaling is planned for the future. It will automatically increase and decrease the number of active replicas depending on load and optimize the use of server resources.
We initiated synchronization between the frontend and backend teams to speed up feature delivery
Since the backend and frontend were developed by separate teams from different organizations, it was important to synchronize their work. KT.Team managers initiated regular team synchronization meetings. During these meetings, the frontend and backend teams exchanged plans and work results.
This made it possible to synchronize the release of features to production: the backend team developed them in the PIM system, Magento, and others, while the KT.Team team worked on the frontend (the online store website).
As a result, we achieved regular, predictable and accelerated delivery of features. Had the teams worked asynchronously, some features would have been delayed in development (for example, if the frontend had already designed the order-tracking logic while the backend had not yet prepared the corresponding infrastructure).
This allowed the Brandly project team to show better product development momentum in internal presentations.
