“Technology must keep up with ambition, not limit it” – a conversation about the future of e-commerce and the role of a software house

Technologia musi nadążać za ambicją, a nie ją ograniczać

The e-commerce market is entering a maturity phase. Mere presence on the Internet is no longer enough to build an advantage. The pace of implementing changes, process automation and the ability to efficiently enter new markets are becoming more and more important. We talk to Michał Kłoczkowski, owner of ecom.house, about why technology should develop together with business.

The company designs and develops advanced e-commerce environments, combining Magento 2 with dedicated modules, integrations and microservices.

Today’s e-commerce is developing dynamically, but many mature companies are hitting a technological ceiling. Where is the problem most often?

In systems designed for an earlier stage of company development. The platform may have served its purpose well for several years, but then the scale of sales, the number of markets, the structure of the catalog and the way the team works changed. If the system stays in the same place, it may be the beginning of problems.

The problem becomes apparent when launching a new initiative. This may be entering new markets, implementing advanced personalization, changing the pricing policy or automating order processing. Suddenly it turns out that a seemingly simple modification requires several months of work, many workarounds and the participation of several suppliers, or we simply hear that it is “impossible”.

Then the system ceases to support development and begins to block it. Instead of helping, it imposes its limits on the company. This often ends with the team abandoning great ideas, not because they don’t make business sense, but simply because the platform doesn’t allow it. This is a signal that the technology that once worked has become insufficient for the company.

You often say that you are a software house running your own e-commerce. How does this experience impact client projects?

At ecom.house, we do not look at the store only from the perspective of code and list of functions. We know the everyday reality of online sales: margins, return logistics, updating product feeds, payment problems, incorrect stock levels and the pressure that appears during the largest campaigns. This experience changes the way you conduct a conversation with a customer. First, we want to know what problem is to be solved, how the process currently works and what financial or operational effect the change is expected to bring.

Sometimes the best recommendation is not an extensive feature at all. A better result may be achieved by simplifying the process or improving the flow of data between ERP, warehouse and store. We can also openly say that a given idea will not recoup the costs incurred. The code is supposed to support the business, not be a value in itself.

There is an ongoing debate on the market: a ready-made subscription platform or an open source environment with dedicated elements? How to make the right decision?

First, you need to look at the company’s stage of development. SaaS can be a very good choice for starters or for very standard processes. It allows you to quickly launch sales, test your offer and reduce initial costs. With a standard business model, it can also operate efficiently for many years. The situation changes as complexity increases. The company sells on many markets, has an extensive pricing policy, several warehouses, its own logistics processes and numerous integrations. Then the closed platform increasingly forces compromises. There are more applications, commissions and dependencies on external suppliers.

An environment based on opensource code such as Magento 2 and dedicated modules gives you more freedom. The company can develop its own sales logic, design integrations in line with processes and decide on the order of changes. This does not mean that every large enterprise must automatically migrate from SaaS, but it is better not to miss the right moment if such a migration is needed.

What does the combination of a ready-made engine with dedicated web applications look like in practice?

We treat Magento 2 as a proven foundation. The engine provides extensive catalog, price, order, customer and sales management across multiple markets. There is no point in creating these elements from scratch if we have a good standard ready and the specific nature of the business does not require it. At the same time, we do not try to enclose every process within one system. If a company needs an advanced configurator, a portal for partners, an unusual order processing panel or an application supporting stationary sales, we design a separate component and combine it with the other elements of the architecture.

Thanks to this, the platform remains modular. Individual parts can be developed, replaced and scaled without rebuilding the entire environment. Documentation and ownership of the code of dedicated elements are also important. The client receives the code, modules and documentation on the terms described in the contract. Changing your technology partner should not mean losing the opportunity to further develop your store.

Does the lack of vendor lock-in mean full independence?

Full technological independence actually does not exist. Each system uses libraries, frameworks, cloud services, payment operators and external integrations. It is important to be able to consciously manage these dependencies. The company should know what its environment consists of, have documentation and have access to the code created for the project. It should also be able to switch providers without having to build the platform from scratch. This is what practical limiting of vendor lock-in is all about.

What directions will build e-commerce advantage in the coming years?

The first area is the further development of multi-service architecture. Usually, the first move is to separate the front-end from the back-end by building the so-called PWA, which gives greater freedom in designing the shopping experience and facilitates the development of multiple channels. However, the “headless” label itself does not guarantee speed or better conversions. Here, the architecture must respond to a specific need and be properly designed, and in the era of AI it allows for easier expansion with good calibration of independent agents.

The second direction is back-office automation. We still encounter large stores where employees manually transfer data, correct orders, or synchronize information between systems. With increasing scale, such activities increase costs and the risk of errors. ERP, WMS, PIM integrations and data flow automation can give a greater effect than another visual change on the website.

The third area includes analytics and data warehousing. AI can support demand forecasting, campaign analysis, customer service, personalization and content management. However, this requires organized data and well-described processes. You can’t effectively automate chaos. First you need to build a solid foundation, and only then implement more advanced models.

Of these three things, however, I expect the greatest emphasis on modularity and a return to microservices. Companies no longer want to make their entire development dependent on one extensive system. They prefer to combine specialized tools into a coherent ecosystem and replace individual elements without stopping sales. Previously, however, such a challenge was difficult and expensive, AI makes it much easier, giving experienced architects and programmers the tools to control more systems at the same time.

What advice would you give to e-commerce leaders who feel that current technology is slowing down business growth?

I would start by pausing and auditing. Not from immediate migration or choosing a new engine. First, it is worth checking where the limitations really arise, how much current dependencies cost and what business initiatives cannot be launched. The audit should combine business, operational and technological perspectives. Only then can you decide whether it is enough to tidy up the architecture, replace a single integration, or whether a complete change of the platform is needed.

Technology must keep up with ambition, not limit it. If every new idea requires fighting the system, costly workarounds or waiting for many months, it is worth starting a conversation about a new architecture. Before technological debt begins to directly deprive the company of revenues and development opportunities.

Similar Posts