The standard platform begins to limit growth. What was an advantage at the outset becomes a constraint after a few years: no access to process logic or data, and no room for functionality the provider did not anticipate.
Magento implementations for complex e-commerce
We implement Magento where the store is no longer a standalone application but has become one of the company’s core systems: exchanging data with ERP, PIM and CRM, serving multiple markets or supporting two sales models at once. We lead the project from requirements analysis through architecture and development to launch and continued platform development.
A free 30–60 minute conversation. You leave with an assessment of fit and a list of areas requiring analysis - not a sales proposal.
Context
The decision to choose Magento rarely begins with technology.
It begins when the current solution starts becoming costly. The sales process has to be bent around the system’s limitations. Another integration requires a workaround. A change that seems obvious from a business perspective proves technically impossible or disproportionately expensive.
The same reasons recur in most of the projects companies bring to us:
Integration requirements are growing. Stock levels, prices, orders, sales documents, product data and shipment statuses must move between systems without manual work or inconsistencies.
Processes emerge that cannot be bought as an off-the-shelf module. Non-standard product configuration, custom pricing logic, order approvals, contract customer support and specific availability rules.
The company wants control over its code, data and infrastructure because e-commerce is too important to depend entirely on the decisions of an external platform provider.
The e-commerce platform serves multiple markets or sales models, and the differences between them go beyond changing the language and currency.
Under these conditions, control over the code, data and architecture is no longer a matter of technical preference. It becomes essential if the platform is to keep pace with the business in the years ahead.
Magento is not automatically better than SaaS platforms. It is better when its flexibility and control deliver a real return that justifies the project’s greater complexity.
Projects we have delivered
See our work
Approach
What we do differently
We begin with questions, not a feature list.
How is product data created and updated? Where do prices and stock levels come from? Which system is responsible for an order at each stage? Which processes remain in the ERP, and which should move into Magento? What should happen if one of the systems is temporarily unavailable?
The answers to these questions have a far greater impact on future stability and development costs than the store’s feature list alone.
We calculate the cost of decisions, not just development.
In complex e-commerce, the code itself is rarely the most expensive part. Architectural decisions that begin to block platform development after a year or two cost far more - especially when changing them means rewriting a large part of the system.
Integration is more than connecting an API.
We determine not only what data should be transferred, but also which system is the source of truth, when synchronisation should occur, and what should happen in the event of an error or duplicate. This is what separates an integration that works during testing from one that reliably supports daily sales.
We use modules when they genuinely solve the problem.
There is no point rebuilding functionality that already exists and is well maintained. But we do not base a project’s architecture on a random collection of plugins simply because they shorten the first stage of development. What matters is the total cost over the platform’s lifecycle.
We design with maintenance in mind.
Technical decisions look different when a team only considers the code until project handover and when that same team will later update, diagnose and develop it. We are in the latter position.
Scope
Implementation scope
We can lead the project end to end or join at selected stages if you are handling part of the work internally.
The process is not a rigid waterfall. Workstreams run in parallel wherever dependencies allow - UX design usually stays ahead of development, while integrations are often built alongside the frontend.
Discovery and requirements analysis
Workshops with the business and technical teams. Analysis of the sales model, processes, external systems, constraints and growth plans. We determine what genuinely needs to be included in the first version of the platform and what can wait.
Functional and technical documentation and architecture
Documented requirements, the approach to implementing functionality, solution architecture, integration design and key technology decisions. The document supports estimation, development and the platform’s subsequent maintenance.
UX/UI
We can prepare the complete UX and visual design. You do not need to come to us with finished mock-ups. If you have your own design team or agency, we work with their materials.
Development
Magento, Hyvä, custom development, integrations and platform configuration. We treat integrations as part of the architecture, not as work bolted on at the end of the project.
Testing and launch
QA, integration testing with your systems, data preparation and migration, environment configuration, and go-live planning and execution.
Stabilisation, maintenance and development
Our responsibility does not end on launch day. After stabilisation, we can take over the platform’s long-term maintenance and continued development.
Technology
Key technology decisions
Magento Open Source or Adobe Commerce
We do not begin a project by choosing a licence. We begin with the requirements.
For new projects, Magento Open Source is our default starting point. We recommend Adobe Commerce when specific business requirements justify its functionality and licence cost. This decision should be made after analysing the processes, not at the beginning of a project discussion.
Frontend
For new implementations, we recommend Hyvä by default.
A lighter frontend means shorter load times and better Core Web Vitals - metrics Google takes into account when evaluating a website and which have a real impact on user behaviour throughout the purchase journey. We treat Hyvä as part of the solution, not as a separate add-on product.
Integrations
We design them as part of the platform architecture.
We determine the direction and frequency of data exchange, how errors and retries should be handled, and which system is the source of truth for each type of data. We have proven experience integrating SAP, Comarch, Microsoft Dynamics and Enova, as well as bespoke systems on the client side.
Infrastructure
Hosting and infrastructure are optional parts of the scope.
We can design, launch and optimise the environment, but you do not have to purchase infrastructure from us. If you have your own provider or team, we work with them. In practice, we are often involved in this area because the configuration of PHP, databases, Redis, Varnish, OpenSearch and caching layers directly affects the performance of the entire platform.
Implementation versus replacing an existing platform
An implementation does not always mean starting from scratch. Just as often, it means replacing a working solution with a new platform while maintaining sales continuity.
If the project’s greatest challenge is migrating data, customers, orders, URLs, search rankings and existing integrations, the right starting point is a separate service:
Migration and replatforming →Team
Why Velocity
Expertise
Magento is our core expertise.
We have worked with Magento for more than 10 years and are an Adobe partner. We understand the long-term cost of architectural decisions because we maintain the platforms we implement.
Experts
The project is delivered by our experts.
A Magento implementation is not a task that can safely be handed to a team learning the platform as the project progresses.
Complexity
We work in complex environments.
Large catalogues, extensive product data, ERP, PIM and CRM integrations, and processes that do not fit within standard configuration. We have delivered projects with catalogues containing hundreds of thousands of products and large numbers of attributes.
Responsibility
We remain accountable after launch.
We have worked with many of our clients for years. We design the platform with its maintenance and continued development over the years ahead in mind.
When Magento is not the right choice
Magento is usually not economically justified for a simple store with a few dozen products, a standard purchase process, few integrations and no significant custom requirements. If the goal is the cheapest and fastest possible launch, a simpler SaaS platform will usually be a better fit.
We say this during the first conversation. Implementing Magento in a project that does not need it results in maintenance costs without a corresponding benefit.
How much does an implementation cost, and how long does it take?
There is no single meaningful price for a Magento implementation, but there are typical ranges.
from
PLN 70,000
duration
3–9 months
The Magento implementations we deliver usually start at PLN 70,000 and take between 3 and 9 months. Projects with extensive integrations and a B2B model typically take 6–9 months.
The primary factors affecting scope and cost are the number and quality of integrations, the availability of APIs in external systems, the B2C or B2B model, the UX/UI scope, the number of markets, the scale of custom development and the condition of the data to be migrated.
The first conversation is not paid discovery. It is an initial analysis that allows both sides to determine whether further cooperation makes sense. Full discovery is a separate, paid stage of the project - but we already gather some requirements during the proposal process so that the estimate is based on specifics rather than assumptions.
Questions
FAQ
VLCT
Magento Open Source is sufficient for most projects. Adobe Commerce makes sense when specific requirements justify it - for example, advanced native B2B functionality, sophisticated content management or enterprise requirements on your side. The answer should follow from a requirements analysis, not from a default choice.
VLCT
Individual price lists and discounts for each customer, company accounts with multiple users and roles, order approval processes, credit limits, requests for quotation, quick ordering from a SKU list, and integration of commercial terms with the ERP. Some of these features are available natively in Adobe Commerce; others we build in Magento Open Source.
VLCT
Yes. Magento provides REST and GraphQL APIs, and we design each integration around the system on the other side. We have experience with SAP, Comarch, Microsoft Dynamics and Enova, as well as bespoke systems. The key questions concern the scope of exchanged data, the direction and frequency of synchronisation, and which system is the source of truth.
VLCT
It depends on the project. The ecosystem offers both free and commercial extensions with one-off or annual licences. Not every feature is worth buying: with non-standard processes, an off-the-shelf module can generate higher maintenance costs than a custom implementation. We present our recommendations during the requirements analysis.
VLCT
Not all of them, but those that affect the architecture and data model do. The integration scope, catalogue model, pricing logic and customer account structure should be determined before work begins because changing them later is costly. Interface details, content and smaller features can be refined during the project.
VLCT
Yes. Magento natively supports multiple websites, stores and store views within a single installation, with separate catalogues, prices, currencies, languages and tax configurations. The level of complexity depends on how much the markets differ in their sales processes, not simply on their number.
VLCT
Go-live is followed by a stabilisation period during which we respond to issues and fine-tune the platform under production conditions. The store can then move into ongoing maintenance and development: security updates, monitoring, troubleshooting and new functionality. You can also bring the platform in-house - the documentation and code quality are intended to make that possible.