Why the best e-commerce implementations start with difficult questions
In many companies, the moment an e-commerce project begins is equated with the start of development. A backlog appears, the first mockups, integrations, a sprint schedule, a list of features and the expectation that, since the technology team has started working, the project has actually begun.
In practice, the best implementations start much earlier.
Not with the first line of code, not with the choice of modules, not with the decision about the appearance of the homepage and not with determining which features should be included in the first stage. They start at the moment when the company is ready to ask itself difficult questions about its sales model, operational processes, data, integrations, customers, business scale and the way in which the e-commerce platform is supposed to support growth in the coming years.
It is precisely at this stage that decisions are made which later affect the cost of implementation, the pace of work, the quality of the architecture, system stability, platform scalability and the possibility of further developing online sales.
If this stage is skipped, development very quickly starts to play the role of a costly way to fix disordered business decisions. The implementation team receives a list of features, but does not always receive an answer to the question of why these features are needed, what problem they are supposed to solve and how they fit into the entire sales architecture.
At CREHLER, we see this especially in complex B2B and B2C e-commerce projects, where the platform is not a separate store operating alongside the company, but part of a larger ecosystem. It is connected with ERP, PIM, WMS, CRM, payment systems, marketing automation tools, marketplaces, data warehouses, BI systems and customer service processes. In such an environment, the “implementation of an online store” is never only the implementation of an online store.
Strategy is not an addition to the project. It is protection against costly chaos
Strategy before the start of development is sometimes mistakenly understood as a document that delays the project. In reality, a well-conducted strategic stage does not slow down the implementation, but protects the company from decisions that are much more expensive to reverse later.
In e-commerce, many mistakes do not reveal themselves immediately. At the beginning, everything may look correct. The platform works, products are visible, the cart accepts orders, the integration transfers data and the user can go through the purchasing path. The problem only appears when the company begins to scale sales, enters new markets, expands the offer, adds new customer groups, launches marketplaces, changes the discount model or tries to implement more advanced automation.
Then it turns out that some decisions made at the beginning of the project were too short-sighted. The product data structure does not support further expansion. The pricing logic does not take into account complex B2B conditions. The integration with ERP does not handle exceptions that are standard in everyday sales. The architecture is not prepared for the development of many channels. The customer panel does not respond to the real needs of buyers. The ordering process still requires manual support from the team, even though one of the goals of the implementation was automation.
Such problems very often do not result from the technology itself. They result from the fact that, before development began, there was no strategic conversation about how the company really works and how it is supposed to work after the implementation of the new platform.
That is why strategy is not a presentation prepared “for the sake of order”. It is a way of confronting business expectations with operational reality. It allows the company to check whether it knows what it needs, whether its processes are ready for digitalization, whether the data is sufficiently organized and whether the chosen technological direction truly supports business goals.
Difficult questions are cheaper than later rebuilds
In e-commerce projects, it is easy to talk about features. It is much harder to talk about dependencies, consequences and limitations.
A feature sounds specific: product configurator, B2B panel, individual price lists, integration with ERP, automatic invoices, support for multiple warehouses, separate commercial conditions for customers, multilinguality, marketplace, quick reorder, product recommendations, AI in customer service.
However, the real questions start much deeper.
Can the current pricing model be sensibly reflected in the system? Are all commercial exceptions still necessary? Is the product data complete, consistent and ready to be used across multiple channels? Should ERP be the source of truth for prices, stock levels and contractors? What should responsibility for data look like after implementation? Which processes should be automated, and which first require organizational change? Should the platform support the company’s current way of operating, or help it move to a new sales model?
These are questions that can be uncomfortable because they concern not only technology, but also the way the business is managed. They show places where the company operates through habit, manual workarounds or exceptions that have become part of everyday life over the years. Without naming them, the technology team can only transfer existing chaos into a new system.
And this is one of the most expensive scenarios in e-commerce: a modern platform that recreates old problems in a more technologically advanced environment.
E-commerce should not copy the current operational chaos
One of the most common mistakes made before implementation is the assumption that the new platform should accurately reproduce the company’s current way of working. At first glance, this sounds logical, because if the company operates in a certain way, the system should support it.
The problem is that the current way of working is very often not the target operating model, but the result of years of compromises, exceptions, manual processes and decisions made on an ad hoc basis.
In B2B companies, this may mean hundreds of individual arrangements with customers, price lists maintained in Excel, orders placed by email, manual confirmation of availability, different delivery rules for selected contractors, non-standard discounts, separate document workflows and extensive knowledge held by sales representatives that has never been translated into system logic.
In B2C companies, this may mean a dispersed product offer, incomplete data, inconsistent descriptions, separate processes for marketplaces, manual updates of promotions, limited automation of order handling and no consistent customer view.
If strategic work is not carried out before development, there is a high risk that the new e-commerce platform will become a digital copy of these problems. It will be visually new, technologically modern and potentially very extensive, but it will still be based on disordered processes.
That is why one of the most important tasks at the beginning of the project is to distinguish what the company does today from how it should operate after the implementation. Strategy is not about mindlessly writing down current processes. It is about assessing which processes are worth reproducing, which should be simplified, which should be automated and which should be completely rebuilt.
Before development, you need to understand not only the store, but the entire sales ecosystem
A modern e-commerce implementation rarely concerns one application. Especially in medium-sized and large companies, the sales platform is part of a larger architecture in which each system has a specific role.
ERP is responsible for key operational data. PIM organizes product information. WMS supports logistics and warehouse operations. CRM gathers knowledge about customers. Marketing automation tools handle communication. Marketplaces generate additional sales, but they also require consistent data and well-designed processes. Analytics systems show results, but only when data is collected and interpreted correctly.
If, before development begins, the company does not know how these elements are supposed to work together, the project very quickly begins to drift. Each integration becomes a separate topic. Each exception requires an additional decision. Each data inconsistency comes back as a problem on the implementation side.
That is why the conversation about strategy must cover not only the appearance of the store and the list of features, but also data flows, system responsibilities, business rules, integration priorities and the future development of the architecture.
At CREHLER, this is exactly how we approach e-commerce projects. We analyze not only what is to be implemented, but also how the platform will operate in the company’s entire environment. Thanks to this, technological decisions are not detached from business processes, and development does not start with a wish list, but with a well-understood logic of how the organization works.
Strategy helps determine what should really be included in the first stage
One of the biggest challenges in e-commerce implementations is the scope of the project. Companies very often want to launch everything at once because every feature seems important. Customer panel, advanced personalization, multilinguality, integrations, marketplaces, loyalty program, recommendations, advanced promotions, automations, additional user roles, AI features and full analytics.
Without strategy, it is difficult to assess what is truly critical at the start and what can be planned as the next stage of development. As a result, the project may become overloaded with a scope that extends implementation time, increases cost and makes it harder to maintain quality.
A well-conducted strategic stage makes it possible to organize priorities. It helps separate features that are necessary to launch sales from those that will build an advantage in later stages. It also makes it possible to check which elements require preparation earlier because they affect the architecture of the entire solution.
Not every feature has to be implemented immediately, but many decisions need to be made with the future in mind. This is a very important difference. Strategy is not about limiting the company’s ambitions, but about planning the project in such a way that the first stage does not close the path to further development.
Lack of strategy increases the risk of conflict between business, IT and operations
An e-commerce implementation always affects many areas of the company. The management board looks at investment, return, scaling and competitive advantage. Sales looks at customers, commercial conditions and relationships. Marketing looks at conversion, content, campaigns and user experience. IT looks at security, integrations, stability and maintenance. Logistics looks at availability, warehouses, deliveries and returns. Customer service looks at communication, complaints and everyday problems of buyers.
If these perspectives are not connected before development, the project begins to generate tension. Each department has its own vision, its own priorities and its own definition of success. Then the implementation team is placed in a difficult situation, because it is supposed to deliver a solution that the organization has not managed to agree on internally.
Strategy helps build a shared understanding of the project. It does not mean that all decisions will be easy, but it makes them conscious. It makes it possible to determine what the business goal of the implementation is, which processes are to be changed, which limitations are critical, which risks must be taken into account and how the success of the project will be measured.
Thanks to this, development is not a battlefield between departments, but a stage of executing a previously agreed direction.
Good questions reveal risks before they become technological problems
The greatest value of strategy before development is the possibility of detecting risks earlier. Not every risk can be eliminated, but most can be planned better if they are named early enough.
The risk may be low quality of product data. It may be too many exceptions in the pricing policy. It may be the lack of a process owner on the client’s side. It may be the unavailability of the operational team at key moments of the project. It may be too broad a scope of the first stage. It may be a mismatch between the current ERP and the planned sales model. It may also be the lack of a decision as to whether the company only wants to launch a new platform or actually change the way it conducts online sales.
If these topics appear only during development, they usually cause delays, additional costs and difficult project decisions. If they are discussed earlier, they can become part of the plan.
That is exactly why difficult questions are one of the most important tools in a good implementation. They are not meant to complicate the project. They are meant to prevent it from becoming much more complicated later, in a far more expensive way.
The role of a technology partner should not start with coding
In complex e-commerce projects, a technology partner should not be only an executor of the backlog. Its role should begin with understanding the client’s business, processes, limitations and goals. Only then can it responsibly recommend technological solutions.
If an implementation partner begins work only by executing tasks, there is a risk that it will very efficiently build something that does not solve the right problem. It may deliver features in line with the brief, but not necessarily in line with the real business need. It may complete an integration that works technically, but does not support the target process. It may implement a B2B panel that looks correct, but does not relieve sales representatives in their everyday work.
That is why a good partner should be able not only to answer the client’s questions, but also to ask its own. It should help organize priorities, indicate dependencies, assess the consequences of decisions and show which solutions will make sense not only on the day the platform is launched, but also after one, two or five years of development.
At CREHLER, it is particularly important to us that the stage before development is treated as part of real project work, not as a formality. This is when the foundation is created for the architecture, integrations, scope of implementation, cooperation model and further development of the platform.
Strategy does not end with a document, but with decisions
The strategic stage has value only when it leads to decisions that later organize development. It is not about creating an extensive document that will be approved and put aside. It is about preparing a practical direction for action.
After a well-conducted strategy, the company should know what the goal of the implementation is, what scope should be included in the first stage, which integrations are critical, which processes require change, what data needs to be organized, which features have the greatest impact on the business and which architectural decisions must be made before work begins.
Such a stage also allows the company to better assess the budget and schedule. Not because it eliminates all unknowns, but because it limits the number of assumptions made blindly. The better the company understands its project before development, the greater the chance that implementation work will proceed in an orderly manner.
Strategy does not guarantee that the project will be simple. In good e-commerce, many things are never simple, because the sales platform must handle the complexity of the business. However, strategy makes this complexity consciously designed, rather than accidentally discovered during coding.
The best implementations start before the first sprint is created
A good e-commerce implementation is not about starting development as quickly as possible, but about starting it at the right moment – when the company understands its goals, processes, data, limitations and direction of development.
The best projects do not start with the question: “what should we build?”. They start with much more important questions: why are we building this, what problem are we solving, what needs to change in the organization, which decisions will affect the future and how to design a platform that will not only support current sales, but also allow them to scale.
That is why difficult questions are one of the most important elements of a good implementation. They help avoid accidental decisions, reduce the risk of costly rebuilds and allow the company to build a solution that makes sense from a business, operational and technological perspective.
If a company treats e-commerce as a strategic element of growth, it should not start with development. It should start with a conversation about how its online sales are really supposed to work.
At CREHLER, we help companies go through this stage consciously – from process analysis, through solution architecture, to implementation and further development of the e-commerce platform. Thanks to this, development is not the beginning of searching for answers, but the execution of a well-thought-out direction.
If you are planning to implement or develop an e-commerce platform and want to check whether your project is ready for the development stage, let’s talk about strategy, architecture and the decisions worth making before the first sprint is created.
