Start a project

Magento 2 development

Magento 2 development that is still easy to upgrade in three years

Most Magento problems are not Magento problems. They are the result of code written against the platform rather than with it. Our UK Magento 2 developers build stores, modules and integrations the way the framework intends, so the next upgrade is routine.

Talk to a Magento developerWhat we build

What we build

Magento 2 development, from a single module to a whole store

Some clients need a complete build. Others need one awkward requirement solved properly.

  • New Magento 2 builds

    Catalogue structure, storefront, checkout, hosting setup and integrations, planned together. New builds use a Hyvä front end unless there is a reason not to.

  • Custom module development

    Pricing rules, product configurators, stock logic, admin tools and anything else specific to your business, packaged as self-contained modules.

  • Checkout customisation

    Delivery date selection, extra fields, address lookup, custom totals and payment or shipping method rules, without breaking the checkout on the next release.

  • Integrations

    ERP, PIM, payment, shipping and marketplace connections over REST, GraphQL or message queues, with retries and logging so failures are visible.

  • B2B features

    Customer group and tier pricing, trade accounts, quotes and quick ordering. On Adobe Commerce we configure and extend the B2B module rather than rebuild it.

  • Headless and GraphQL

    API-driven storefronts and mobile apps on Magento’s GraphQL layer, where the case for a separate front end is real.

A quick diagnosis

Signs your current build is holding you back

Merchants rarely come to us because Magento cannot do something. They come because their store has become slow to change, and every release feels like a risk.

If two or more of these sound familiar, the cause is usually in the code rather than the platform. An audit will confirm it.

Ask for a code audit

  • Upgrades keep being postponed

    Nobody will quote for a version upgrade, or the last attempt was abandoned because too much broke.

  • Small changes take a long time

    A new field at checkout or a change to a price rule turns into weeks, because nobody is sure what else it touches.

  • Fixes cause new bugs

    There are no tests and no staging environment that matches production, so every deployment is a gamble.

  • Extensions fight each other

    Dozens of third-party modules rewrite the same classes, and nobody remembers why half of them were installed.

  • Orders or stock go missing

    An integration fails silently on busy days, and your team reconciles the ERP by hand.

Upgrade-safe code

How we keep custom code out of the way of upgrades

Magento provides proper extension points. Using them is what makes an upgrade a routine job rather than a rebuild.

Extension points

  • No edits to Magento core or to third-party modules
  • Plugins and observers to change behaviour, with class preferences as a last resort
  • Dependency injection throughout, no direct use of the object manager
  • Theme changes in a child theme, never in the parent

Data and APIs

  • Service contracts: code depends on Magento’s interfaces, not its internals
  • Declarative schema and data patches for database changes
  • Configuration kept in code so environments match
  • Composer-managed dependencies with pinned versions

Testing and review

  • Every change reviewed by a second developer before it is merged
  • Magento coding standard and static analysis run automatically
  • Unit and integration tests around pricing, tax, checkout and order export
  • Releases tested on staging before production

Headless Magento

Headless and GraphQL: when it is worth it, and when it is not

A headless build separates the storefront from Magento. Magento keeps the catalogue, prices, cart and orders, and a separate front-end application talks to it through the GraphQL API.

That buys freedom on the front end. It also means two applications to build, host, monitor and upgrade, and any extension that adds something to the storefront has to be rebuilt in the new front end, because its templates no longer apply.

It is worth it when

  • The same catalogue and cart must serve a website, a mobile app or in-store screens.
  • You have a front-end team with its own release cycle and the budget to keep it.
  • The storefront is one part of a larger content or application platform.

It is not worth it when

  • The only goal is speed. A Hyvä storefront delivers that with far less to maintain.
  • You rely on many storefront extensions and want them to keep working.
  • One small team has to look after everything.

Integrations

The systems a Magento store has to talk to

An integration is judged on its worst day. We design for the failures first: timeouts, duplicates and a third party that is offline.

Back office
ERP PIM Warehouse management Accounting CRM
Payments
Card gateways Digital wallets Pay later providers 3D Secure Payment on account
Fulfilment
Carrier rates and labels Click and collect Multi-Source Inventory Order tracking
Channels
Marketplaces Product feeds Email platforms Analytics and tag management
How we connect them
REST API GraphQL Message queues Webhooks Scheduled imports and exports

Delivery

From first conversation to documented handover

The same developers stay with the work from scoping to support.

  1. 01

    Discover

    Scope it in writing

    We go through your catalogue, pricing, operations and existing systems, then write down what will be built and what it will cost. Existing stores get a code audit first.

    • Written scope
    • Fixed price
  2. 02

    Build

    Develop in short cycles

    Work goes to a staging site as it is finished, so you test with real products and real orders rather than waiting for a big reveal.

    • Staging site
    • Regular demos
  3. 03

    Verify

    Review and test

    Each change is peer reviewed, checked by automated tests and static analysis, then tested by hand against the scenarios you care about.

    • Reviewed pull requests
    • Test results
  4. 04

    Hand over

    Launch and document

    A rehearsed release with a rollback plan, followed by documentation of every custom module, integration and deployment step. The repository is yours.

    • Launch runbook
    • Technical documentation

Questions

Magento 2 development questions

What does a Magento 2 developer do?

A Magento 2 developer builds and maintains online stores on Magento Open Source and Adobe Commerce. The work covers custom modules, theme and checkout changes, integrations with systems such as ERP and payment providers, version upgrades and bug fixing. Back-end developers work mainly in PHP, and front-end developers in Hyvä or Luma themes.

How much does Magento 2 development cost?

The cost of Magento 2 development depends on the number of integrations, the amount of custom logic, the design work involved and how much data has to be migrated. We do not publish a price list. After a discovery stage we quote a fixed price against a written scope, and ongoing work runs on a monthly retainer.

How long does it take to build a Magento 2 store?

It depends on scope. A store with a standard catalogue and few integrations is a much shorter project than a B2B build connected to an ERP and a warehouse system. The schedule is set during discovery, once the requirements are written down, and we tell you in writing if anything needs to move.

Should we use a Magento extension or have a custom module written?

Use a well-maintained extension when the requirement is common, such as a payment method or a product feed. Have a custom module written when the requirement is specific to your business, or when an extension would bring far more code than the feature needs. Every extension adds upgrade and security work, so fewer is better.

Is headless Magento worth it?

Headless Magento is worth it when one catalogue and cart must serve several front ends, such as a website and a mobile app, or when you have a dedicated front-end team. It is rarely worth it for speed alone. A Hyvä storefront gives fast pages with one application to maintain instead of two.

Can you work on a Magento 2 store another agency built?

Yes. We start with an audit of the custom code, installed extensions, patch level and deployment process, so both sides know the condition of the store. We then agree what to stabilise first. Most inherited builds can be repaired in stages while the store keeps trading.

Related services

Where Magento development usually leads