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.
Top comments (6)
The SEO point is the one I'd push hardest. Many rebuilds treat redirects as a launch-week task, but by then the new URL structure is already fixed. The safer approach is to export every indexed URL and top landing page before design starts, so the new architecture is built around that list. It's much cheaper to keep a good URL than to redirect it later.
On the "too many apps" point, it helps to measure what each app costs in page speed. A Lighthouse or WebPageTest run with the app on and off often shows a bigger hit than expected, and that makes it easy to decide which ones stay. Curious whether the team has a rule of thumb for how many third-party scripts a store can carry before conversion starts to suffer 🤔
Exporting every indexed URL before design starts is a smart way to put it, and it's easy to skip when the focus is on the new look. On your question, there's no safe number of third-party scripts, since one heavy app can cost more than ten light ones. A better rule is a performance budget. Measure Core Web Vitals with and without each app, and remove anything that costs more speed than it earns in revenue 📉
The "who is going to maintain this?" question deserves to come before the build, not after. A simple way to apply it is to give every custom feature an owner and a review date at kickoff. If nobody can be named, the feature probably shouldn't be built yet. Custom checkout logic and product configurators are the usual offenders, because they break quietly after a platform update and nobody notices until orders drop.
The same idea applies to testing. Beyond edge cases like failed payments and partial refunds, I'd add a post-update checklist that reruns the key purchase flows after every platform or app update. Do you think most teams do this, or does it only happen after the first broken checkout? 🛒
Giving every custom feature an owner and a review date at kickoff is a practical rule, and it would stop a lot of "who built this?" conversations later. To answer your question, most teams only add a post-update checklist after the first broken checkout, so doing it earlier is a real advantage. A short smoke test covering search, add to cart, coupon, and payment after every update catches most of the quiet failures 🛒
Mobile gets treated as a design problem, but a lot of the damage happens in the data. A store can look fine on a phone and still lose orders because of slow image loading, oversized scripts, or a checkout form with too many fields. Testing on a mid-range phone over a slow connection, not just a resized desktop browser, shows problems that a design review misses. It's one of the cheapest checks to run before launch.
The same thinking applies to the "more technology isn't a better store" point. Before adding a new tool, it helps to ask which number it should move, such as conversion, load time, or support tickets. If nobody can name one, it's probably not ready to be added 🛒
Some comments may only be visible to logged-in visitors. Sign in to view all comments.