Magento

Headless suits a store whose front end changes faster than its commerce logic, or must share components with a wider web estate: a React storefront against Magento's GraphQL API separates those release cycles. It costs a second application to build and run, and it forfeits part of the extension ecosystem, because storefront-facing modules no longer render anything.

Theme-based storefronts remain viable where that separation is not needed. The deciding question is whether the storefront and the commerce logic release at different speeds.

Adobe patches Adobe Commerce and Magento Open Source on a quarterly release cadence, and a store with modified core files cannot take those patches cleanly. Customisation survives patching when it lives in modules built on plugins, observers and dependency injection, with Composer managing any unavoidable core patches as explicit, reviewable files.

An upgrade audit before each patch cycle is cheaper than a stalled deployment after it. Third-party extensions are the usual blocker, so their compatibility is checked first.

Mixed, for a reason specific to Magento: the public corpus is split between Magento 1 and Magento 2, whose architectures differ completely, so coding agents regularly propose patterns from the wrong generation. Magento 2's convention-heavy structure of XML configuration, dependency injection and interceptors also has thinner public code than the plain PHP underneath it.

The seams work well. GraphQL and REST integration code and headless React storefronts sit in dense, well-documented territory where agents perform strongly, so AI-assisted work concentrates there while module internals stay on reviewed, test-backed changes.

Either as a fixed cost for an initial outcome, such as a first release or a defined migration, or as a monthly rate for the team once later phases are under way. We do not publish a figure for a build, because the scale is set by the number of features, platforms, user groups and users, and projects have run from four weeks to several months. The How We Charge page sets out both models, milestone billing and the notice period.

Typically one full-time engineer on the build, with two part-time roles alongside: one running the project and one working with you on priorities and technical decisions. Teams are shaped around the system rather than around one technology, so Magento work draws in the neighbouring stack when it needs to. Delivery starts under Australian leadership, with the engineering in our Manila delivery centre.

A delivery plan reaches you within 48 hours of the first call, and a build typically starts in week two. Where the work is an enhancement to an application another team built, we audit the application first, so the plan is costed against what is actually there.