How to Plan an E-commerce Website Before Development

Most e-commerce projects go wrong long before a developer writes a line of code. They go wrong in a planning meeting where the catalogue is described as "a few hundred products", checkout is described as "standard", and shipping is described as something to sort out with the courier partner later. Six weeks into ecommerce website development, those three assumptions turn into rework: SKUs that cannot hold variants, a checkout that cannot reconcile cash on delivery, and a shipping calculator quoting rates the finance team never approved.

Planning is not a sitemap and a mood board. It is a set of decisions about data, money movement and human effort after launch. Here are the four areas that demand the most upfront rigour, and the order in which to lock them down.

Begin with the catalogue, not the homepage

The catalogue is the schema of your business. It outlives every redesign, every theme change and most agencies. If the model is wrong, every downstream screen is wrong too.

Before development starts, settle these:

• Product versus variant. Decide whether a shirt in five sizes and three colours is one product with fifteen variants or fifteen products. This choice determines URLs, inventory tracking, returns handling and how your warehouse team picks orders.
• Attributes as filters, categories as navigation. Categories should reflect how customers shop; attributes should reflect how they narrow. Mixing the two produces menus that grow forever and filters nobody uses.
• Identifiers and compliance fields. Every SKU needs a stable internal code, an HSN code for GST invoicing, and where relevant a brand, supplier and warranty period. Adding these later means re-touching thousands of records.
• Media specification. Agree image count, aspect ratio, maximum file size, alt-text ownership and whether zoom or video is required. Undefined media rules are the single most common cause of launch delays.
• Data ownership and migration. If you are moving from a marketplace, a spreadsheet or an older platform, map fields explicitly. Ask who is accountable for the product content, and whether bulk import or editing one SKU at a time is the real workflow.

A useful test: can your catalogue model survive a new category, a bundle, a product with no variants, and a product discontinued but still returnable? If any of those break the model, fix it now.

Model the checkout around failure, not the happy path

A checkout that works in a demo is easy. A checkout that behaves correctly when a UPI payment times out, a card is declined after a debit, or a customer abandons the page mid-redirect is the actual engineering problem.

Decisions to lock before development:

• Payment methods. UPI, cards, net banking, wallets, EMI and cash on delivery each carry different fees, settlement cycles and reconciliation effort. List them, then decide who owns the commercial negotiation with the payment gateway.
• Guest checkout. Forcing account creation costs orders and adds password-support load. If accounts are needed for loyalty or subscriptions, make them optional at the first purchase.
• Serviceability before payment. Show delivery estimates and COD eligibility in the cart, not after the payment screen. Discovering that a pin code is unserviceable after paying is the fastest route to a refund request and a chargeback.
• COD rules. Define eligibility by order value, pin code, customer history and product category. Decide whether OTP verification is required and who bears the remittance delay.
• Security and compliance scope. Card-on-file tokenisation, PCI-DSS scope, and redirect versus native payment flows all change the build. Choose the architecture deliberately rather than by default.
• Consent for recovery messaging. Abandoned-cart emails and SMS need consent capture and, in India, registered sender templates. Plan the fields now; retrofit is painful.

Write down what happens in three specific cases: payment succeeds but order creation fails, payment fails but money is debited, and the customer closes the browser mid-payment. Each needs a defined owner, a customer-facing message and a resolution timeframe. This document is worth more than a week of design polish.

Decide shipping and fulfilment rules before the rate card

Shipping is where a well-designed website meets the practicalities of Indian logistics. The website must express business rules that your operations team can actually honour.

• Zones and serviceability. Group pin codes into zones and decide which zones are served, which are prepaid-only, and which carry longer promised timelines.
• Rate logic. Choose between flat rates, weight slabs, free shipping above a threshold, or a live courier quote. Then decide what happens when the calculation disagrees with what was actually charged at the counter.
• Volumetric weight. Bulky, lightweight products are billed on volumetric weight by most carriers. If your catalogue includes them, the calculator must reflect it or margins will quietly disappear.
• Split shipments. Multi-warehouse or made-to-order catalogues produce orders that ship in parts. Decide whether partial shipments are allowed, how the customer is informed, and how shipping is charged.
• Returns and reverse logistics. Define the return window, who pays return freight, which categories are excluded, and how refunds are timed against the return receipt.
• SLAs you can defend. Promised delivery dates should be derived from cut-off times and working days, not optimistic guesses. A missed promise is worse than a longer one.

Get the rate card and the rule set signed off in writing by the people who will run the warehouse. A shipping calculator built on assumptions is a customer-service queue waiting to happen.

Treat operations as a product decision

After launch, someone has to process orders, answer queries, issue credit notes and chase couriers. The website should make that work visible and boring.

• Inventory source of truth. Decide whether inventory lives in the store, an ERP or a warehouse system, and how often it syncs. Overselling is an integration problem, not a marketing one.
• Order lifecycle states. Define the full set of states from placed to delivered to returned, including on-hold and cancelled. Every state needs a trigger, a notification and a report.
• Invoicing and refunds. GST invoices, credit notes and refund timelines should be generated by the system, not assembled manually in a spreadsheet.
• Roles and permissions. Support staff should not be able to edit prices. Build admin roles before you need them.
• Dashboards at launch. Orders per day, payment failure rate, RTO rate, average order value and refund ageing should exist from day one. Metrics added later have no baseline.

Sequence the work and sign off in the right order

A sensible sequence is: discovery and business rules, then data modelling, then wireframes, then integration mapping, then build. Keep a limited-SKU pilot store for a staging environment where the team places real orders, triggers a real return and reconciles a real COD remittance before the full catalogue goes live.

A one-page pre-development checklist

• Catalogue model, variant logic, attributes and media specification agreed and documented.
• Payment methods listed with fees, settlement cycles and gateway owner identified.
• Failure, retry and reconciliation flows written for each payment method.
• Serviceability, shipping rate logic and COD rules approved by operations.
• Return, refund and credit-note policy defined and mapped to system states.
• Inventory source of truth, sync frequency and oversell policy decided.
• Admin roles, launch dashboards and reporting requirements listed.
• Pilot scope and go-live criteria agreed in writing.

None of this is glamorous, and none of it appears in a design review. But ecommerce website development succeeds or fails on whether these decisions were made early, in writing, by the people who will live with them.