Skip to content
Zapolu

Magento 2 / Mage-OS / Adobe Commerce

Enterprise commerce for complex catalogs, B2B, and multi-store, on Mage-OS and Adobe Commerce.

Magento powers some of the largest e-commerce operations on the web, and it has earned a reputation for operational complexity along the way. Run well, it is still the most capable open platform for complex catalogs and B2B. Run badly, it produces 12-second product pages and hosting costs nobody can explain. Most of our Magento engagements start with a shop in the second state.

We work with both live branches of the platform:

  • Mage-OS: the community-led fork that decouples the platform’s future from Adobe’s roadmap and releases faster. New open-source builds go here rather than to stock Magento Open Source; most of the community’s release activity has moved to the fork.
  • Adobe Commerce: the licensed cloud edition with the B2B suite, page builder, and enterprise SLAs.

The work is led by an architect holding Adobe Certified Master – Adobe Commerce Architect, the highest certification Adobe issues for Commerce, plus a Hyvä developer certification on the storefront side. Both are verifiable on LinkedIn.

When Magento is the right choice

  • Complex catalogs with many product types, configurable options, and pricing rules
  • B2B requirements: company accounts, quote workflows, tiered pricing, purchase approvals
  • Multi-store and multi-brand setups under one admin
  • An existing investment in Adobe Commerce extensions and integrations

If none of these apply, Shopify is usually the cheaper answer, and we will say so on the first call.

Problems we are asked to resolve

  • Product pages that take three seconds although Varnish and Redis are “already configured”
  • Checkout that fails under campaign load while the servers sit at 10% utilization
  • Forty installed extensions, half abandoned by their vendors, two of them conflicting over the same observer
  • Indexers and crons in a state where the storefront shows stock the warehouse doesn’t have
  • An upgrade postponed so long that every security patch has become a project of its own

Problems we have fixed

From stores we’ve worked on over the years, anonymized:

  • Customer registration failed over a weekend because one extension’s table had exhausted all 4.29 billion auto-increment IDs while holding half a million rows. A BIGINT hotfix restored signups within the hour; a schema override made the fix survive upgrades.
  • Cash-on-delivery orders began requiring card payment after an upgrade: the schema migration had rebuilt a table and shifted the row IDs a legacy module used as hardcoded constants. Found by comparing the raw tables across environments.
  • Salable stock drifted below reality for months. A marketplace connector renamed order increments after placing inventory reservations, so MSI could never release them. Proven with anti-joins on the reservation metadata, fixed with a vendor patch and a cleanup cron.
  • Addresses stopped matching in the ERP because Magento’s CSV-injection guard silently prepends a space to any value starting with ”+”, which includes phone numbers. Traced into framework internals, fixed with a composer patch.
  • Media uploads worked on staging and failed on production. A hypothesis-elimination pass pinned it to a single stale configuration row, and a self-healing data patch made sure it can’t come back.

What we do

  • Performance audits and storefront rebuilds. Our default recommendation is Hyvä: it replaces the legacy frontend stack entirely and typically brings Lighthouse scores into the 90s. PWA Studio or fully headless where the case calls for it.
  • Custom modules and integrations for ERP, PIM, fulfillment, payments, and marketplaces, built idempotent and observable, because the integration layer is where Magento shops break most often.
  • Version upgrades, including overdue Magento 1 to 2 migrations, Mage-OS migrations, and reducing the risk of major-version upgrades with a full extension audit before anything is touched.
  • Long-term operational support: security patches, monitoring, cache tuning, and the on-call engineer for the day the database lock table fills up. It runs as a monthly retainer, with DevOps & infrastructure underneath.

How an engagement usually starts

For a live shop, the performance audit is the natural entry: a fixed price, real measurements, and a prioritized fix list your own team can execute. For a shop still on Magento 1 or several major versions behind, we start with a migration assessment instead: what carries over, what gets rewritten, and what the cutover plan looks like. Either way, you know the scope and the price in writing before anything is billed.

Related services