Choosing the Right Platform Before Writing Any Code
The platform decision is the first real engineering decision, not a branding one. A single-brand D2C store selling under 2,000 SKUs with standard variant sets is usually better off on Shopify or Shopify Plus - the checkout is locked down, PCI compliance is handled, and app ecosystem covers most edge cases without custom development. A B2B distributor with tiered pricing per customer account, net-30 payment terms, and CSV-based bulk ordering needs WooCommerce on a properly tuned WordPress/MySQL stack, or Magento (Adobe Commerce) if the catalog crosses 20,000 SKUs with complex attribute sets and multi-warehouse inventory. A multi-vendor marketplace with independent vendor payouts, commission splits, and vendor-specific shipping rules almost always needs either a headless build on Next.js with a commerce API (Medusa, Commercetools, or a custom Node.js backend) or a heavily customized Magento/WooCommerce install with a marketplace plugin layer rewritten for the specific payout logic.
We don't default to one stack because it's what we know best. We ask about SKU count, order volume per day, whether tax and shipping rules vary by product category, and how much of the checkout logic is genuinely custom versus configurable through existing extensions. That answer decides the platform before any wireframe gets drawn.
When Headless Commerce Is Worth the Extra Build Time
Headless (decoupled frontend on Next.js or Nuxt, commerce backend via Shopify's Storefront API, Commercetools, or Medusa) makes sense when the storefront needs to be genuinely fast on mobile networks, when the brand runs multiple frontends (web, app, kiosk) off one product catalog, or when marketing wants full control over page layout without fighting theme constraints. It is not worth it for a single storefront doing under 500 orders a month - the added infrastructure and hosting complexity outweighs the performance gain at that volume.
Catalog Architecture: The Part Templates Don't Solve
Most store failures trace back to catalog structure decided too late. Variant explosion (size Γ color Γ material Γ pack-size) needs to be modeled correctly at the attribute level before products are entered, or bulk price updates and inventory sync become manual work every week. We map out:
- Attribute sets and how they map to filterable facets on category pages (Elasticsearch or Algolia indexing for Magento/headless builds where native search isn't enough)
- Whether inventory is single-location, multi-warehouse, or drop-shipped from supplier feeds that need scheduled import jobs
- Bundle and kit logic - whether a "bundle" is a separate SKU with its own stock count or a virtual grouping that decrements component stock
- How product data syncs with an existing ERP (Tally, SAP B1, Zoho Inventory) so the website isn't the source of truth for stock that finance and warehouse teams also touch
Payment Gateway and Tax Logic
Payment integration is rarely just "add Razorpay/Stripe and done." Real implementations have to handle partial refunds, failed payment retries without duplicate order creation, COD-to-prepaid conversion incentives, and gateway-specific webhook reconciliation so an order status in the store always matches the actual transaction state in the payment dashboard. For stores selling across states or countries, tax logic needs product-category-level rules (GST slabs differing by HSN code in India, VAT thresholds in the EU, US sales tax nexus by state) - this is usually handled through a tax engine integration (Avalara, TaxJar, or native GST modules) rather than hardcoded percentages, because hardcoded tax breaks the moment a rule changes.
Shipping rate calculation follows the same principle: weight-based, zone-based, or carrier-API-based (Shiprocket, Delhivery, ShipStation) rates need to be pulled live where order volume justifies the API cost, and estimated/flat-rate tables where it doesn't.
Checkout Reliability Under Load
A checkout flow that works fine at 20 concurrent users can drop orders at 500 - inventory oversell during flash sales, database lock contention on stock decrement, and payment gateway timeouts under load are the three failure modes we specifically test for before a launch or a sale event. This means load-testing checkout with a tool like k6 or Locust against realistic concurrency, adding queue-based stock reservation instead of direct decrement where flash-sale traffic is expected, and setting up gateway timeout handling that doesn't leave a customer's card charged with no order record.
Post-Launch: Conversion Work Is Ongoing, Not a One-Time Audit
What We Actually Track and Change
Conversion optimization on a live store means looking at funnel drop-off by step (cart β shipping info β payment β confirmation) using GA4 or a heatmap tool like Hotjar, and testing specific changes - guest checkout vs. forced account creation, number of steps in checkout, whether shipping cost is shown before or after cart review, payment method ordering. We run these as structured A/B tests where traffic allows, or before/after comparisons with a control period where it doesn't. This is iterative work over months, not a single audit document.
Search and Filter Relevance
For catalogs above a few hundred SKUs, native platform search is often the weakest part of the experience - synonym handling, typo tolerance, and facet performance all need a dedicated search layer (Algolia, Elasticsearch, or Shopify's search & discovery app configured properly) rather than default database search.
Migration Between Platforms
A common project is migrating an existing store - WooCommerce to Shopify Plus as order volume outgrows self-hosted infrastructure, or Magento 1 to Adobe Commerce/headless after end-of-life support forced the decision. Migration work involves mapping product and customer data schemas between platforms, preserving order history and SEO URL structure (301 redirect mapping at scale, not spot fixes), and running the new store in parallel against a copy of live traffic before cutover to catch data mismatches before customers see them.
What You Get as Deliverables
- Platform recommendation with the reasoning documented, not just a build
- Catalog and attribute schema, inventory sync method, and ERP integration points where relevant
- Payment gateway and tax engine integration with webhook reconciliation logic
- Shipping rate integration (API-based or table-based, matched to order volume)
- Load-tested checkout flow with documented concurrency thresholds
- Analytics and funnel tracking setup (GA4 events mapped to checkout steps)
- A defined post-launch optimization schedule rather than a handover-and-disappear model
