Every e-commerce spec arrives with thirty features. Here are seven that almost always belong on the cutting room floor — and why cutting them ships better software, faster, with less debt.
This isn't about saying no to clients. It's about saying yes to the right things at the right time. The features below aren't bad ideas — most of them are great in year three. They're bad scope items in version one, where they steal budget from things that actually matter (the catalog, the checkout, the inventory truth).
1. AI personalization on day one
"We want personalized recommendations based on browsing behaviour" appears in 80% of specs. In version one, you have ten products, no purchase history, and no behaviour data. Personalization needs data; you don't have any.
What we ship instead: "people who bought this also bought" using simple co-occurrence statistics, computed weekly. It's 5% of the engineering effort and delivers 80% of the value. When you have a year of purchase data, revisit personalization.
2. The custom recommendation engine
Adjacent to #1: "we want our own recommendation engine, not Algolia/Klevu/whatever." This is almost always a mistake. Recommendation engines are a deep specialty. The vendors have been working on them for a decade with budgets you don't have.
Pay €500-2000/month for one of the boring options. Differentiate on the things customers actually notice — speed of search, relevance, freshness, mobile experience. Your custom recommender will be worse and a constant maintenance burden.
3. Blog, magazine, and content hub integrated into the storefront
"We want a content section integrated tightly with our products." A common request, almost always wrong. The content team and the product team move at different speeds. They have different review processes. They should not share a release cycle.
What we ship: WordPress, Ghost, or a headless CMS, on a subdomain or sub-path, with light cross-linking to product pages. Editors get their tools, engineers don't get pulled into copy approval workflows.
4. Live multi-currency conversion at checkout
"We want to display prices in the customer's local currency, dynamically converted from EUR." Mathematically simple, operationally a nightmare:
- Conversion rates fluctuate, so a customer sees one price on the product page and a slightly different total at checkout. Support tickets follow.
- Tax calculation by country needs the local price as input.
- Refunds in the original currency may not match the original payment due to FX drift.
What we ship: support 2-3 explicit currencies (EUR, plus your top non-EUR markets), each with locked prices reviewed quarterly. The customer's currency is determined by storefront, not by IP. Less elegant, dramatically less expensive.
5. The custom A/B testing framework
"We want to run experiments." Excellent instinct. "We want to build our own experimentation platform." Almost never the right call. A/B testing platforms are commodity.
Use Google Optimize's successor (GA4 + a third-party tool), VWO, Statsig, or PostHog. Spend the engineering budget on the variants you'll actually test, not on the framework that runs them.
6. The "social shopping" features
Reviews on product pages: yes, build this on day one. Wishlists: maybe, depends on category. Social feeds, "follow other shoppers," gift hub features, photo galleries from customers — these are year-three features at best. Most never reach product-market fit because the storefront isn't a social network.
If your category genuinely needs social proof (fashion, beauty), use a vendor product like Yotpo or Bazaarvoice. Don't build.
7. The chatbot
The chatbot is the most consistent feature creep in e-commerce specs. The use case is usually fuzzy ("answer customer questions"). The implementation costs are predictable: integration, knowledge base maintenance, escalation flows, and a chatbot that confidently gives wrong answers.
What we ship: a clear FAQ page, a shipping/returns page, and a contact form with a 24-hour response promise. If chat genuinely matters for your business, use Intercom or a similar vendor and put it behind a "Need help?" button rather than a permanent overlay.
What to keep instead
Cutting these seven frees budget for the things that actually drive conversion in year one:
- Product detail pages that load in under 2 seconds and look right on mobile.
- Search that handles typos, synonyms, and price filters reasonably.
- Inventory truth — the price and stock you show match the warehouse, always.
- Checkout that works on a phone, supports the payment methods your customers actually use, and recovers from errors gracefully.
- Order management for your operations team. Customer service tickets multiply when ops can't see what's happening.
- Email transactional flows (order confirmation, shipping update, return) that are clear and on-brand.
None of these are exciting. All of them are what customers and operations actually need.
What you can take from this
When a stakeholder says "and we also want X," ask: "what does this replace from the version one scope?" If they can't answer, it's a cut. Build the boring fundamentals well first. The interesting features are easier in year two when you have data, traffic, and a working storefront to extend.
If you're scoping an e-commerce build right now and want a second opinion on the spec, that's exactly the kind of conversation we have in our discovery sessions. Tell us about it.