This is the opener in a short series on what it actually took to build and run a real e-commerce store — the same “practice what we sell” approach we’ve used for our own site’s technical SEO. Nothing here is hypothetical.

Why we built a store before we sold e-commerce consulting

Most of what gets marketed as “e-commerce expertise” is theory — a services page describing what an agency would do, never what it has done. We decided the more honest and more useful path was to build a real store first, run into the real problems a small store owner actually hits, and fix them ourselves before offering to fix them for anyone else.

That store is Wrenfield Apparel Co., a Shopify dropshipping store sourcing women’s and men’s apparel and accessories through two suppliers. This post is a plain account of what building it actually involved.

The purchasability bug nobody checks for

Early on, products looked fine in the admin — marked available, priced, in stock — but a real “Add to cart” click failed. That gap between what the API reports and what a buyer actually experiences is easy to miss if you only check dashboards. We traced it to three separate, compounding causes: an inventory policy that blocked sales once stock hit zero, a shipping location that had never been attached to a delivery profile (so Shopify had no rate to quote), and product variants with no recorded weight (so a carrier-rate lookup had nothing to calculate from). Each one alone would have caused the same symptom. All three had to be found and fixed before checkout actually worked — and we verified it with a real cart-to-checkout test, not just a clean API response.

Marketplace sync has its own failure modes

Listing a catalog on eBay and Google Shopping surfaced a second class of problem: silent rejections. The root cause on the eBay side was a missing product-taxonomy field — Shopify’s own Standard Product Category — required for the marketplace connector to map a product into eBay’s category system. On the Google Merchant Center side, the same missing field caused the same rejection pattern for a different reason. Neither showed up as an obvious error message; both required directly querying the catalog data to find.

Catalog governance, done mechanically on purpose

With products sourced from more than one supplier, category and data-quality drift happens fast. We built categorization rules that are deliberately mechanical — a documented, narrow ruleset that never invents a new category or makes a judgment call on ambiguous products. When the rules don’t have a confident answer, the product gets flagged for a human, not guessed at. The same discipline applies to duplicate-listing detection: real duplicates get merged or removed, near-matches get flagged, nothing gets silently deleted.

SEO architecture and a real brand-attribution bug

Beyond standard on-page SEO, an AI-search readiness audit found something specific: the store’s structured data was attributing every product to the supplier’s brand name, not the store’s — because the underlying “Vendor” field had never been changed from the supplier’s default. Left alone, that meant AI engines reading the store’s own schema would credit the wrong brand. We traced it, then corrected it across the full catalog.

Pricing and promotion, with a margin floor first

Every pricing and discount decision runs through a margin floor before anything else — no promotion gets built that would sell below a set profitability line, and “creating” a discount code is treated as a distinct step from “activating” it, so nothing goes live on a timeline nobody actually chose.

What this store hasn’t proven yet

In the interest of being direct: this store is still early, and we’re not going to dress that up. The operational work above is real, checkable, and done. A sales-results chapter isn’t written yet. We’ll say so plainly when it is, the same way we’re saying so plainly now that it isn’t.

Read more about this build in our case study, or see how we approach store operations and automation more generally.