E-commerce Development

Model the catalogue before you design anything

Almost every e-commerce project that goes badly went wrong here. A product is not a single thing — it is a product with variants, and how you model variants determines whether the store can express your business.

The questions to answer before design starts: does stock live on the product or on each variant? Can price differ per variant, and per customer? Do variants have their own images, weights and barcodes? Do you sell by weight or length rather than by unit? Do bundles exist, and does buying a bundle decrement the stock of its components? Are some products made to order with no stock at all? Do you need different prices per branch or per region?

If several of those answers are unusual, that is a strong signal about platform choice. Hosted platforms handle conventional variants beautifully and fight you on anything else, which is the practical test in our Shopify vs WooCommerce vs custom comparison.

Payments in Pakistan: plan for mixed methods

Local commerce does not look like the tutorials. A realistic store here supports several payment paths at once, and each has consequences well beyond the checkout screen:

• Cash on delivery. Still a large share of orders in this market. It changes everything downstream: you need a confirmation step to filter fake orders, a courier that remits collected cash, reconciliation between what was collected and what was received, and a returns rate that is meaningfully higher than for prepaid orders.
• Local wallets and bank gateways. Fees, settlement timing and refund mechanics differ between providers, and refunds are frequently the weakest part of the integration — test a full refund before launch, not after your first complaint.
• Cards. Verify with your acquirer what is available for your business type and volume; do not assume a global processor is usable here without checking.
• Bank transfer with proof upload. Common for larger B2B orders. Needs an admin verification queue, or it becomes a WhatsApp process.

Whatever the mix, the order state machine must be explicit: pending, confirmed, paid, packed, dispatched, delivered, cancelled, returned, refunded — with defined transitions. Vague order status is how stores lose track of money.

Never take payment twice for one order

Checkout is the one place where a duplicate request cannot be tolerated. Users double-tap on slow connections, gateways retry callbacks, and networks drop responses after the charge succeeded.

Two safeguards, both essential. First, idempotency: the order creation and payment capture endpoints accept a client-generated key so a repeated request returns the original result instead of charging again. Second, reconcile server-side: never treat the browser's redirect as proof of payment. Trust only the gateway's server-to-server notification, verified by signature, and have a scheduled job that queries the gateway for any order left in an ambiguous state. Stores without that second job accumulate paid-but-unfulfilled orders and never know.

Stock accuracy is a trust problem

Selling something you do not have costs a customer permanently, and it is usually a system design issue rather than a warehouse one. What we build for: stock reserved when an order is confirmed rather than when it ships, so two customers cannot buy the last unit; a single source of truth if you also sell in a physical shop, because a POS and a website with independent stock counts will diverge within a week; and an oversell alert that reaches a human immediately rather than surfacing at month end.

Shipping, couriers and the cost of getting it wrong

Unclear delivery cost and timing is one of the largest causes of abandoned carts everywhere, and it is entirely fixable. Rates should be shown before the final step, not revealed at the end. Beyond that, a store integrated with a courier needs booking, label or consignment number generation, tracking status pulled back into the order, and a reconciliation of courier charges against what you quoted the customer — because the difference is silently eating your margin if nobody checks.

Returns need equal thought, particularly with cash on delivery. Who pays return shipping, what condition is acceptable, how long is the window, does stock go back into sellable inventory or a quarantine location, and how is the refund issued for an order that was paid in cash? These are policy decisions we need from you; the system enforces whatever you decide.

Tax, invoices and records

Invoicing seems trivial until it is audited. Get these right at build time: whether displayed prices include or exclude tax and how that is shown, sequential invoice numbering that cannot skip or repeat, credit notes for refunds rather than editing the original invoice, and retention of order documents in an immutable form. If you have an accountant, a thirty-minute conversation with them during discovery prevents a rebuild of your invoicing logic later.

Conversion work that is worth the money

Once the mechanics are right, a handful of things reliably move revenue, and they are mostly unglamorous: genuinely good product photography — the highest-return investment in e-commerce and the most under-budgeted; guest checkout, because forced account creation loses real orders; a fast, single-page-feeling checkout tested on a mid-range phone; abandoned-cart recovery emails; clear stock and delivery information on the product page rather than at checkout; and transactional emails that actually arrive, which means proper SPF and DKIM configuration and a real transactional email service.

Speed matters more here than on any other kind of site, because the visitor has no loyalty and a competitor is one tab away. Every store we build goes through the full performance pass before launch, with particular attention to product images and third-party scripts.