Most guides to this answer a different question. They tell you how to sign up for a platform and pick a theme, which takes an afternoon, and then stop before the parts that actually decide whether the store works.
The build is not the hard bit. Getting the catalogue into a shape that will still make sense at four hundred products is the hard bit, and so is being ready to take money legally, and so is a checkout that people finish. This walks through the whole sequence in the order the work genuinely goes in.
Written for an Indian business, because two of these steps have answers here that they do not have anywhere else: what the law requires you to display, and when GST registration becomes compulsory. Both catch people out, and both are cheaper to handle before launch than after. GST invoicing for an Indian online store covers what the store has to produce once you are registered.
You can do most of this yourself. Some of it you should not. Where a step is genuinely worth paying for we say so, and where it is not we say that too. We write this as an ecommerce website development company in Pune, so the commercial interest is declared rather than hidden.
First, decide what you are actually building
There are three answers and they lead to completely different projects. Picking the wrong one is the most common expensive mistake at this stage, mostly because nobody stops to make it a decision.
Your own store, on your own domain
You own the customer relationship, the data and the margin. You also own acquisition, which is the hard part. Nobody arrives by accident. This is the right answer if you have a brand, repeat buyers, or products with enough margin to pay for traffic.
A marketplace listing
Amazon, Flipkart, Meesho. Demand already exists, so you can be selling this week. You do not own the customer, you compete on price inside somebody else's search, and your margin absorbs their commission. Good for validation and for commodity goods.
Both, in that order
What most successful Indian sellers we work with actually did. Marketplace first to prove the product sells, own store second to keep the customers who come back. The mistake is doing them simultaneously with half the attention on each.
Something that is not retail at all
If your buyers are dealers or distributors ordering on credit against negotiated price lists, you are not building a shop. You are building an ordering portal, and almost nothing in a standard ecommerce build applies to you.
That last one is worth being certain about before you go further, because the two projects share a name and nothing else. Dealer portals need customer-specific pricing, credit limits, minimum order quantities and approval steps, none of which a retail store has. If you sell both ways, you need both, and they should not be tangled into one checkout.
Write your answer down in one sentence before anything else happens. Half the scope disagreements we see on a build trace back to a founder and a developer holding different answers to this question without either of them noticing.
What to settle before anyone designs anything
None of this is exciting and all of it blocks launch. Start it now, because two of these have waiting periods that no amount of paying someone can shorten, and because they gate the marketplace applications if you also plan to sell products online through Amazon or Flipkart.
Sole proprietorship, LLP or private limited. It determines the name on your invoices, the bank account money settles into, and what a payment gateway will ask you for during onboarding. Changing it after you have issued invoices is genuinely painful.
Covered properly below, because the rule is different depending on how you sell. Get this wrong and you either register unnecessarily or trade without a registration you were required to hold.
In the business name, matching the entity. Gateways settle to it and will verify the name matches. A mismatch here is one of the commonest reasons onboarding stalls for a fortnight.
Buy it before you commission a logo. Short, spellable over a phone call, and ideally the same as the name you will trade under. A .in or a .com both work; what matters more is that you can say it aloud without spelling it.
The GST rule that surprises people
This is the one worth reading twice, because the answer flips depending on where you sell.
Selling through a marketplace, which in GST language is an electronic commerce operator, generally makes registration compulsory regardless of turnover. The ordinary thresholds of forty lakh for goods and twenty lakh for services do not shelter you. In practice, listing one product on Amazon can require a GSTIN where the same product sold from your own website would not.
Selling only through your own website is different. Those standard turnover thresholds do apply. And there is now a narrow exemption for intra-state suppliers through an operator who stay below the threshold, though it is narrow enough that most businesses planning to grow will not sit inside it for long.
| How you sell | Registration required | Threshold that applies |
|---|---|---|
| Your own website only | Once you cross the threshold | Rs 40 lakh goods, Rs 20 lakh services |
| Through a marketplace | Generally from the first sale | Ordinary thresholds do not apply |
| Intra-state through an operator, below threshold | Narrow exemption may apply | Rs 40 lakh goods, Rs 20 lakh services |
| Both website and marketplace | Yes, driven by the marketplace side | One GSTIN covers both channels |
| Position as of August 2026 | Confirm with your accountant | Turns on what and where you sell |
One consequence people miss: once you are registered because of marketplace sales, your own-website sales come under that same registration too. You do not get to keep them separate. Confirm your own position with your accountant rather than with a guide, ours included, because the details turn on what you sell and where your buyers are.
Catalogue first, design second
The single most reliable predictor of whether a build goes smoothly. Teams that structure the catalogue before choosing a theme ship on time, and end up with a product feed that will pass review later. Teams that pick a beautiful theme and then try to pour their products into it spend the last three weeks fighting it.
The reason is simple. A theme is a set of assumptions about how many images a product has, how many variants, how long a title runs, whether there is a size chart, whether products belong to one category or several. If your catalogue disagrees with those assumptions, something has to give, and at that point the theme is already paid for.
List every attribute a customer would filter or search by
Size, colour, material, capacity, compatibility, brand. These become filters and, later, the facets that either help your customers or eat your crawl budget. Deciding them now is free. Adding one across four hundred products later is not.
Decide what is a variant and what is a separate product
The decision that is hardest to reverse in the entire build. Different sizes of the same shirt are variants. Two shirts that merely look similar are separate products. Get it wrong and you are re-entering the catalogue, re-shooting images and rebuilding every URL that ranked.
Fix your SKU scheme and use it everywhere
The same code in the store, in your accounts and on the shelf. This is what makes stock reconciliation possible later, and it costs nothing today.
Write one real product description
Not a placeholder. A real one, at the length you can sustain for the whole catalogue. If you cannot write four hundred of those, find that out now and change the plan, rather than in launch week.
Shoot one product properly
Same reason. Consistent background, consistent crop, consistent aspect ratio. Product photography is the one line where paying a professional almost always returns the money, and mixed-quality images are visible to a customer in about half a second.
A spreadsheet with every product, its attributes, its variants and its SKU is a better deliverable at this stage than any mockup. It also means the eventual import is an afternoon rather than a fortnight of typing, and it is what decides later whether your category pages have anything to rank with.
Choosing the platform
With a catalogue in hand this becomes a much easier question, because you now know what you are asking the platform to hold. We have a full comparison of Shopify and WooCommerce for Indian stores, so this is the short version.
Somebody else runs the infrastructure and you pay monthly for it.
- Fastest route from nothing to selling
- No hosting, patching or backups to think about
- A per-order fee that is unavoidable in India
- The checkout is not yours to rewrite
You own the code and the server, and the responsibility that comes with them.
- No percentage taken by the platform itself
- Every part of cart and checkout is changeable
- Somebody has to apply the updates, forever
- Only as fast as the hosting you pay for
The honest short answer for a first store with a standard catalogue: either will work, and you should pick on who will maintain it rather than on features. If your business has rules a template will not express, that changes, and occasionally the answer is a custom ecommerce build instead. That is rarer than people who want a custom build think.
Ignore any comparison that recommends a platform without asking what you sell, how many products you have, and who will keep it updated. It is a recommendation that was written before the question.
What the build actually involves
The visible work is a homepage, category pages, product pages, cart and checkout. That part is well understood and rarely goes wrong. What follows is the work that is invisible in a mockup and is where estimates go astray.
Search and filtering that survives your catalogue
Default platform search is usually adequate at fifty products and painful at five hundred. Whether you need something better is a function of catalogue size and how people shop, and it is much cheaper to decide at the start than to retrofit.
Every transactional email
Order confirmation, dispatch, delivery, refund, password reset. Each one needs writing, styling and testing, and each one is read far more attentively than any page on your site. Teams routinely forget these until the week of launch.
The shipping rules, in full
Free above a threshold, flat below it, different by weight or zone, serviceability by pin code. Write these out as sentences before anyone configures anything, because they are almost never as simple as the first description of them.
Tax configuration that matches your invoices
Rates per category, and the split between CGST with SGST and IGST depending on place of supply. A store that computes tax differently from the invoice your accountant expects is a month-end problem every month.
Analytics and conversion tracking, before launch
Installed and verified on day one, not after the first campaign. Data you did not collect in the first month is gone, and it is the month you most want to look back at.
A staging copy of the store
Somewhere to try a change that is not the live site. On a self-hosted store this is not optional once you have real orders, and setting it up after an incident is a bad time to learn how.
Alongside that sits everything the store has to talk to: payments, courier, accounting, and sometimes an ERP or a Tally export. Each of those is a real piece of work rather than a switch, which is why we treat them as their own integration scope rather than a line at the bottom of a build.
The checkout is the product
Everything upstream exists to get someone here, and this is where the money is won and lost. The Baymard Institute puts the average documented cart abandonment rate at 70.22%, drawn from fifty separate studies. Seven in ten people who add something to a cart do not buy it.
Not all of that is fixable. A large share of carts are used as wishlists or price comparisons and were never going to convert. But Baymard also finds that nearly one in five shoppers has abandoned a cart specifically because the checkout was too long or too complicated, and that is entirely yours to fix.
| What Baymard measures | What it found |
|---|---|
| Average documented abandonment rate | 70.22%, across 50 studies |
| Average US checkout, elements shown by default | 23.48 |
| Average US checkout, counting form fields only | 14.88 |
| Abandoned over a long or complicated checkout | Nearly 1 in 5 shoppers |
| Reduction achievable in most checkouts | 20% to 60% fewer elements |
| The practical read | Most checkouts ask for things they do not need |
Go through your own checkout and, for every field, name what the business does with the answer. Anything you cannot justify comes out. Company name on a retail order, a second address line nobody reads, a phone number you already have, date of birth for a product with no age restriction. Each one is a small tax on every order you take.
Two India-specific points on top of that. Pin code serviceability belongs on the product page rather than the checkout, because finding out you do not deliver to their area after choosing a size and colour is the worst possible moment. And if you offer cash on delivery, which most Indian stores must, the rules around it are part of the checkout design rather than an afterthought. What that costs you is covered in the payment gateway guide.
Test the whole flow on a mid-range Android phone, on mobile data, using the UPI app your customers actually use. Not on a laptop, and not on the newest phone in the office. This one exercise finds more lost revenue than any redesign.
Taking money and getting parcels out
Two decisions, each worth making deliberately. On payments, the headline percentage matters less than settlement cycle, success rate and whether the provider holds the right RBI authorisation, all of which we go through in the payment gateway guide. Budget on your real payment mix rather than a rate card, and remember the 18% GST that applies to the fee.
On delivery, the thing to settle early is what a customer sees. Whether shipping is free, flat or calculated; how long delivery takes to their pin code; and what happens when something goes wrong. Vague answers to any of those show up directly in abandonment.
Cash on delivery deserves its own decision rather than being switched on by default. It is how a majority of Indian ecommerce orders are still placed, with ET Prime Research putting it at 60% to 65% of orders in 2024 and higher outside the metros, so switching it off costs real revenue. It also fails far more often than prepaid, and every refused delivery costs you freight in both directions plus the acquisition you already paid for. Take it, and control it.
The part almost everyone leaves until it hurts is reconciliation, and it is an ecommerce integration rather than a spreadsheet job. Your courier collects COD cash on your behalf and remits it later as a lump sum. Unless you can match those remittances back to individual orders, shortfalls from lost parcels, weight discrepancies and deducted return freight go unnoticed for months. Decide at build time how that will be tracked.
What Indian law requires on the site
This section exists because almost no guide to building an ecommerce website mentions it, and it is not optional. The Consumer Protection (E-Commerce) Rules, 2020 were notified on 23 July 2020 under the Consumer Protection Act, 2019, and they set out what an ecommerce entity has to display and how it has to handle complaints.
Most of it is straightforward to comply with if you know about it at build time, and awkward to retrofit into a finished design, at which point it becomes a redesign and migration job. Here is the shape of what is expected.
Who you are, in full
Legal name, the principal geographic address of your headquarters and branches, website details, email address and customer care contact numbers. GSTIN and PAN where applicable. Not a contact form alone.
The total price, in one figure, with the breakup
A single total alongside a breakdown of every compulsory and voluntary charge: delivery, postage and handling, conveyance, and applicable tax. Surprise charges appearing at the last step are exactly what this is aimed at.
Your policies, displayed clearly
Returns, refunds, exchange, warranty, delivery, payment methods and charges, and grievance redressal. Written in a way a customer can act on rather than copied from another site.
A named grievance officer
Appointed, with their details visible on the site. Complaints acknowledged within forty-eight hours and resolved within one month. That is an operational commitment as much as a page of text.
The grievance officer requirement is the one people are most often unaware of, and it is the easiest to satisfy: a name, a role, an email and a stated response time. Failing to have one is not something a customer complaint is a good time to discover.
Alongside those, you need the ordinary pages any store carries: terms and a privacy policy that actually describes what you collect. Have a professional look over the finished set if you are selling anything regulated, anything to children, or anything with a warranty you are making claims about. This guide is not legal advice and is not a substitute for someone who gives it.
The checks that belong before launch, not after
A short list, and every item on it is cheaper now than in week two.
Speed, measured the way Google measures it
Core Web Vitals are assessed at the 75th percentile of real Chrome user sessions over a rolling twenty-eight day window, which means three quarters of your visitors have to clear the bar, not your laptop on office wifi. Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. All three have to pass. One metric sitting in the needs-improvement band fails the whole assessment.
| Metric | What it measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | When the main content finishes rendering | Under 2.5s | 2.5s to 4s | Over 4s |
| INP | How fast the page answers a tap | Under 200ms | 200ms to 500ms | Over 500ms |
| CLS | How much the layout jumps while loading | Under 0.1 | 0.1 to 0.25 | Over 0.25 |
| Assessed at | The 75th percentile of real Chrome sessions | All three must pass | One failure fails the page | Rolling 28 days |
The twenty-eight day window matters for planning. Field data does not appear the day you launch, so fix what a lab test tells you now and expect the real numbers a month later.
- Every product page has a title, a description, an image and a price. Run the export and sort by blank.
- Place a real order end to end, with real money, and refund it. Then do it again on COD.
- Every transactional email arrives, in the right order, and is not in spam.
- The store works on a three-year-old Android phone on mobile data.
- Analytics and conversion tracking fire, verified with a real transaction rather than assumed.
- Search Console and a sitemap are in place on day one, not after the first month of traffic is lost.
- Someone other than the person who built it tries to buy something without instructions.
The last one finds more problems than every automated check combined. Watch them without helping, and write down every place they hesitate. If search visibility is part of the plan rather than an afterthought, the structural decisions behind it belong at this stage too, which is what building with SEO in from the start means in practice.
What happens after launch, which nobody budgets for
Launch is the start of what an ecommerce website costs, not the end of it, and on WooCommerce the ongoing half has a shape of its own: what a WooCommerce store costs to run. The stores that struggle are almost never the ones that launched with a flaw. They are the ones where nobody owned the store afterwards.
On a self-hosted store that means WordPress, PHP, WooCommerce and every plugin, in an order that does not break the checkout, ideally on staging first. On a hosted platform it means your apps and your theme. Neither is zero.
Where is my order, can I exchange this, why was I charged twice. Response time is a retention lever and it is usually the first thing to slip.
Conversion rate, abandonment, COD failure rate, refunds. Not daily, but monthly, by somebody who will act on what they see rather than just report it.
A new store has no rankings and no audience. Whether that comes from search, ads, marketplaces or a customer list you already own, it is a separate budget from the build.
Decide who does each of those before launch, by name. In-house is fine, a retainer is fine, and "we will sort it out later" is the one that costs money. We run maintenance and ecommerce SEO for stores we did not build, precisely because this is the gap people fall into.
The four decisions that are expensive to reverse
Everything else on a store can be changed later for reasonable money. These four cannot, so they deserve disproportionate attention now.
Your URL structure
Every URL that earns a ranking or a link becomes an asset. Changing one later means a redirect, and changing a thousand means a migration project where some of the value does not survive. Decide the pattern before the first product goes live.
How your products are modelled
Variant or separate product, which attributes exist, how categories nest. Restructuring this after launch touches the catalogue, the images, the URLs and anything integrated with it, all at once.
The platform
Reversible, but as a migration rather than a switch. Products, customers and order history move with effort; tokenised cards and search equity are the parts that do not simply transfer.
The entity you sell under
Once you have issued invoices, taken payments into a bank account and registered for GST under one name, changing it is an administrative project rather than an edit. This is why it belongs in week one.
If you are reading this because an existing store already got one of these wrong, that is a different project with a different shape, and it is the redesign and migration work we do most often.
What to do this week
- Write one sentence describing what you are building and who buys from it.
- Start the entity, GST and current account paperwork, because it waits for nobody.
- Buy the domain.
- Build the catalogue spreadsheet: products, attributes, variants, SKUs.
- Write one real product description and shoot one product properly.
- Decide who maintains the store after launch, by name.
Do those six and the rest of the project becomes ordinary work. Skip them and every later step takes twice as long, because each one turns into a decision nobody prepared for.
Tell us what you sell, roughly how many products you have and how orders reach you today. We will tell you what the build actually involves, what to do yourself, and where the cost genuinely sits.
Questions we get asked about this
How long does it take to build an ecommerce website?
A small catalogue on a hosted platform with a standard theme can be live in two to four weeks, and most of that is catalogue work rather than build work. Anything with custom checkout rules, dealer pricing or an ERP integration runs to months. The reliable predictor is not the design; it is how ready your product data is when you start.
Do I need GST registration to sell online?
It depends on how you sell. Supplying through a marketplace generally makes registration compulsory regardless of turnover, because the ordinary forty lakh and twenty lakh thresholds do not apply there. Selling only through your own website falls under those standard thresholds instead. There is also a narrow exemption for intra-state supply through an operator below the threshold. Confirm your own position with your accountant, because it turns on what you sell and where your buyers are.
Can I build an ecommerce website for free?
You can get something running at close to zero on a free WooCommerce install plus cheap hosting, or on a hosted platform trial. It stops being free the moment you need a domain, a payment gateway, a decent theme and somebody to keep it updated. The realistic floor is small rather than nothing, and treating your own time as free is how people conclude a project cost less than it did.
What legal pages does an Indian ecommerce site need?
Beyond terms and a privacy policy, the Consumer Protection (E-Commerce) Rules, 2020 expect your legal name and geographic address, contact details, the total price with a full breakup of charges, and clearly displayed return, refund, exchange, warranty, delivery and grievance information. You also need a named grievance officer displayed on the site, with complaints acknowledged in forty-eight hours and resolved within a month.
Should I start on a marketplace or my own website?
Marketplace first is the lower-risk order if you are still proving that the product sells, because the demand already exists. Your own store is what you build once you have repeat customers worth owning, since it keeps the margin and the relationship. Doing both at once with half your attention on each is the version that usually disappoints.
Which platform should a first-time store use?
For a standard retail catalogue, either of the main two will work, and you should choose on who will maintain it rather than on features. It changes if your business has rules a template will not express, or if order volume is high enough that a per-order platform fee starts to matter.