Online store builds · Delhi NCR, India & overseas
Seven in Ten Carts Are Abandoned. Most of That Is Built In.
Ecommerce website development services are the work of building an online store and the systems behind it: catalogue, checkout, payment gateways, shipping rules, tax, order flow and the admin screens your team actually has to live in. We are an ecommerce web design agency in Vikaspuri, West Delhi, building stores for founders and brands across India and overseas. The storefront is the part everyone looks at in the pitch. The plumbing behind it is where the project is won or lost, and where most of the budget honestly goes.
| Storefront and design | what everyone looks at |
| Catalogue and product data | the slow part |
| Checkout and payments | where carts are lost |
| Shipping, tax and returns | ✗ rarely scoped up front |
| The admin your team lives in | ✗ almost never specified |
We Publish What a Store Costs
Three tiers with real numbers, below. Ecommerce is the category where quotes most often arrive as a single figure with no breakdown, and where the breakdown is the only part that tells you anything.
We Scope Operations Before Design
Shipping rules, tax, returns and the admin flow are agreed before a single screen is designed. It is unglamorous and it is the reason our store builds do not drift.
We Do Not Take a Cut of Your Sales
No revenue share, no transaction percentage, no lock-in on the platform. You own the store, the code and the data, and you can take it elsewhere whenever you want.
You Get the Keys to Everything
Platform admin, payment gateway dashboards, domain, hosting, repository and analytics, all in your own name from day one. We have inherited too many stores where the previous agency held the accounts.
Finished versus working
Why Store Builds Run Over
A Store That Looks Finished
- ✗The quote is one numberA single figure for the whole store, with no line for catalogue, payment integration or the admin build. The missing lines reappear later as change requests.
- ✗Operations are an afterthoughtShipping zones, tax, cancellations and returns get discussed after the design is signed off, which is the point at which changing them is expensive.
- ✗The catalogue arrives late and rawProduct data turns up in a spreadsheet two weeks before launch with no descriptions, no proper images and no variant structure. The build then waits on it.
- ✗Checkout is whatever the theme shippedThe single highest leverage screen in the whole store is left at its default, with fields nobody questioned and a payment flow nobody tested on a real phone.
- ✗Nobody owns the admin experienceThe team who will process fifty orders a day were never shown the back end until handover, and it turns out to need eleven clicks per order.
A Store That Can Take Orders on Day One
- ✓The quote has lines you can argue withCatalogue, checkout, payments, shipping logic, admin and content are costed separately, so you can cut scope knowingly instead of discovering it later.
- ✓Operations are agreed in week oneHow you ship, where you ship, what you charge for it, how tax applies and what happens on a return. All settled before design, because all of it shapes the interface.
- ✓The catalogue has a structure before it has contentVariants, attributes, categories and filters are modelled first, so your product data has somewhere to go and does not have to be re-entered.
- ✓Checkout is designed, not inheritedField count questioned, guest checkout on by default, shipping cost visible early, and the whole flow tested on a mid-range Android phone on a slow connection.
- ✓Your team sees the back end before launchThe people who will actually use it walk through order processing while there is still time to change it.
What the data shows
Four Numbers From the Checkout
Three numbers from the same body of checkout research, and one about who is actually buying online in India. We have put the sources under the grid, along with two figures we went looking for and decided not to use.
70.22%
Of online shopping carts are abandoned, averaged across fifty separate studies
From the Baymard Institute, which maintains a running list of documented cart abandonment research. The 70.22 percent figure is the average across fifty studies published between 2006 and 2025, and the list was last updated in September 2025. The spread matters as much as the average: the studies range from roughly 60 percent to over 80 percent, so treat it as a benchmark for the category rather than a target for your store. The useful point for a build is that the number has barely moved in twenty years, which suggests most of it is structural rather than something a discount code fixes.
40%
Abandon because extra costs such as shipping, tax and fees were too high
Also from Baymard, from the same body of work on abandonment reasons, counting only shoppers who were genuinely intending to buy rather than browsing. It is the single largest stated reason by a wide margin. Note what it does not say: it does not say shipping is too expensive, it says the extra costs were too high, and shoppers see them late. Showing delivery cost on the product page and in the cart, rather than revealing it at the final step, is a build decision, not a marketing one. Three other reasons on the same list are also built rather than marketed: 18 percent left because the site forced them to create an account, 17 percent because checkout was too long or complicated, and 9 percent because there were not enough payment methods.
11.3
Form fields in an average checkout, when most stores need only eight
From the Baymard ecommerce UX benchmark, published in June 2024, measured across their panel of leading ecommerce sites. The average came down from 12.7 in 2019 and 11.8 in 2021, so the direction is right, but the gap to what is actually needed is still roughly three fields. Each unnecessary field is a small tax paid by every single customer who reaches that screen. This is the cheapest improvement available in ecommerce and the one most often skipped, because removing fields means arguing with whoever asked for them.
65%
Of new online shoppers in India come from tier-2 and smaller cities
From the India Brand Equity Foundation, in their ecommerce industry report dated May 2026. For a build, this is the figure with the most practical consequences and the least attention. It argues for a store that loads quickly on a mid-range phone and a patchy connection. It argues for payment methods beyond cards, and for cash on delivery treated as a first-class flow rather than a grudging checkbox. It also argues for address forms that cope with addresses which do not fit a neat template. A store tested only on a fast laptop in a metro is being tested on the wrong customer.
Sources: the abandonment rate and the reasons behind it are from the Baymard Institute cart abandonment list, 50 studies, updated September 2025. The checkout field count is from Baymard, published June 2024. The tier-2 share is from the India Brand Equity Foundation ecommerce report, May 2026. Three of the four come from the same research body, which we would rather say plainly than disguise by hunting for weaker sources that agree.
Two numbers we went looking for and left out. The size of the Indian ecommerce market: the IBEF page above gives figures of roughly 125 billion dollars, 145 billion and 211.6 billion for overlapping years without reconciling them, so we are not going to pick whichever is most flattering. And the share of Indian ecommerce payments made over UPI, which is quoted everywhere. The figures circulating are all secondary, and we could not check them against the published statistics of the National Payments Corporation of India, so they are not here. UPI matters enormously to your checkout either way, and you should support it. We just are not going to put a number on it that we have not verified.
Five Things to Settle Before You Commission a Store
Five things to settle before you ask anybody, including us, to quote. The first three are free and will change the quote you get. The last two decide whether you should be building a store at all this year.
- Count your products properly, including every size and colour as a separate line
- Write down how an order is handled today, from payment to packing to dispatch
- Open your current site on a mid-range Android phone on mobile data, and try to buy something
- Decide who in your team will add products and process orders every day, by name
- Work out your margin per order, and what you can afford to pay to acquire one customer
The last two are the ones that catch people. A store needs somebody whose actual job includes keeping it current, and if that person does not exist yet, the store will be out of date within three months of launch. And if your margin per order will not cover the cost of acquiring a customer, a better store does not fix that, it just makes the arithmetic visible faster. We would rather you discovered that now than after the invoice.
Our process
A Seven Step Build
Map Operations Before Anything Else
How you ship, where, at what cost, how tax applies, what happens on cancellations and returns, and who touches an order between payment and dispatch. Every one of these shapes the interface, so all of them come first.
Model the Catalogue
Categories, variants, attributes and the filters customers will actually use. Getting the structure right before any product data is entered is the difference between a catalogue you can grow and one you have to rebuild.
Choose the Platform on Evidence
Driven by your catalogue size, your operations and who maintains it, not by what is fashionable. We go into this properly further down, and we have separate pages on Shopify website design and WooCommerce development if you already know which way you are leaning.
Design the Checkout First
Before the homepage. It is the screen with the most revenue riding on it and the least creative latitude, so it gets designed while attention is fresh rather than in the last week.
Build the Store and the Admin Together
Storefront and back end developed in parallel, because a store your team cannot operate is not finished. Your order processors see working screens well before launch.
Integrate, Then Break It on Purpose
Payment gateways, shipping providers and tax configured, then tested with real transactions, failed payments, refunds, partial cancellations and an address that does not fit the form. The failure paths are the ones that matter.
Launch, Then Watch the Checkout
We stay on the store through the first weeks of real orders, watching where people stop. Early live data on your own checkout beats any benchmark, including the ones on this page.
Starter, Growth or Custom
The column you need is decided by your catalogue and your operations, not by your ambition. A brand with twelve products and one warehouse does not need the third column, however fast it plans to grow.
Pick the first column whenever your catalogue is small and your operations are simple, even if your plans are not. Moving from a Starter Store to a Growth Store later is ordinary work. Paying for a Custom Build before you have orders to justify it is money spent on capacity you may never use, and we will tell you so rather than take the larger brief.
What you get
What You Get
A working store, and the documentation that lets somebody else maintain it. The second part is the one most handovers skip.
A working store, on your own accounts
Platform, domain, hosting, payment gateways, repository and analytics, all registered in your name with you as owner. Not ours, with you added.
A structured catalogue
Categories, variants, attributes and filters modelled properly, with your products loaded and a documented method for adding more.
A designed checkout
Field count questioned line by line, guest checkout enabled, delivery cost visible before the final step, tested on real devices and slow connections.
Payment gateways, live and tested
Configured, tested with real transactions, and tested again on the failure paths: declined cards, abandoned sessions, refunds and partial cancellations.
Shipping, tax and returns logic
Zones, rates, free-shipping thresholds, tax treatment and the return flow, all configured and documented rather than left at defaults.
An admin your team can use
The order processing flow reviewed with the people who will do it daily, and adjusted before launch rather than after the complaints.
Mobile performance that holds up
Built and tested for a mid-range Android phone on mobile data, because that is what most of your customers are holding.
Handover documentation
How to add a product, change a shipping rate, issue a refund and read the analytics. Written for your team, not for a developer.
A fortnight of post-launch cover
We stay close through the first real orders, because that is when the problems nobody predicted turn up.
Who This Is Built For
Online store development services are worth buying when selling is the point of the site rather than a feature of it. These are the situations where that is usually true.
Brands selling direct for the first time
You have been selling through retail, marketplaces or direct messages, and you want a channel you own and can read properly.
Businesses outgrowing a marketplace
Amazon or Flipkart is paying the bills but taking the margin and keeping the customer relationship. A store of your own changes both.
Stores on a build that cannot keep up
The catalogue has outgrown the structure, the checkout is the theme default, and every change needs a developer. This is usually a rebuild rather than a repair.
B2C brands with real inventory
B2C ecommerce site development with sizes, colours, stock levels and returns to handle, which is a genuinely different problem from selling a single digital product.
Businesses with complicated shipping
Heavy or fragile goods, zone-based rates, multiple warehouses or anything where delivery cost varies enough to need real logic rather than a flat rate.
Indian brands selling overseas
Multi-currency, international shipping and the tax treatment that comes with it, built in from the start rather than bolted on when the first foreign order arrives.
Teams who will actually run the store
The best outcomes we get are with clients who name the person responsible for the store before the build begins. The worst are with those who intend to decide later.
What actually changes
What Changes in Practice
Specific and limited. A new store does not create demand, and anyone promising that is selling you something else. Here is what a properly built one actually changes.
Fewer carts lost to friction you control
Delivery cost shown early, guest checkout available, fewer fields and more payment methods. Four of the top reasons shoppers abandon are build decisions, and all four are fixable before launch.
Hours back from order processing
An admin flow designed around how your team actually works, rather than the platform default, compounds quietly. Two minutes saved per order is real money at any volume worth having.
A catalogue you can grow into
Structure modelled before data is loaded means adding a product line next year is an afternoon, not a migration.
Numbers you can act on
Analytics configured so you can see where people stop, rather than only that they did. Most stores we inherit cannot tell you which step loses the orders.
What a Growth Store Build Looks Like
This is the shape of a typical Growth Store build. It is an illustration of how the work is sequenced, not a fixed schedule, and the catalogue stage is the one that most often decides whether the rest runs to time.
Weeks 1 to 2: Operations and catalogue model
Shipping, tax, returns and order flow agreed and written down. Catalogue structure modelled and signed off. Platform decision made and reasoned. Nothing is designed yet, deliberately.
Weeks 3 to 4: Checkout and key templates
Checkout designed first, then product page, category page and cart. These four templates carry almost all the revenue, so they get the attention before anything decorative.
Weeks 5 to 7: Build and catalogue load
Storefront and admin built in parallel. Product data loaded into the structure agreed in week two. This is the stage that slips when the catalogue is not ready, which is why we ask for it early and loudly.
Weeks 8 to 9: Integrations and failure testing
Payment gateways, shipping providers, tax and analytics connected. Then tested properly: real transactions, declined cards, refunds, cancellations, awkward addresses, slow connections, old phones.
Weeks 10 to 11: Your team, then content
Order processing walkthrough with the people who will do it, and changes made while changes are still cheap. Remaining content and policy pages finished.
Week 12: Launch and watch
Go live, then stay on it. We watch the checkout through the first real orders, because the first fortnight tells you more than the previous eleven weeks of testing.
Published pricing
What an Ecommerce Website Costs in India
Published, because ecommerce is where vague pricing does the most damage. These are build fees. Platform subscriptions, payment gateway charges, apps and hosting are paid by you directly to those providers, and we will tell you what they come to before you commit.
Starter Store
A small catalogue, standard operations and a tightened default checkout. The right answer for most first stores, and a perfectly good place to take real orders from.
- ✓Up to about 50 products
- ✓Standard platform, light customisation
- ✓Checkout tightened and tested
- ✓Payment gateway integration
- ✓Basic shipping and tax setup
- ✓Mobile performance tested
- ✓Handover documentation
- ✓About 4 to 5 weeks
Growth Store
A modelled catalogue, a designed checkout and an admin flow shaped around your team. This is the tier most brands with real inventory and real operations actually need.
- ✓Up to about 500 products
- ✓Platform chosen on evidence
- ✓Custom theme and designed checkout
- ✓Payments, shipping, tax and analytics
- ✓Catalogue structure modelled first
- ✓Order flow adjusted to your team
- ✓Failure path testing
- ✓Team walkthrough before launch
- ✓Two weeks post-launch cover
- ✓About 8 to 12 weeks
Custom Build
Large or complex catalogues, multiple warehouses, international selling, or integration with inventory, accounting or ERP systems you already run.
- ✓Large or complex catalogues
- ✓Platform or custom stack
- ✓Instrumented checkout
- ✓Inventory, accounting or ERP integration
- ✓Multi-currency and international shipping
- ✓Admin built around your operations
- ✓Data migration from an existing store
- ✓Extended testing and staged launch
- ✓From 14 weeks
Four things move the price inside a band. The number of products once every variant is counted. How much of your product data needs writing rather than importing. How many integrations have to talk to each other. And whether you are migrating from an existing store. What does not move it is how much revenue you expect, because we are not going to price the build against your forecast.
Online store development price is also affected by one thing clients rarely budget for, so we will say it here. Product photography and product descriptions are usually the largest hidden cost of a store build, and they are usually the reason a launch date slips. We can quote for them separately, or you can handle them, but do not leave them unplanned.
What We Will Not Promise You
Ecommerce is the easiest category in this industry to oversell, because the client can picture the revenue. Here is what we will not claim.
- ✗We will not promise a conversion rateAnybody quoting you a figure before seeing your products, prices, delivery promise and competition is guessing. Conversion depends mostly on things outside the build, starting with whether your offer is good.
- ✗We will not promise trafficA store is a place to convert demand, not a source of it. Ranking an online store is separate work, and we have a page on ecommerce SEO that covers it honestly.
- ✗We will not build you a marketplace on a store budgetMulti-vendor platforms, with seller onboarding, split payouts and commission logic, are a different category of project. If that is what you want, we will say so rather than quote you a store and discover it later.
- ✗We will not pretend the platform decision is permanentStores do get replatformed, and a build that assumes otherwise is brittle. We keep your product data portable and your content exportable, even though it is not in our commercial interest to make leaving easy.
- ✗We will not take your store live on a FridayA small thing, and we hold to it. Launches generate problems, and problems need people available to fix them.
Where to Start
Start with the three free things in the list above, which cost nothing and take an afternoon. Count your products including variants, write down how an order moves through your business today, and try to buy something from your current site on a mid-range phone on mobile data. That last one is uncomfortable and it is the most useful twenty minutes you will spend.
Then send us the product count, your current order process and where you are leaning on platform. We will tell you which tier you are in, what the build involves and what it will cost, before anybody books a call. If you would rather talk it through first, that is fine too. And whoever you end up using, if you are about to hire an ecommerce development company in India, ask every one of them to price the catalogue, the payment integration and the admin build as separate lines. The ones who will not are the ones to worry about.
Ecommerce Build Questions, Answered
How much does an ecommerce website cost in India?
With us, between INR 85,000 and INR 7,00,000 depending on catalogue size and how complicated your operations are, and the three tiers above set out what sits in each band. Across the Indian market more broadly you will see anything from about INR 15,000 for a template store set up by a freelancer to several lakh for a custom build. Both ends of that range can be the right answer for somebody. The figure to watch is not the headline but what sits under it. A quote that does not separately price catalogue setup, payment integration, shipping logic and the admin build is not a cheap quote, it is an incomplete one. Also budget separately for product photography and descriptions, which are usually the largest cost people forget.
Shopify or WooCommerce, which should I choose?
The honest answer is that it depends on three things, and none of them is which platform is better. First, who maintains it: Shopify is hosted and handles its own updates and security, while WooCommerce runs on your WordPress site and somebody has to keep it patched. If nobody in your business will own that, Shopify is usually the safer choice. Second, running cost against control: Shopify charges a monthly fee and, unless you use its own payment product, a transaction fee, but it rarely breaks. WooCommerce has no platform fee and almost unlimited flexibility, but plugins can conflict and the hosting is yours to get right. Third, how unusual your requirements are: complicated B2B pricing, bespoke workflows or deep integration with systems you already run tend to favour WooCommerce. For most Indian B2C brands with a straightforward catalogue, we lean Shopify for the first store and WooCommerce when there is either a strong cost argument at volume or a requirement the hosted platform cannot meet. We build both, we have no partnership incentive either way, and there are fuller pages on Shopify website design and WooCommerce development.
How long does an online store take to build?
About 4 to 5 weeks for a Starter Store, 8 to 12 for a Growth Store, and from 14 weeks for a custom build. The variable that moves those dates is almost never the development, it is the product data. Stores wait on photography, descriptions, specifications and variant information far more often than they wait on code. If your catalogue is photographed, written and structured before we start, the timelines above hold comfortably. If it is not, the realistic answer is that the build takes as long as the catalogue does, and we would rather tell you that at the start than at week nine.
Do you set up payment gateways?
Yes, as part of every build. We integrate and test the gateway, which in India usually means one of Razorpay, PayU, Cashfree, CCAvenue or Shopify Payments, with PayPal or Stripe added when you sell overseas. Testing means real transactions and, more importantly, the failure paths: declined cards, abandoned sessions, refunds and partial cancellations. Two things to know. You apply for the merchant account yourself, because it is your business that is being underwritten, and approval needs your registration and bank documents, so start it early since it is a common cause of launch delay. And you cannot store customer card details yourself: the Reserve Bank of India requires tokenisation, and its own guidance states that a token requestor cannot store the card number or any other card detail. In practice the gateway handles that, which is one more reason to use a proper one rather than improvise.
Can you migrate my existing store to a new platform?
Yes, and it is a defined piece of work rather than a side effect of the build. Products, variants, customers, order history and URLs all have to move, and the URLs are the part most often fumbled. Old product and category addresses need redirecting to their new equivalents one by one, because a blanket redirect to the homepage loses the rankings those pages had. We map them before launch. Expect a migration to add somewhere between two and four weeks to a build, depending on catalogue size and how clean the existing data is.
Do I need cash on delivery?
In India, usually yes, and it should be treated as a proper flow rather than a reluctant checkbox. Prepaid-only checkouts still lose orders in much of the country, particularly outside the large metros, and tier-2 and smaller cities are where the growth in online shoppers is. The sensible approach is to offer it, measure the return rate against prepaid, and then decide whether to restrict it by pincode, order value or category. That is a decision to make on your own data after a few months, not before launch on somebody else’s advice.
What ongoing costs should I expect after launch?
Platform subscription if you are on a hosted platform, or hosting if you are not. Payment gateway charges per transaction, typically around 2 percent plus tax in India, which you should check against your own margin. Any paid apps or plugins. Domain renewal. And some provision for maintenance, because a store that takes money needs its updates applied. We set these out before you commit so the running cost is not a surprise, and we have a separate page on website maintenance if you want us to handle it.
Will my store work properly on a slow phone?
It will, because we test for it. Most Indian ecommerce traffic is mobile, a good deal of it on mid-range Android phones on mobile data, and a store that feels fine on a designer laptop can be close to unusable there. We test on real devices and throttled connections rather than on a desktop browser pretending to be a phone. If speed is already a problem on your existing store, that is a solvable and separate piece of work, covered on our website speed optimization page.
Do you work with ecommerce businesses outside Delhi?
Yes. We are an ecommerce website development company India wide, based in Vikaspuri, West Delhi, and we handle ecommerce website development in Delhi NCR, the rest of India, and overseas in the UAE, the UK and the USA. Clients who want an ecommerce developer Delhi NCR based, and who would rather map out operations face to face, are welcome at the studio. Store builds otherwise run perfectly well remotely, and most of ours do. The parts that genuinely benefit from being in the same room, the operations mapping and the admin walkthrough, work fine over video as long as the right people attend.
Can you just redesign my existing store instead of rebuilding it?
Often yes, and it is usually cheaper. If the catalogue structure is sound and the platform is fine, a redesign of the key templates plus a checkout rebuild gets you most of the benefit for a fraction of the cost. A full rebuild earns its money when the catalogue structure itself is the problem, when the platform genuinely cannot do what you need, or when the existing build is so customised that changing anything is expensive. We will tell you which situation you are in after looking, and we have a page on website redesign covering the general case.
How many products can you load, and do you write the descriptions?
We can load as many as you have, and the method matters more than the number. For anything above about fifty products we import from a structured spreadsheet rather than entering them by hand, which means the work is in getting your data into the right shape once. Descriptions and photography we can quote for separately, and we are straightforward about why: they are the most commonly underestimated part of a store launch, and leaving them unplanned is the most common reason a launch date moves.
Do you build B2B stores with customer-specific pricing?
Yes, though it is a different problem from B2C and it belongs in the Custom Build tier. Customer-specific price lists, minimum order quantities, quote requests, credit terms and approval workflows all need building and testing properly. It is very doable, and it is not something to attach to a starter store budget. If this is what you need, tell us early, because it changes the platform recommendation as well as the price.
What happens if I want to change agency later?
You take everything with you. The accounts are in your name from day one, the code is in a repository you own, the product data is exportable and the documentation is written for whoever comes next rather than for us. We think making it easy to leave is the only honest way to ask somebody to stay, and we would rather keep clients because the work is good.
Do you help with getting the store found once it is live?
It is separate work and we are clear about that. A store build makes a site that can be found and can convert. Actually ranking it is ecommerce SEO, which deals with category pages, product page structure, faceted navigation and the technical problems that large catalogues create. We do that work, on our ecommerce SEO page, and we would rather sell it to you as a separate decision than bundle it in and let you assume it is included.
Is an online store the right answer for my business at all?
Not always, and we will tell you when we think it is not. If your margin per order will not cover what it costs to acquire a customer, a store makes that arithmetic visible faster but does not change it. If your products genuinely need a conversation before purchase, a well-built enquiry site may convert better than a cart. And if nobody in your business will own the store day to day, it will be out of date within months whatever we build. We have talked people out of store builds before. It is a short conversation and it is cheaper than the alternative.
Store Builds by Industry
Related Services
Ecommerce Development by Location
Talk to Us About Your Store
Send us your product count, the platform you are leaning towards, and how orders are handled today. That is enough for us to tell you which tier you are in and what the build will actually involve. If a store is the wrong answer for you, which happens more often than you would expect, we will say so before anybody quotes.