Magento online store development
We build complex B2C and mid-market eCommerce on Magento Open Source: catalogs with attributes and filters, multi-store in one admin panel, integrations with ERP/CRM, payment and delivery, migration from another platform, a technical SEO foundation, and performance work. Magento Open Source from $5,000 — a starting point for a limited scope; we calculate the exact amount after discovery. No promises of rankings, traffic, or a “store that scales itself.”
When Magento is justified, and when another platform is better
Magento is a heavy platform: it gives control over complex catalog, pricing, and multi-store logic, but it requires development and infrastructure resources. For a simple store it is overkill.
| Situation | What we recommend |
|---|---|
| Complex catalog with attributes, variations, different price lists for groups | Magento Open Source — catalog and pricing logic justifies the complexity |
| Several languages, currencies, or markets in one admin panel (multi-store) | Magento Open Source — store views cover this scenario |
| Migration from another CMS with data and URL preservation | Magento Open Source — if the target logic is complex; otherwise a simpler stack |
| Small catalog, standard checkout, quick start | store on OpenCart — a lighter platform for typical tasks |
| Non-standard business logic beyond boxed eCommerce | custom eCommerce on Laravel — when you need your own application |
| A general overview of eCommerce development and basic stages | turnkey online store development — the parent service page |
Magento Open Source vs Adobe Commerce — what exactly we build
“Magento” is not a single product. Open Source and Adobe Commerce are different editions with different licensing and feature sets. Some B2B features are often mistakenly attributed to “Magento out of the box,” although they work only in Adobe’s commercial edition. So first we pin down which edition you are actually launching.
| Edition | For whom | Licensing | What we do with it |
|---|---|---|---|
| Magento Open Source | custom B2C / mid-market | open source + hosting and development TCO | development, customization, integrations, migration, support |
| Adobe Commerce | enterprise level | Adobe commercial license | not our service — we will point out the boundaries and where to turn |
| Adobe Commerce B2B | B2B / mixed models | separate availability in Commerce (extension) | not our service — company accounts, shared catalogs, customer-specific pricing outside Open Source |
Which Magento stores we build on Open Source
Four typical scenarios that Magento Open Source fits. All are within the Open Source edition: without Adobe Commerce enterprise B2B features that require a different license.
B2C with a complex catalog
A retail store with many SKUs, attributes, and variations, where filters and facets have to work for real demand. We design catalog, pricing, and promotion logic around your assortment, not around a theme template.Multi-store: languages, currencies, markets
Several store views in one admin panel — separate catalogs, prices, and content for different markets without code duplication. We pin down the number of store views and localizations at the start, because it directly affects timelines and budget.Multi-source inventory
Several warehouses or shipping points with source and stock logic. In Open Source this is available, but reservation and routing rules depend on configuration and customization — we agree on them for your processes rather than turning them on “as is.”Migration to Magento
Transferring the catalog, customers, orders, and content from another platform with URL preservation and redirects. Migration scope is a separate estimation block; details are below in the section on SEO and migration safeguards.What Magento store development includes
A project starts not with a theme but with processes: how the catalog is structured, how orders are processed, which integrations are needed. What is included in the cost and what the client pays separately (licenses, hosting, paid extensions) we record in the estimate.
| Work block | What it gives the store |
|---|---|
| Discovery and business logic | documented catalog, order, and integration structure before development starts |
| Technical specification | fixed functionality and requirements — the basis for estimating timelines and budget |
| UX/UI and prototype | wireframes of key pages and eCommerce design built for conversion, agreed before layout |
| Module and theme development | custom logic through our own modules, we do not touch the core — easier updates |
| Integrations | ERP/CRM, payment, delivery, analytics with controlled synchronization |
| Technical SEO foundation | clean URLs, canonical, sitemap, metadata templates — conditions for indexing, without promising rankings |
| Testing and QA | functional, cross-browser, and full-cycle test orders |
| Launch and support | cutover, post-release monitoring, and agreed maintenance |
Magento layers, modules, and integrations
A Magento solution consists of separated layers: when each layer is independent, updating one component does not break the rest. We write a custom module when a ready-made solution from Marketplace does not cover a specific requirement — not by default.
01 Core (catalog, orders, prices, customers — we only extend) → 02 Theme (templates, CSS, JS; custom — for a non-standard structure) → 03 Modules (search, payment, discounts, custom logic) → 04 Integrations (API to ERP, CRM, payment, delivery, analytics) → 05 Infrastructure (staging and production; we test changes separately)
We describe each integration not with the slogan “data syncs itself” but with parameters: direction of synchronization, source of truth, frequency, retries and idempotency, monitoring, and who owns the integration after launch.
| Integration | Direction / source of truth | How we control it |
|---|---|---|
| ERP / accounting system | two-way; the source of truth for stock and prices is ERP | batch or events, retries, reconciliation of discrepancies, logs |
| CRM | from the store to CRM; the source of truth for the customer is CRM | order idempotency, alerts on failures, field mapping |
| Payment provider | two-way; the source of truth for the transaction is the provider | sandbox tests, statuses and webhooks, payment reconciliation |
| Delivery services | from the store to the service; statuses back | API limits, retries, control of waybill generation |
| Analytics (GA4) | from the store to analytics; eCommerce events | event verification, agreed parameters, owner — the team |
Speed as a method, not a promise
Magento is demanding of infrastructure: load grows together with the catalog, integrations, and traffic. We do not promise “a page instantly” or “scaling without limits” — instead we design and verify performance against an agreed profile of catalog, traffic, and peak orders.
Performance budget and profiling
We set target metrics and look for real bottlenecks through profiling rather than optimizing at random. Then we work on what actually slows down the specific store.Cache, Varnish, and CDN
Full Page Cache and Varnish remove repeated queries to the database; a CDN serves static content from a closer node. We select the configuration for the hosting model rather than turning it on by template.OpenSearch and indexers
Search on OpenSearch and correctly configured indexers are critical for a large catalog. We agree on a reindexing strategy so that catalog updates do not hit performance.Queues and background processes
We move heavy operations into queues so they do not block the user. This is a method of offloading, not a guarantee that the system will “withstand anything.”Image optimization and Core Web Vitals
Compression and modern formats reduce page weight. We analyze CWV (LCP, INP, CLS) on the store’s field data rather than promising abstract “minus seconds.”Load test and peak readiness
Before seasonal peaks we run load tests on the agreed infrastructure and prepare an action plan. What is included in the cost and what is a separate DevOps service we record in advance.We plan a resource reserve at the design stage, because moving infrastructure later is more expensive. But “reserve” means an agreed load profile and verification by tests, not an unconditional promise to hold any traffic.
Technical SEO foundation and safe migration
SEO on Magento is decisions made during development: URL structure, canonical, managed indexing of filters, metadata templates, markup. We lay the technical SEO foundation, but rankings and traffic depend on demand, competition, content, and promotion — so we do not guarantee them. This foundation is then picked up by eCommerce SEO promotion.
Anatomy of a product page
– URL / canonical — a readable clean URL; canonical as a preference signal, not the only protection against duplicates
– Title / H1 — a metadata template for thousands of products + quality control; H1 is the exact name
– Filters — we index only where there is demand; other combinations are removed with canonical / noindex
– Markup — Product / Offer / Review — eligibility for a rich result, not a guarantee of display
– Images — alt, compression, modern formats — impact on both CWV and Google Images
– Availability / price — page data matches the feed and store stock
Migration to Magento is a separate scenario with its own risks. We go through it step by step, with data reconciliation and SEO preservation.
01 Source audit (catalog, customers, orders, content, current URLs) → 02 Mapping and URL (structure correspondence + 301 redirect map) → 03 Transfer (data + delta migration; passwords often cannot be transferred) → 04 Reconciliation (validation and data reconciliation before cutover) → 05 Cutover + monitoring (rollback plan, downtime window, indexing control after launch)
Security as shared responsibility
Magento security is a process, not a one-time setup, and responsibility for it is shared. Under Adobe’s official model, the merchant and the partner are responsible for custom code, integrations, supported dependencies, patching, and incident response. We cover the technical part and agree on who does what after launch.
Supported versions and patches
We keep Magento and dependencies on supported versions and apply security patches per the update policy. A patch reduces the risk of known vulnerabilities but does not make the system invulnerable once and for all.Access: 2FA and least privilege
Two-factor authentication, minimally necessary rights, access control. These are levels of admin-panel protection, not a “secret URL” as the main line of defense.Secrets and secure coding
Managing secrets outside the code, reviewing third-party extensions before installation — they are a frequent vector of problems. We check every extension rather than installing it blindly.PCI scope and payments
We agree on the PCI scope with the payment provider so that the store does not hold unnecessary payment data. The specific model depends on the chosen provider.WAF, CDN, and scanning
We apply WAF and CDN depending on the hosting model, not as a universal standard for all installations. We add malware/security scanning and monitoring of suspicious activity.Logs, incidents, and backups
Logs, alerts, and an incident-response plan + backups with regular restore tests. A backup on its own “guarantees” nothing — the value comes from verified RPO/RTO and isolated copies.A store needs regular auditing just as it needs support. The division of responsibility — who patches, who monitors, who responds to an incident — we record in the maintenance contract, so we do not sort it out live at the critical moment.
Magento cases on Open Source
Three stores we built on Magento Open Source. We quote only the figures a client has agreed to and that have a source; the rest are added as they are approved.
A catalogue with attributes and variations
A store with complex attributes and variations, where the previous platform could not hold the logic of filters and group pricing.
A catalogue on Magento Open Source, custom modules for the pricing logic, filters shaped by demand, payment and delivery integrations.
Snuskingdom — an international snus and nicotine products store we built on Magento 2. The published figure: from 10K visits a month. The case on the site. Detailed figures (catalogue, store views, integrations, before→after with a source) will be added once agreed with the client.
Several markets in one admin panel
Several languages and markets previously run as separate sites, with duplicated content and a catalogue that drifted out of sync.
Store views per market, a shared catalogue core, localisation, hreflang and stock sync through an integration.
Healthygarden.ch — a Swiss store on Magento: a de_DE storefront and local payment methods (Twint, PostFinance, Visa, Mastercard). Figures for an agreed period will be added once the client approves them.
Moving to Magento while keeping the URLs
Migrating the catalogue, customers and orders from another CMS without losing SEO URLs or link equity.
Structure mapping, a 301 redirect map, a delta migration, data reconciliation, a cutover plan and post-launch monitoring.
Snus24.com — another store in the niche on Magento. The scope, timeline and before→after figures will be added once agreed with the client.
We quote only figures confirmed by the client and backed by a source. Where numbers are not yet approved, it is more honest to name the project and the scope than to drop in a textbook example: a case is evidence, not an illustration.
How long it takes and what total cost of ownership consists of
Timelines depend on scope: catalog size, number of store views, depth of integrations, and whether migration is involved, so the stages in the plan are approximate. A Magento solution is evaluated not by development alone — the real total cost of ownership (TCO) includes infrastructure and support.
– Discovery — 1–3 weeks — Business logic, scope, edition, integrations, and the spec — before development starts.
– Turnkey development — per scope — Design, modules, theme, integrations, QA. We fix the timeline after discovery.
– Migration — separate — We calculate data volume, reconciliation, and cutover as a separate block.
| TCO component | What we account for |
|---|---|
| Development and customization | modules, theme, integrations, QA — the starting part of the budget |
| Hosting and infrastructure | servers, cache, queues, search — depending on load |
| Search, cache, queues | OpenSearch, Varnish/Redis, queue services as separate components |
| Paid extensions | licenses for third-party extensions, if they are needed |
| Patches, upgrades, DevOps | supported versions, updates, deployment, and monitoring |
| Support and QA environments | staging, supported SLA, and further development |
Cost of development on Magento Open Source
An approximate range of work. The anchor is Magento Open Source from $5,000: this is a starting point for a limited scope, not a typical enterprise cost. We calculate exact figures per brief after discovery; TCO components (hosting, extension licenses, support) are separate.
A separate stage: to fix the scope, edition, and integrations before development starts.
- Analysis of business logic and catalog
- Choice of edition (Open Source) and project boundaries
- List of integrations and their parameters
- Technical specification and scope estimate
- Migration estimate, if it is needed
Magento Open Source for your catalog and processes. The price is a starting point for a limited scope.
- eCommerce design and prototype
- Catalog, attributes, filters, checkout
- Custom modules for business logic
- Multi-store if needed (store views)
- ERP/CRM, payment, delivery, analytics integrations
- Technical SEO foundation and QA
Transfer to Magento and further maintenance with a clear division of responsibility.
- Migration of catalog, customers, orders
- URL and 301-redirect map
- Data reconciliation and cutover plan
- Patches, upgrades, monitoring
- Supported SLA under contract
The price is for a specific functional scope, not a “package.” $5,000 is the lower bound of a start on Open Source; the final estimate depends on the catalog, store views, integrations, and migration, and we calculate TCO separately from the development cost.
What post-launch maintenance includes
A Magento store needs servicing: patches, updates, monitoring, and response to incidents. We fix the scope and response time in the SLA, and we agree on the areas of responsibility — between the client’s team and us — at the start of maintenance.
Updates and patches
We keep the platform and dependencies on supported versions, apply security patches per the policy, and test them on staging before production.Monitoring and alerts
We watch availability, errors, and performance and respond to alerts. What we monitor and with what priority is defined by the SLA.Incident response
An action plan for a failure or attack with agreed RPO/RTO and verified backups — so that recovery does not depend on improvisation.Further development
New integrations, store views, and features — in sprints, prioritized by impact. Upgrades and refactoring are a normal part of the lifecycle, not an emergency.Frequently asked questions about Magento development
Which Magento edition do you work on?
Which Magento edition do you work on?
On Magento Open Source — custom B2C and mid-market. Enterprise capabilities of Adobe Commerce and B2B (company accounts, shared catalogs, customer-specific pricing) are a different edition with Adobe’s commercial license; we do not sell them as our own service, but we will point out the boundaries at discovery.
How much does Magento store development cost?
Magento Open Source from $5,000 is a starting point for a limited scope, not a typical enterprise cost. The final estimate depends on the catalog, store views, integrations, and migration. Hosting, extension licenses, and support are separate TCO components.
Will Magento withstand a large catalog and peaks?
Scale is determined not by the platform itself but by the architecture: catalog, indexers, OpenSearch, cache/Varnish/CDN, queues, and infrastructure. We design and test the system against an agreed profile of traffic and orders and verify it with load tests — without promises of “millions of SKUs” or automatic scaling.
Do you guarantee traffic and ranking growth after launch?
No. We lay the technical SEO foundation — URL, canonical, managed indexing, metadata templates, markup — but rankings and traffic depend on demand, competition, content, and promotion. These are conditions for growth, not a guarantee of it.
How does migration to Magento work?
Step by step: source audit, structure mapping and a 301-redirect map, data transfer with delta migration, reconciliation before cutover, launch, and indexing monitoring. Customer passwords mostly cannot be transferred directly — we plan an access-recovery scenario.
Who is responsible for the store's security?
It is a shared responsibility. We cover the technical part — supported versions, patches, access, secrets, PCI scope with the provider, logs, and backups with restore tests. The division of “who patches, who monitors, who responds to an incident” we record in the maintenance contract.
What else is useful before the start
Magento development rarely lives on its own — here are adjacent directions worth considering when choosing a platform and after launch.
Turnkey online store development
The parent service with the basic stages of eCommerce development — the Magento direction branches off from it. Read more →Store on OpenCart
A lighter platform for typical catalogs and a quick start, when Magento’s complexity is not needed. Read more →Custom eCommerce on Laravel
For non-standard business logic, when you need your own application rather than a boxed CMS. Read more →eCommerce SEO promotion
Picks up the store’s technical SEO foundation and works on demand, semantics, and content after launch. Read more →Discuss a Magento project
Tell us about the catalog, markets, and integrations you need — at discovery we will agree on the edition, scope, and project boundaries and send a preliminary estimate per brief. We work on Magento Open Source.