DEV Community: BrainSpate

I Asked an eCommerce Agency’s Dev Team What They’d Never Do Again

Harper Elise Callahan — Thu, 08 Oct 2026 09:54:29 +0000

Plenty of eCommerce best-practice articles tell store owners what they should do. I wanted to hear the opposite. So I asked an eCommerce agency’s development team a simple question: “What would you never do again when building or rebuilding an online store?”

The answers were surprisingly consistent. Nobody mentioned some obscure coding mistake that only developers would understand. Instead, they talked about decisions that seemed perfectly sensible at the time: customizing everything, choosing a platform before defining requirements, treating mobile as an afterthought, installing too many apps, rebuilding a working store just because the technology felt old, and letting business requirements translate into technical work without enough discussion.

After years of working on eCommerce projects, developers learn these lessons the expensive way.

1. They Would Never Rebuild a Store Without a Clear Business Reason

An experienced eCommerce development agency knows that a store can feel outdated without actually needing a complete rebuild.

Developers see this often. A business owner decides the website needs a complete overhaul because the current design looks dated, competitors have newer-looking websites, or a new platform seems more powerful.

But a rebuild is not automatically an improvement.

A working store already contains years of SEO equity, customer behavior data, integrations, product structures, analytics history, and operational processes. Throwing all of that into a new system creates risk.

The development team would now ask:

What problem are we solving?
Is the problem technical, commercial, or visual?
Can the current platform solve it?
What happens to existing URLs?
Which integrations will need replacing?
What data needs to migrate?
What functionality could disappear during the rebuild?
How will organic traffic be protected?

If nobody can answer those questions clearly, a rebuild probably needs more investigation before development starts.

The lesson: Don't rebuild because a store feels old. Rebuild when the existing architecture genuinely prevents the business from moving forward.

2. They Would Never Choose a Platform Before Defining Requirements

Choosing Shopify, Magento, WooCommerce, BigCommerce, or another platform can become a surprisingly emotional decision.

Teams often start with:

“Which platform is best?”

The better question is:

“What does this store actually need to do?”

A B2C fashion store with a few hundred products has very different requirements from a B2B operation with customer-specific pricing, multiple warehouses, ERP synchronization, complex product configurations, and international tax rules.

The platform should follow the requirements, not the other way around.

An experienced development team will usually want to understand:

Product complexity
Catalog size
Order volume
Customer types
Payment requirements
Shipping rules
ERP or CRM integrations
Inventory management
International markets
Subscription requirements
SEO requirements
Custom checkout needs
Reporting and analytics

Only then does the platform conversation become useful.

The lesson: Don’t fall in love with a platform before understanding the business it has to support.

3. They Would Never Treat Mobile as a Smaller Version of Desktop

This one sounds obvious, but it still causes problems.

Developers have worked on stores where desktop designs were completed first, and mobile was essentially treated as a cleanup task.

That approach creates predictable issues.

A product grid that looks great on a desktop may become difficult to browse on a phone. Filters can become frustrating. Product images can dominate the screen. Checkout fields can become unnecessarily difficult to complete.

Mobile shoppers also interact differently.

They may be:

Searching for a product quickly
Comparing prices
Checking delivery information
Looking for reviews
Returning to a product from an ad
Completing an order with one hand

The development team would rather think about mobile behavior from the beginning than spend weeks fixing a desktop-first implementation later.

The lesson: Mobile isn’t a breakpoint. It’s one of the primary shopping experiences.

4. They Would Never Install an App or Plugin Just Because It Looks Useful

This came up repeatedly.

Apps and plugins are incredibly convenient. Need reviews? Install one. Need popups? Install one. Need analytics? Install one. Need a product filter? There’s probably an app for that too.

The problem appears later.

Each additional dependency can introduce:

JavaScript
CSS
API calls
Database queries
Security considerations
Compatibility issues
Subscription costs
Another vendor to maintain

One app rarely breaks a store.

Twenty or thirty poorly managed dependencies can create a completely different problem.

The development team’s approach is much more selective: install something because the business needs it, not because it looks interesting.

Before adding a third-party tool, they would ask whether the functionality already exists natively, whether it can be implemented more efficiently, and whether the business is prepared to maintain another dependency.

The lesson: Every app becomes part of your technical ecosystem. Treat it like a decision, not a shopping trip.

5. They Would Never Customize the Core Platform Without Thinking About Future Updates

Custom development isn’t inherently bad.

In fact, serious eCommerce businesses often need customization.

The problem is customization without boundaries.

A developer can make almost anything work if given enough time. But the question isn’t just whether something can be built. It’s whether it can still be maintained six months or three years later.

A heavily customized platform can make upgrades more complicated, debugging slower, and future development more expensive.

The team would rather customize where it creates genuine business value and stay close to the platform’s supported architecture everywhere else.

That means asking:

Does this customization create a competitive advantage, or are we rebuilding something the platform already does reasonably well?

That distinction matters.

6. They Would Never Ignore the Existing Data Before a Migration

Migration conversations often focus on products.

Developers think about much more than products.

A store migration can involve:

Product data
Categories
Customer accounts
Orders
Reviews
Images
Redirects
Metadata
URLs
Inventory
Discount codes
Shipping rules
Tax settings
Analytics
Integrations

And then there is the data that doesn’t fit neatly into a migration spreadsheet.

Historical URLs can matter for SEO. Customer records may have dependencies. Old product variants may be connected to orders or reporting systems.

The team would never treat migration as:

Export → import → launch.

A serious migration needs mapping, validation, testing, redirects, and a rollback plan.

The lesson: Migration is not a file-transfer exercise. It’s a business continuity project.

7. They Would Never Leave SEO Until the Store Is Ready to Launch

This is one of the easiest mistakes to make because SEO isn’t always visible during development.

The new homepage looks fantastic. Products work. Checkout works. The team is ready to launch.

Then someone asks:

“Where did our organic traffic go?”

SEO needs to be part of the rebuild from the beginning.

Developers and SEO teams need to coordinate on:

URL structures
Redirects
Canonical tags
Indexation
XML sitemaps
Internal linking
Structured data
Page templates
Metadata
Faceted navigation
Pagination
Site architecture
Core Web Vitals

A redesigned store can technically function perfectly while becoming much harder for search engines to understand.

The team would never want SEO to be a launch-week checklist.

The lesson: If organic search matters to revenue, SEO is part of the architecture.

8. They Would Never Build Features Nobody Has Agreed to Maintain

One developer’s favorite phrase might be:

“Who is going to maintain this?”

A feature can be impressive and still be a bad business decision.

Custom product configurators, complex personalization, unusual checkout flows, advanced recommendation systems, and elaborate integrations can all create value.

But they also create maintenance obligations.

Someone has to:

Monitor them
Fix bugs
Update dependencies
Test them after platform updates.
Train internal teams
Handle edge cases
Support customers when something breaks.

The development team would rather build fewer features that the business can actually support than create a store full of impressive functionality nobody owns.

The lesson: Every feature has a future maintenance cost. Include that cost in the original decision.

9. They Would Never Optimize Only for the Homepage

The homepage gets most of the attention during redesigns.

Developers know that customers don’t necessarily enter through it.

They might land on:

A product page
A category page
A blog article
A Google search result
A campaign landing page
A comparison page
A shared product link

For many eCommerce businesses, product and category pages do far more commercial work than the homepage.

That’s why the team would look at the complete customer journey rather than obsessing over one polished entry point.

A beautiful homepage cannot compensate for confusing product information, weak search, slow checkout, unclear shipping details, or difficult navigation.

The lesson: Design the store around shopping journeys, not screenshots.

10. They Would Never Skip Testing With Real Users and Real Scenarios

A development environment can tell you whether something technically works.

It doesn’t always tell you whether customers understand it.

That’s why real-world scenarios matter.

Instead of asking:

“Does checkout work?”

Test:

“Can a first-time customer find a product, understand the price, select the right variant, check delivery information, add it to the cart, and complete checkout without help?”

Then test unusual situations.

What happens when:

Is a product out of stock?
A coupon doesn’t apply?
Payment fails?
A customer changes their address?
A product has 20 variants?
The cart contains multiple shipping types?
Is an order partially refunded?

The edge cases are where many eCommerce experiences reveal their weaknesses.

11. They Would Never Assume More Technology Means a Better Store

There’s a temptation in eCommerce to keep adding technology.

Headless commerce. Personalization. AI recommendations. Multiple analytics systems. CDPs. Automation platforms. Search engines. Customer-data tools. Custom APIs.

Some businesses genuinely need these things.

Others don’t.

The development team’s philosophy is simpler: technology should reduce friction, not create complexity for its own sake.

If a simpler architecture can produce the same commercial outcome, it may be the better architecture.

That doesn’t mean avoiding advanced technology. It means using it intentionally.

What These Developers Would Do Instead

After hearing all of these answers, a pattern becomes clear.

The biggest mistakes aren’t usually caused by developers who don’t know how to code.

They’re caused by teams making technical decisions without enough business context.

A healthier eCommerce development process looks more like this:

❌ Instead of	✅ Do this
Rebuilding because the store looks old	Identify the actual business problem
Choosing a platform first	Define requirements first
Treating mobile as secondary	Design for mobile from the beginning
Installing dozens of apps	Audit every dependency
Customizing everything	Customize where it creates business value
Treating migration as data transfer	Plan migration as a business-critical project
Adding SEO before launch	Build SEO into the architecture
Building every requested feature	Prioritize features by value and maintenance cost
Optimizing only the homepage	Optimize the complete shopping journey
Testing only happy paths	Test real customers and edge cases

The Real Lesson: Don’t Confuse Change With Progress

The most interesting thing about asking an experienced development team what they would never do again is that many of their answers aren’t really about code.

They’re about restraint.

Knowing when not to rebuild.

Knowing when not to add another app.

Knowing when not to customize.

Knowing when a new feature isn’t worth the maintenance burden.

And knowing when the existing store is actually good enough.

That last point is especially important.

eCommerce businesses can spend enormous amounts of money improving things that customers don’t care about while overlooking problems that directly affect conversion, retention, search visibility, and operations.

A better development process isn’t necessarily about building more.

Sometimes it’s about understanding the existing system well enough to know what should be left alone.

And if an eCommerce agency’s developers have learned anything the expensive way, it’s probably this:

The best store isn’t the one with the most technology. It’s the one where every technical decision has a clear reason behind it.

Frequently Asked Questions

What are the biggest mistakes eCommerce developers see?

The biggest mistakes include unnecessary rebuilds, excessive customization, poor migration planning, ignoring SEO, relying on too many third-party apps, and designing primarily for desktop.

Should every eCommerce business rebuild its website every few years?

No. A rebuild makes sense when the existing platform or architecture prevents the business from meeting important requirements. A store that still performs well may benefit more from targeted improvements than a complete rebuild.

Why is eCommerce migration risky?

Migration can affect products, customers, orders, URLs, SEO, integrations, inventory, and analytics. Poor planning can cause data loss, broken functionality, indexing problems, and revenue disruption.

Is too much customization bad for an eCommerce store?

Not necessarily. Strategic customization can create significant business value. Problems arise when businesses customize core functionality without considering maintenance, upgrades, performance, and long-term development costs.

What should an eCommerce development team prioritize?

A strong team should prioritize business requirements, customer experience, performance, security, SEO, maintainability, integrations, and scalability rather than simply adding more features or technology.

Headless Shopify Architecture: How Does It Actually Work?

Harper Elise Callahan — Fri, 11 Sep 2026 12:59:50 +0000

Most explanations of headless Shopify start with why you'd want it. I'd rather start with what it actually is, mechanically, because I think a lot of the confusion in this space comes from people deciding to go headless before they understand what's still Shopify and what isn't.

Short version: headless Shopify keeps Shopify running the back end, products, inventory, customers, and (almost always) checkout, while you build and host a custom front end that talks to that back end through APIs instead of Shopify's theme engine. The architecture isn't Shopify minus a front end. It's Shopify-plus-a-separate-system-you-now-own.

Here's how the pieces actually fit together.

The core split: what "headless" removes and what it doesn't

In a standard Shopify theme, one system does everything. Shopify renders the page (using Liquid), stores the data, runs the cart logic, and hosts checkout. There's no meaningful separation; you're working inside Shopify's own rendering layer the whole time.

The back end stays on Shopify: product catalog, inventory, customer accounts, order management, and checkout logic.
The front end is something you build separately, commonly with Shopify's own Hydrogen framework, or with Next.js, Nuxt, or another JavaScript framework and host yourself, or through Shopify's Oxygen hosting if you're using Hydrogen.

The key thing to understand is that "headless" refers to what happens to the front end, not a wholesale replacement of Shopify's commerce logic. You're not rebuilding checkout, inventory management, or payment processing from scratch. You're rebuilding the layer the shopper actually sees and clicks through. Headless Shopify development therefore requires planning beyond the storefront itself, particularly around APIs, frontend architecture, integrations, and ongoing maintenance.

The building blocks

A few components do the actual work, and mixing them up is where a lot of confusion starts.

Storefront API. This is the API your custom front end talks to. It exposes what a shopper-facing experience needs: products, collections, the cart, and customer account data through GraphQL. It's built for public, customer-facing use: authentication is lighter-weight than the admin side, and it's designed to be called from a browser or mobile app.

Admin API. This is a separate, more powerful API meant for merchant- and staff-facing tools, with access to order management, inventory adjustments, and shop configuration. It requires proper OAuth authentication and shouldn't be exposed to a customer-facing front end. Keeping these two APIs separate is a deliberate security boundary, not an arbitrary technical split.

Cart and checkout. Your custom front end builds and manages the cart through the Storefront API. When the shopper is ready to pay, the front end hands off to Shopify's checkout rather than collecting payment itself. That handoff matters: it lets you keep Shopify's PCI compliance, fraud protection, and payment infrastructure without having to reimplement any of it. Checkout customization in a headless setup is real but bounded: you're extending Shopify's checkout, not replacing it, and that's true even for larger merchants on more advanced plans.

Hydrogen and Oxygen. Hydrogen is Shopify's own React-based framework for building the custom front end, and Oxygen is Shopify's hosting layer for Hydrogen apps. Using both keeps your headless build inside Shopify's infrastructure. You're not required to use them; a Next.js front end hosted on Vercel that talks to the Storefront API is a legitimate headless architecture too, but Hydrogen and Oxygen are the path Shopify maintains and updates.

How a page request actually flows through the system

It helps to walk through what happens when a shopper loads a product page, because this is where the architecture stops being abstract.

The shopper's browser requests a page from your custom front end (hosted on Oxygen, Vercel, or wherever you've deployed it).
Your front-end code queries the Storefront API for the data that page needs: product details, pricing, images, and variant availability.
Shopify returns that data as structured JSON through GraphQL.
Your front end renders the page using its own components, styling, and layout logic completely independent of Liquid or Shopify's theme templates.
When the shopper adds something to their cart, your front end calls the Storefront API again to update the cart object.
At checkout, your front end redirects the shopper to Shopify's hosted checkout, passing the cart along so pricing, discounts, and line items carry over intact.
Shopify handles payment, fraud checks, tax, and order creation; then the order lands back in the same Shopify admin your team already uses.

Notice how much of this is still Shopify. You've taken over steps one, two, and four, fetching data and rendering it your way. In most implementations, everything downstream of "add to cart" still runs through Shopify's infrastructure.

Where content management fits in

One thing standard Shopify theme setups don't force you to think about: where non-product content lives. In a theme, Shopify handles that mostly through its own page and blog tools, plus metafields for structured extras.

In a headless setup, teams frequently pair Shopify with a separate content management system. Headless APIs let teams deliver content and functionality independently of the frontend, so a separate CMS can work alongside a commerce platform in a decoupled architecture. Contentful's guide to headless APIs explains that this separation lets APIs serve different frontend applications without being tied to a particular presentation layer.

Sanity and Contentful are common choices for content that isn't product data, such as landing pages, editorial, lookbooks, and brand storytelling. Your front end then pulls from two sources: the Storefront API for commerce data, and the CMS for content, and stitches both into the pages it renders. This isn't required; plenty of headless builds keep content in Shopify's metafields and skip a separate CMS entirely, but it's common enough that it's worth planning for explicitly rather than discovering the need mid-build.

The misunderstanding worth clearing up#

The most common misconception I run into is the assumption that headless means the entire experience, including checkout, becomes custom. It doesn't, in the overwhelming majority of implementations. Checkout stays on Shopify's hosted infrastructure because that's where PCI compliance, fraud protection, and payment processing already live, and rebuilding it yourself would mean taking on liability most merchants have no interest in assuming.

If a pitch for a headless build implies you'll have full custom control over checkout itself, double-check what your specific plan actually permits, rather than assuming it by default.

What this means practically for a team building it

Understanding the architecture changes what you should be asking a development team or agency before committing:

Which front-end framework are they proposing, and does that match the skills your team can maintain afterward? A headless implementation requires developers comfortable with frontend, backend, and APIs. Full-stack developer responsibilities cover many of these cross-functional skills.
Are they using Hydrogen/Oxygen or a separate stack like Next.js on their own hosting, and who owns that hosting relationship?
How is checkout being handed off, and what happens to cart data, discounts, and customer identity across that handoff?
Is a separate CMS part of the plan, and if so, who will maintain the content structure long-term?
What's the plan for keeping the front end in sync with Shopify's API changes over time?

These are architecture questions, not vendor-pitch questions, and they're a reasonable thing to ask regardless of who's building it.

Bottom line

Headless Shopify architecture is a front-end swap connected back to Shopify's existing commerce engine through the Storefront API, with checkout still running through Shopify's own infrastructure in nearly every real-world implementation. Once you see it as "keep the engine, replace the dashboard" rather than "rebuild the car," the rest of the decisions which framework, whether to add a separate CMS, how much engineering capacity you actually need get a lot easier to reason about.