Planning an E-commerce Website Before Development: Catalogs, Checkout, Shipping and Operations

Why planning decides the outcome of ecommerce website development

Most e-commerce builds fail quietly, long before code is written. A team picks a platform, installs a theme, and only then discovers that its catalog does not fit the default data model, that its discount rules cannot be expressed in the available cart logic, or that the warehouse has no clean way to decide which order ships in which box. Rebuilding after launch costs several times more than deciding upfront, because by then real orders, real inventory and real customer expectations are attached to the broken assumption.

A pre-development plan is not a design document. It is a set of written decisions, owned by the people who run merchandising, finance and fulfilment, that the build can be measured against.

Catalog: treat the data model as the product

Before comparing platforms, define what a product actually is in your business. Write down the answers to these questions and test them against your ten best-selling and ten most awkward items — the ones with sizes, bundles, expiry dates or custom stitching.

• Product versus variant versus SKU. Which level holds price, stock and images? A shirt with six sizes and three colours could be 1 product, 3 products or 18 SKUs depending on how you sell and stock it.
• Attributes and filters. List the attributes customers will filter by, and confirm each one is a controlled vocabulary rather than free text. Inconsistent size labels destroy filter quality.
• Category versus collection. Categories are usually a stable hierarchy for navigation and SEO. Collections are merchandising groupings such as "Festive Edit" or "Under ₹999" that change monthly. Mixing the two creates messy URLs and broken breadcrumbs.
• Pricing and tax data. Record MRP, selling price, and the GST rate and HSN code per item. Tax treatment varies by product category and by your registration, so get finance to confirm the mapping rather than letting a developer guess.
• Media standards. Fix aspect ratios, image counts and naming conventions early; retrofitting thousands of inconsistent images is slow and expensive.

Checkout: design around failure, not just the happy path

Checkout is where revenue is lost, and the losses are usually administrative rather than technical. Map the full flow as a sequence of states, then list what happens when each step fails.

• Guest and account flows. Decide whether account creation is optional, when it is prompted, and how password resets work.
• Address handling. Pincode entry, serviceability checks and address validation should happen before payment, not after.
• Payment methods. Card, UPI, netbanking, wallets, EMI and cash on delivery each carry different eligibility rules, limits and reconciliation needs. Confirm which you will actually support at launch.
• Failure states. Define behaviour for payment timeouts, failed authorisations, duplicate submissions and abandoned carts. A payment that succeeds at the gateway but fails on your site is the most damaging scenario, so specify how it is detected and resolved.
• Price transparency. Shipping charges, COD fees and taxes should appear before the final step. Surprise costs at payment are a leading cause of drop-off.
• Discount logic. Write the actual rules — coupons, automatic cart discounts, tiered thresholds, first-order-only offers — and check the platform can express them without custom plugins for every campaign.

Shipping and delivery promises

Shipping rules live in the gap between marketing and operations, which is why they are so often left vague. Pin them down in writing.

• Serviceability. Which pincodes do you serve, and is that a static list, a courier API, or a manual rule per zone?
• Rate calculation. Flat rate, weight slabs, zone-based or free above a threshold. Decide whether rates are calculated at cart or at checkout after the address is known.
• Split shipments. If an order contains items from different warehouses, does it ship together or separately? This directly affects shipping charges, packaging and customer communication.
• Promise versus reality. Display estimated delivery windows you can consistently meet. An optimistic estimate creates more support tickets than a conservative one.
• Returns and reverse logistics. Who pays return shipping, what is the return window, and how is a pickup scheduled? Reverse flows need their own states in the order system.

Operations: the work that happens after the order

This is the section most planning documents omit entirely, and the one that determines whether the store is manageable at volume.

• Inventory model. Single warehouse or multiple locations? Is stock reserved at cart, at payment, or at fulfilment? Overselling is an inventory-state problem, not a website problem.
• Order state machine. List every status from placed to delivered, cancelled, returned and refunded, and who can move an order between them.
• Invoicing and compliance. GST invoices, credit notes for returns, and records needed for reconciliation should be generated by the system, not assembled manually each month.
• Payment reconciliation. Match gateway settlements against orders; decide who reviews mismatches and how often.
• Notifications. Order confirmation, dispatch, delivery and refund messages, plus the templates customers actually read.
• Roles and access. Who can edit prices, issue refunds, or export customer data? Build these permissions into the plan rather than granting admin to everyone.

Non-functional requirements and integrations

Alongside the business rules, note the constraints: mobile-first layouts, page-load budgets for catalog pages with large image sets, URL and pagination structure for search engines, accessibility of forms and error messages, and a defined analytics event list so launch data is comparable to later data. Then list every system the site must talk to — ERP, warehouse management, accounting, CRM, courier aggregators, helpdesk — and note which direction data flows and how often.

A practical sign-off checklist

Before development begins, the plan should contain: a catalog schema with sample data; a documented checkout flow including failure states; written shipping, COD and returns policies in rule form; an order state diagram; a list of integrations with owners; a launch scope with explicit exclusions; and named decision-makers for each area. If a section is blank, that is a decision you are deferring to a developer who does not own the consequence.

Common planning mistakes

Three recur. First, planning the storefront while ignoring the back office, which produces a beautiful site nobody can operate. Second, treating the catalog as content rather than structured data, which caps how the site can be filtered, merchandised or migrated later. Third, planning for launch day instead of month twelve — no thought given to campaign calendars, seasonal traffic, catalog growth or staff turnover. A good plan is one that a new operations hire could read and run the store from.