Magento Development: What the Process Should Actually Look Like End to End

Most Magento 2 and Adobe Commerce projects do not become expensive because Magento suddenly misbehaves. They become expensive because someone waved discovery through, left ERP integration logic half-defined, treated frontend architecture as a preference to settle later, and pushed risk into build and UAT where it costs three times as much to fix.

The short answer: A rigorous Magento 2 development process moves through five defined stages – discovery, architecture, build, QA and UAT, and launch with handoff. Each stage requires clear inputs, named owners, documented outputs, and a sign-off point before the next begins. Most cost overruns, missed timelines and post-launch instability trace back to discovery that skipped hard integration questions, or an architecture phase compressed to hit a proposal deadline.

I have been through this with enough Magento 2 and Adobe Commerce builds to know that a supplier who cannot show you those stage outputs before you sign is not running a process. They are running a hope. This guide is for eCommerce leads, operations teams, B2B stakeholders and buyers shortlisting a Magento development agency or Adobe Commerce supplier who need a clearer way to judge process quality before scope, proposals and timelines start to blur together.

Discovery should narrow risk, not collect vague requirements

A weak discovery phase often looks busy while leaving the hard questions untouched. You get workshops, notes and a quote. Nobody has settled where pricing rules live, how the ERP will talk to Magento 2, which customer group logic governs B2B account access, or which edge cases in the order workflow will surface three months into build. I have watched entire sprints get lost because a discovery phase treated ERP field mapping as something to “align on later.”

Before architecture starts, ownership must be clear. Someone on the client side needs to sign off requirements and hold authority over backlog trade-offs. The supplier should document scope boundaries, critical user journeys, customer group logic, extension needs, data ownership and the likely frontend direction – not as a broad statement of intent but as a document with named decisions and open questions explicitly flagged.

Discovery should answer specific questions, not vague ones:

• Ask for outputs, not activity: what gets signed off at the end of discovery, and what decisions remain open going into architecture? If the answer is a summary slide deck, that is not a discovery output.
• Check dependency mapping: ERP, PIM, payment gateway, shipping carrier and tax engine should all be mapped before build – including which data owner lives on which side of the integration and what happens when the connection fails.
• Push on B2B logic: pricing tiers, approval workflows, company account hierarchies and role-based permissions need documenting early. These are the rules that consistently break in staging when nobody pinned them down in discovery.
• Watch proposal quality: if two suppliers scoped different assumptions, the quotes are not really comparable. The gap is not cost – it is unresolved scope dressed up as a price difference.

That last point matters more than most buyers expect. Two proposals that look dramatically different on cost often reflect two different versions of the same project, not two different price points. If you want a sharper view of what discovery should actually produce before build begins, see what a proper discovery workshop should produce before build starts.

Architecture is where Magento projects become stable or expensive

This is where long-tail cost gets decided. If architecture is compressed into a few slides and a rough component diagram, technical debt follows – and in my experience, the teams that compress architecture are usually the ones with the most confident initial proposal. You should expect a clear approach to extension selection and compatibility review, custom logic boundaries, Magento Cloud versus self-hosted infrastructure decisions, deployment pipeline design, Elasticsearch index configuration, Varnish cache rules, Redis session versus full-page cache separation, and integration design that names systems, owners and failure modes.

If a supplier cannot explain why a specific extension is safe to use, how it behaves with the other modules already in scope, what patching that extension means in twelve months, or how a conflict with a Magento 2 core override would be handled – that is not a minor gap. That is a structural risk to the build.

Performance belongs in architecture, not in testing. Core Web Vitals targets should be agreed here, with named ownership, a measurement method and realistic load conditions. The question that matters more than which caching layer is used is whether the team designed around performance from the start or grafted it on when the client noticed a slow page speed score. If you want a clearer view of what actually matters in Core Web Vitals for eCommerce, that is worth reviewing before architecture sign-off.

Hyva, PWA Studio or standard Luma: this is an architecture decision, not a late preference

Do not let the frontend direction drift into build. I have watched more than a few Magento 2 projects where the frontend choice was left implicit until development was three weeks in, at which point the extension compatibility assumptions, the theme override structure and the GraphQL API surface all had to be revisited at cost.

Hyva removes the RequireJS and KnockoutJS stack from Magento 2’s standard frontend and replaces it with Alpine.js and Tailwind CSS. That can simplify the theme layer and improve Core Web Vitals scores meaningfully – but it also changes how third-party extensions behave. Extensions built for the standard Luma theme do not automatically work with Hyva. Some have no Hyva-compatible version at all. The compatibility check is a piece of real work, not a five-minute review, and it needs to happen before architecture is signed off.

PWA Studio with a GraphQL-driven frontend is the right direction for teams that need full headless behaviour – decoupled storefront, API-first rendering, maximum flexibility in frontend tooling. The trade-off is a more complex delivery, more demanding frontend engineering, and a support model that requires clear ownership of both the PWA layer and the Magento 2 backend. GraphQL schema extensions for custom business logic need their own design decisions, and that scope is rarely priced correctly in early proposals.

The standard Luma frontend may still suit some Adobe Commerce estates, particularly where existing module behaviour, internal familiarity or a constrained upgrade path makes a full frontend rebuild harder to justify. The choice has to be made deliberately, with its implications for extension compatibility, deployment and team capability documented before architecture sign-off. If you are weighing that trade-off, choosing the right front-end framework for the build adds useful context.

Not sure if your Magento scope is actually ready for build?

Most projects go wrong because discovery was rushed or architecture was skipped. We can review your current scope, flag the gaps that usually cause delays, and help you decide what needs pinning down before you commit budget.

Review your scope

No obligation. Just a clearer view of what is missing.

A credible build phase has stage gates, not a long period of silence

Once scope and architecture are signed off, build should move in controlled slices. You should see weekly progress reports, clear milestone reviews and a live view of what is complete, blocked or waiting on your team. If you are only hearing from the delivery team when they need something from you, that is not a process. That is managed silence.

Sequence matters and most delivery timelines underestimate it. Extension work, custom logic, ERP integration and frontend implementation should be planned around their dependencies – not run in parallel because the Gantt chart looks tidy. Storefront work often looks faster because it is visible. Integration work reliably takes longer because its failure modes live in stock reconciliation rules, order state transitions, retry logic on failed API calls, and data ownership disputes that only surface when real data hits the connector. Those failure modes are almost never what the original estimate was based on.

Magento delivery flow: phases, inputs, outputs and typical duration ranges

Those ranges move with scope, integration depth, data quality and how quickly your side can make decisions. A supplier should be able to explain that plainly – not wave at a broad estimate and hope the dependencies untangle themselves in build.

Testing should expose edge cases before launch does

Testing is not one bucket called QA. Technical QA sits with the delivery team and focuses on code quality, extension compatibility and integration behaviour. UAT sits with business stakeholders who know what the pricing rules, order workflows and B2B permissions are actually supposed to do. Launch readiness is a separate decision covering operational ownership, rollback sequencing and monitoring configuration. Collapsing these three into a single QA phase is one of the more reliable ways to discover a problem in production.

You should ask specifically how extension compatibility will be validated against the Magento 2 core version in production, how checkout paths will be tested across customer types and price groups, and how B2B behaviours – role-based access, company account approval flows, tiered pricing – will be validated against the rules that were defined in discovery.

The most consistent testing failure I have seen in Adobe Commerce builds is pricing that works in staging and breaks in production. The reason is almost always the same: staging uses simplified test data, whereas production carries real customer groups, live ERP-fed prices, layered discount rules and a populated Elasticsearch index. When all of those interact – particularly under a promotion or during a B2B account switch – the price calculation logic exposes assumptions that a controlled staging environment never surfaces. That is the kind of failure that does not get caught by a QA team running scripted tests against a clean dataset.

Performance and security need named owners before launch, not after. You should know what traffic and load assumptions were tested under, how Core Web Vitals were measured and in what conditions, who holds the Magento 2 or Adobe Commerce security patch schedule, and who owns the rollback decision if a production deployment fails.

If patching responsibility, rollback authority and monitoring ownership are not agreed before launch, the project is not ready. It is simply close to deployment.

The handoff is part of delivery, not admin after the real work

I say this plainly because it is still routinely treated as optional: a Magento 2 project is not finished at go-live. The decisions made during build – why a specific extension was chosen over an alternative, where a theme override sits in the directory structure, how a custom module hooks into the checkout event, what the deployment pipeline assumes about environment variables, how the Elasticsearch index was configured and why – all of that needs to be documented and handed over in a form an internal team or future agency can actually use.

Without it, what typically happens is this: the site launches cleanly, the delivery team moves to the next project, and within four to six weeks the internal team is chasing the previous supplier for context on an urgent fix. They find that the deployment notes cover what the pipeline does but not why three steps are in that order. They discover that the Varnish configuration was set up correctly but nobody wrote down what the cache-clearing logic assumes. They realise that the Redis session configuration was split from full-page cache, but there is no note explaining why that split was made or what would break if it were collapsed. In my experience, this is not a minor inconvenience – it is where small production issues become expensive ones.

A proper handoff should cover: named deployment ownership and release decision authority, documented module decisions with rationale not just configuration, override logs that explain why core behaviour was modified rather than extended, a monitoring setup with agreed alert thresholds rather than a raw dashboard no one is actively watching, patching responsibility assigned to a named team or support partner, and clear support scope so the internal team knows what they are expected to handle independently.

The documentation requirements differ between Magento Cloud and self-hosted deployments. On Magento Cloud, the supplier should hand over environment configuration, deploy hooks, Fastly CDN setup and the B2B extension configuration – not just production access credentials. On self-hosted Magento 2, the scope is broader: infrastructure provisioning, backup procedures, Varnish VCL customisation and the upgrade path to the next minor version all need to be explicitly covered.

Magento 2 and Adobe Commerce estates keep changing. A store that launches cleanly can become expensive to maintain within a year if post-launch ownership is ambiguous. If you are planning the ongoing maintenance model alongside delivery, ongoing & structured eCommerce maintenance service is worth building into scope before go-live rather than sourcing reactively after the first production incident.

Red flags that tell you a supplier is skipping the hard parts

Some warning signs emerge early if you ask specific questions rather than “how long will it take?” This is where process theatre starts to crack.

The most consistent red flag is not any single answer – it is a pattern of vague answers to precise questions. A supplier who has genuinely run this process before will have outputs to show you, names to put against decisions, and a clear position on the choices that change scope. A supplier running a vague process will deflect with confidence and use the phrase “we can align on that in build” more than once. I have heard that sentence enough times to treat it as a scope warning.

Ask these specifically:

• No early integration mapping: ask how ERP, stock, pricing and order flows are documented before build starts. A credible answer names systems, owners, data contracts and failure points. A weak answer talks about “alignment” and deferred workshops.
• No clear frontend position: ask what drives the choice between Hyva, Luma and PWA Studio, what it changes in extension scope and compatibility, and whether a GraphQL API layer is in scope. A weak answer sounds like “we can decide once we start.”
• Vague performance claims: ask which Core Web Vitals targets are agreed, how they will be measured and under what traffic conditions. Ask whether Elasticsearch index configuration and Varnish cache rules are part of the architecture output.
• Weak extension review: ask how compatibility between third-party extensions, the Magento 2 core version and any existing custom modules is assessed before extensions are approved. Ask who owns the patching decision if a compatibility conflict emerges post-launch.
• No named patching owner: ask who handles Adobe Commerce security releases, who owns the Magento Cloud or hosting environment, and who is authorised to trigger rollback in a production incident.
• Lots of meetings, few outputs: ask what gets signed off at the end of each phase and what the sign-off document looks like. If the answer is “we review and confirm direction together,” that is not a sign-off gate. That is a meeting.

If a supplier can answer those questions with specifics, you are probably looking at a real delivery process. If not, you are looking at hidden scope and long-tail cost dressed up as confidence.

If your Magento 2 project sits inside a wider platform move, a rigorous eCommerce replatforming process from discovery to hypercare is worth reviewing before you shortlist. If you are ready to have a direct conversation about what the process should look like for your specific Adobe Commerce setup – before assumptions harden into a signed proposal – that is the right time to ask.