July 31, 2026Quick answer: Choose an eCommerce development company in India by scoring vendors on six things: engineering depth, commerce domain fluency, integration track record, migration and SEO discipline, delivery model, and commercial terms. Ask to meet the engineers before you sign, insist on IP assignment at payment milestones rather than project completion, and treat any vendor who quotes without discovery as a vendor who is guessing. Selection should take three to five weeks, not three days.
Key takeaways
The vendor's portfolio tells you what they designed, not what they engineered. Ask what broke and how they fixed it.
Meeting the actual engineers before contract signature is the single most predictive step in the whole process.
IP assignment at project completion is a trap. It should vest at each payment milestone.
Clutch and GoodFirms are useful for shortlisting and near-useless for deciding. Reference calls decide.
If every answer in the pitch is yes, you are talking to a sales team, not an engineering team.
Most bad eCommerce vendor decisions are not made carelessly. They are made thoroughly, using the wrong criteria.
The buyer builds a spreadsheet. Compares day rates. Reviews portfolios. Checks Clutch. Sits through three pitches with broadly identical slides. Picks the one that felt most confident and came in ₹4 lakh under the others.
Eleven months later the store is live, the ERP sync drops orders on Fridays for reasons nobody has diagnosed, the B2B pricing runs on a plugin that conflicts with the subscription plugin, and the vendor's original team has moved on to other accounts. The buyer did the work. The work measured the wrong things.
This guide is the framework I would use if I were on your side of the table. It includes a hundred-point scorecard, fourteen questions with the answers that should reassure you and the answers that should end the conversation, and the seven contract clauses that decide whether you own your platform or merely rent it from your vendor.
A note on where this comes from, since it matters for how much weight you give it: we are an eCommerce development company. We would like you to hire us. That is exactly why the scorecard below is published in full rather than summarised — an evaluation instrument you can turn on the company that wrote it is the only kind worth reading. Score us with it. If we fall short on a dimension that matters to you, you have learned something useful for the price of ten minutes.
Why Most eCommerce Vendor Selections Go Wrong
Three failure patterns account for the majority of it.
The portfolio problem
Portfolios show finished screens. Screens are the cheapest part of an eCommerce build and the least predictive of whether the platform will hold.
What you cannot see in a portfolio: whether the catalogue architecture survived the client's third year of growth, whether the ERP integration handles duplicate webhooks, whether the checkout was load-tested, whether anyone monitored the migration in Search Console for the fortnight after cutover. All of that is invisible in a screenshot and all of it determines whether the project was a success.
A vendor who shows you twelve beautiful stores has demonstrated design capability. They have demonstrated nothing about engineering capability, and those are different companies more often than buyers expect.
The pitch team versus the delivery team
In many agencies the people in the pitch are not the people who build. This is not necessarily dishonest — it is how agencies are structured. It becomes a problem when nobody tells you, and the senior architect who impressed you in week one is on a different account by week four.
The test is simple and almost nobody applies it: ask to meet the specific engineers who would work on your build, before you sign. A company that says yes has structural transparency. A company that deflects has told you something important.
What a "Top 10" listicle actually measures
Search "best eCommerce development company in India" and you will find dozens of ranked lists. Most are written by companies that appear in them, or by publishers selling the placements.
The ones that are not paid still measure the wrong thing. They measure marketing output — review volume, portfolio polish, content production — because that is what is visible from the outside. Engineering quality is invisible from the outside. That is the whole problem, and it is why you need an instrument rather than a list.
Step 1: Define What You Are Actually Buying
Half of vendor-selection confusion is scope confusion wearing a different hat. Before you speak to anyone, settle three questions.
Storefront or commerce infrastructure?
A storefront is a catalogue, a cart and a checkout. Commerce infrastructure is an order lifecycle, a pricing engine, an inventory model and a set of integrations that behave under load. Both get called "eCommerce development." They are different disciplines requiring different vendors, and vendors who excel at one are frequently mediocre at the other.
If your requirements include account-level pricing, ERP synchronisation, multi-warehouse inventory or subscription billing, you are buying infrastructure. Filter your shortlist accordingly, because a strong Shopify agency is genuinely the wrong tool for that job and a good one will tell you so.
Build, replatform or extend?
Extending an existing store is a different engagement from replatforming, and replatforming carries risks a new build does not — rankings, order history, customer accounts, live trading during cutover. Vendors who are strong at greenfield builds are not automatically strong at migration. Migration is a discipline of its own, and the question of whether replatforming actually pays deserves its own analysis before you shortlist anyone.
Write a brief that produces comparable quotes
If you have read what eCommerce development costs in India, you already know the eleven-question pre-quote checklist. It applies here for a second reason: a brief that specifies catalogue structure, pricing rules and integration list does not just produce accurate quotes. It produces comparable ones, which is what makes evaluation possible at all.
Vendors receiving a specified brief typically quote within 15% of each other. Vendors receiving "we need an eCommerce website" quote within 400% of each other, and no scorecard on earth will help you compare those.
Step 2: The Four Types of Vendor
Freelancer | Platform agency | Development company | In-house team | |
|---|---|---|---|---|
Typical cost | ₹500–1,500/hr | ₹1,200–2,500/hr | ₹2,000–4,000/hr | ₹1.2–3 cr/yr fully loaded |
Best at | Small changes, single-skill tasks | Theme builds, hosted platform work, speed to market | Custom systems, integrations, B2B logic | Continuous product evolution |
Weak at | Anything needing more than one skill | Custom backend, complex pricing, ERP depth | Very small budgets | Getting started; specialist gaps |
Continuity risk | Very high | Medium | Low to medium | Low |
Suits | <₹2 lakh scope | ₹2–12 lakh, standard commerce | ₹12 lakh+, or any integration-heavy build | ₹8 cr+ GMV with permanent roadmap |
When you should not hire a development company
Worth saying plainly, because you will not hear it in a pitch.
If your catalogue is under 200 SKUs with one price per product, you are validating demand rather than scaling it, and your integrations are a payment gateway and a shipping partner — hire a good platform agency or configure a theme yourself. A development company will build you something more capable than you need, and you will pay for capability you cannot yet use.
The trigger for moving up is not revenue. It is friction: workarounds accumulating, plugins conflicting, a feature your business needs that the platform refuses to support. Until you feel that friction, the cheaper option is the correct option.
Step 3: The 100-Point Vendor Scorecard
Score each vendor independently, before you compare. Scoring after comparison produces rationalisation rather than assessment.
Engineering depth — 25 points
Criterion | Points | What earns full marks |
|---|---|---|
Employs the engineers directly | 5 | In-house team, named, on payroll. Subcontracting disclosed if it exists |
You can meet the build team pre-contract | 5 | Yes, without friction, including the technical lead |
Evidence of custom backend work | 10 | Can walk you through a system they architected — data model, order lifecycle, why each decision was made |
Engineering practice | 5 | Version control, code review, automated testing, CI, staging environments — described specifically, not as buzzwords |
Commerce domain fluency — 20 points
Criterion | Points | What earns full marks |
|---|---|---|
Understands your pricing model unprompted | 5 | Asks about contract rates, volume breaks and precedence before you raise them |
Has shipped your commerce type | 5 | D2C, B2B, marketplace or subscription — the same shape, not just the same industry |
Talks in commercial metrics | 5 | Conversion, AOV, cost to serve, repeat rate. Not "feature-rich" and "user-friendly" |
Knows the India layer | 5 | GST and e-invoicing, UPI flows, COD and RTO handling, vernacular requirements where relevant |
Integration track record — 20 points
Criterion | Points | What earns full marks |
|---|---|---|
Named ERP integrations | 5 | "We've integrated Tally three times and SAP twice" beats "we integrate with all major ERPs" |
Failure-case engineering | 5 | Retries, idempotency, dead-letter queues, reconciliation reports — offered before you ask |
Master data clarity | 5 | Can state which system owns products, customers and stock, and why |
Can describe a failure honestly | 5 | Names a specific integration that went wrong and what changed afterwards |
That last one is worth more than its five points suggests. A vendor who has never had an integration fail has either not done many, or is not telling you the truth.
Migration and SEO discipline — 15 points
Criterion | Points | What earns full marks |
|---|---|---|
URL mapping and 301 strategy as a deliverable | 5 | A named document with an owner, not a task buried in a sprint |
Traffic continuity in acceptance criteria | 5 | Written into the contract with a measurable threshold |
Parallel-run and crawl comparison | 5 | Pre-launch crawl compared against live, both platforms running until cutover is uneventful |
Skip this dimension entirely if you are building greenfield with no existing site. Rescale the remaining categories to 100.
Delivery model — 10 points
Criterion | Points | What earns full marks |
|---|---|---|
Working software every sprint | 4 | Two-week cadence, clickable output, no status decks |
Direct engineer access | 3 | You talk to the people writing the code |
Named team continuity | 3 | The same people from kickoff to handover |
Commercial terms — 10 points
Criterion | Points | What earns full marks |
|---|---|---|
IP assignment at milestones | 3 | Vests as you pay, not at project completion |
Documented architecture as a deliverable | 3 | Named in the SOW |
Exit and handover clause | 2 | Defined process, defined timeline |
Payment schedule | 2 | Not front-loaded above 40% |
Reading the score
Total | What it means |
|---|---|
85–100 | Shortlist. Negotiate on scope and terms, not on whether they can build it |
70–84 | Viable. Identify which dimension lost points and close that gap contractually |
55–69 | High risk. Acceptable only for simple, well-bounded scope |
Below 55 | Walk. The gap will surface during integration testing, at the worst possible moment |
Step 4: Fourteen Questions, and What the Answers Reveal
Ask these in the technical call, not the sales call. If there is no technical call available, that is itself the answer.
1. Who exactly will write this code, and can I meet them? Tests: team transparency and whether the pitch team is the delivery team. Strong: named engineers, introduced on the next call, with their relevant background. Warning: "The team is assigned after contract signature." Walk away: deflection, or an account manager answering on the team's behalf.
2. Walk me through the data model you would use for my catalogue. Tests: whether they think architecturally or template-first. Strong: they ask about variants, attributes, units of measure and how merchandising will manage it — then sketch something. Warning: "We'll figure that out in development." Walk away: they describe a theme.
3. How does your pricing engine handle a customer with both a contract rate and an active promotion? Tests:B2B depth. This is the question that separates the two halves of the market. Strong: they explain precedence rules and where those rules are configured. Warning: "The plugin handles it." Walk away: they have not encountered the problem.
4. Which ERPs have you integrated, by name, and how many times? Tests: real track record versus capability claims. Strong: specific systems, specific counts, an offer to connect you with one of those clients. Warning: "All the major ones." Walk away: they name systems but cannot describe the sync pattern.
5. What happens when the ERP is down for four hours during a sale? Tests: failure-case engineering. Strong:queuing, retries with backoff, alerting thresholds, a reconciliation report, and a decision about whether to keep selling.Warning: "We'd get an alert." Walk away: "That shouldn't happen."
6. How do you preserve SEO during replatforming? Tests: migration discipline — the single most expensive thing to get wrong. Strong: URL mapping document, 301 strategy, structured data carry-over, parallel-run crawl comparison, Search Console monitored daily through cutover, traffic continuity in the acceptance criteria. Google's own site-move documentation sets the baseline here; a competent vendor will exceed it. Warning: "We'll set up redirects." Walk away: "SEO is handled by your marketing team."
7. What performance targets will you commit to in writing? Tests: whether speed is engineered or hoped for.Strong: numeric Core Web Vitals targets on a specified device and network, plus load-test multiples for checkout.Warning: "We follow best practices." Walk away: "It'll be fast."
8. Tell me about a project that went wrong. Tests: honesty and institutional learning. Strong: a specific failure, what caused it, what changed in their process afterwards. Warning: a failure blamed entirely on the client. Walk away: "We haven't had one."
9. Who owns the code, and when does ownership transfer? Tests: commercial posture. Strong: you own it; assignment vests at each payment milestone; repository access from day one. Warning: ownership transfers at final payment. Walk away: ownership is "discussed at project end," or they retain a licence.
10. What is in your quote for data migration? Tests: whether they have done this before. Strong: a discrete line item with a range, plus an explanation that legacy data is never clean. Warning: it is bundled into "development." Walk away: it is not mentioned.
11. What is not included in this quote? Tests: scope honesty. Possibly the most useful question on the list. Strong: a clear list — content creation, photography, third-party licences, post-launch retainer. Warning: "Everything is included." Walk away: irritation at the question.
12. How will we work together after launch? Tests: whether they build for handover or for dependency. Strong:documented architecture, a knowledge-transfer session, an optional retainer, and a path where your own team could take over. Warning: support is only available as a mandatory annual contract. Walk away: no documentation deliverable.
13. What would you tell me not to build? Tests: advisory capability versus order-taking. Strong: they identify something in your brief that is premature, over-engineered or better solved without code. Warning: a vague "we'd phase it." Walk away: nothing. Everything in your brief is a great idea. This is the most common failure on the list, and the most predictive.
14. If we stopped work in month three, what would I have? Tests: whether value accrues incrementally or only at the end. Strong: a specific description of working software plus documentation and repository access. Warning: "A partial build." Walk away: "Nothing useful."
Want a second opinion on a shortlist you already have? We will run this scorecard against the proposals on your desk — including ours, if we are one of them — and tell you where the gaps are. No obligation to hire anyone. Book a 30-minute review →
Step 5: Verifying Claims Independently
Everything above is what the vendor tells you. This step is what you find out for yourself.
Reading Clutch and GoodFirms critically
Both are legitimate directories with verified-review processes, and both are useful for building a shortlist. Neither should decide anything.
What to actually look at: not the star rating, which clusters near five for everyone. Read the project descriptions in the reviews and ask whether they resemble your project. Twenty five-star reviews for Shopify theme work tell you nothing about whether the company can build a B2B pricing engine. Check review recency — a strong profile built three years ago describes a company that may no longer exist in the same form. Check whether reviewers are named with verifiable roles.
The reference call
Ask for two references: one recent, one at least two years old. The old one matters more, because it tells you what the platform was like to live with.
Three questions that produce honest answers:
What did you have to fix after launch that you expected to be finished?
When something broke, how long did it take to get an engineer who understood the problem?
If you were starting again, would you hire them, and would you change anything about how you scoped it?
Audit their clients' live sites yourself
This is the step almost nobody takes and it is the most revealing.
Take three sites from the vendor's portfolio and run each through PageSpeed Insights on mobile. View source and check for structured data. Open a product page and look at the schema. Go through the checkout to the payment step.
You are not looking for perfection — some of those constraints belong to the client. You are looking for a pattern. Three portfolio sites with no product schema and four-second mobile loads tells you what this vendor's baseline actually is, regardless of what the pitch said.
Step 6: The Contract Clause Checklist
Seven clauses decide whether you own your commerce platform or effectively lease it from your vendor. Most Indian mid-market contracts contain none of them.
# | Clause | Why it matters |
|---|---|---|
1 | IP assignment at payment milestones | Assignment at "project completion" means a stalled project leaves you with nothing you own. Vesting as you pay means the work is yours as it is delivered |
2 | Repository access from day one | You should be able to see the code as it is written. Escrow is a weaker substitute; direct access is the standard to ask for |
3 | Documented architecture as a named deliverable | Data model, integration contracts, deployment process, environment configuration. Without it, your platform is only maintainable by the people who built it |
4 | Performance SLAs expressed as numbers | "Optimised for speed" is unenforceable. "LCP under 2.5s on a mid-range Android over 4G, verified pre-launch" is a test that passes or fails |
5 | Integration failure handling specified | Name the retry policy, the alerting thresholds and who receives the alerts. Silent failures are the most expensive class of eCommerce bug and the least contracted-for |
6 | Post-launch handover defined | A knowledge-transfer session, credentials inventory, and a documented runbook. Specify the timeline, not just the intent |
7 | Exit clause with code and data portability | How you leave, what you take, how long it takes. Negotiate this while everyone is friendly, because you will only need it when they are not |
None of these are unreasonable and a confident vendor will agree to all seven. Resistance to clause 1 or clause 7 in particular is worth taking seriously as a signal about how the relationship will run.
Engagement Models and What Each One Costs You
Your choice of engagement model changes your risk more than your price.
Model | You carry | They carry | Right when |
|---|---|---|---|
Fixed cost | Change-request friction | Delivery risk, priced as a 10–20% premium | Scope is genuinely locked |
Dedicated team | Prioritisation and direction | Staffing and continuity | The product keeps evolving after v1 |
Staff augmentation | Delivery management | Recruitment and replacement | You have an engineering lead and a skill gap |
Fixed cost feels safer and is more expensive. You pay a premium for certainty, and on eCommerce projects involving ERP integration, requirements always move — which means every improvement arrives as a change request with an invoice attached. Choose it when your scope is truly settled, not because uncertainty is uncomfortable. There is a fuller breakdown in our guide to engagement models.
Nine Red Flags
A quote arrives within 24 hours with no discovery call
The portfolio shows designs but no systems
They cannot or will not name the engineers who would build it
SEO is described as something to handle after launch
Discovery is offered free — careful scoping work has a cost, and free discovery is a sales call wearing a lab coat
A day rate is quoted but scope stays vague
Payment is front-loaded above 40%
Code ownership is not mentioned in the proposal
Every answer is yes
Number nine is the one to weight heaviest. A team that has built enough commerce platforms has opinions, and some of those opinions will contradict your brief. A vendor who agrees with everything has either not thought about your problem or has decided that winning the contract matters more than the outcome.
A Real Evaluation: Industrial Distributor Rebuild
Mullen Equipment is an industrial equipment distributor with over seventy-five years of history, selling into chemical, pharmaceutical and process industries. Their site had accumulated content for years without a structural plan, and the gap between what the business could actually do and what the website communicated had widened with every product line added.
For technical buyers — procurement engineers, plant managers — a disorganised site is not merely an inconvenience. It is evidence. It suggests the supplier may not be the detail-oriented partner needed for a long-term equipment relationship.
The brief that mattered was not "redesign the website." It was a structural rebuild of how content was organised, presented and managed, with the finished platform working as a sales tool for a specific type of technical buyer. Six-plus product categories restructured around how a procurement engineer actually searches.
The evaluation lesson: a vendor selected on visual portfolio would have delivered a better-looking version of the same problem. The requirement was information architecture, and that is an engineering competency rather than a design one. Scorecard dimension two — commerce domain fluency — is what would have surfaced that difference during selection.
Frequently Asked Questions
How do I choose an eCommerce development company in India?
Score vendors on six dimensions rather than comparing day rates: engineering depth, commerce domain fluency, integration track record, migration and SEO discipline, delivery model, and commercial terms. Meet the engineers who would build your platform before signing, verify claims through reference calls and by auditing their clients' live sites, and confirm that IP assignment vests at payment milestones. Allow three to five weeks for the process.
What questions should I ask before hiring an eCommerce development company?
The most revealing are: who exactly will write this code and can I meet them; how does your pricing engine handle a contract rate and a promotion together; what happens when the ERP is down during a sale; what is not included in this quote; and what would you tell me not to build. That last question separates advisors from order-takers more reliably than any other.
Are Clutch and GoodFirms reliable for finding an eCommerce partner?
They are reliable for shortlisting and unreliable for deciding. Star ratings cluster near five across the whole category. What is useful is the project descriptions inside the reviews — check whether the work described resembles your work, whether reviews are recent, and whether reviewers are named with verifiable roles. Reference calls should decide, not directory scores.
Should I hire a freelancer or an eCommerce development company in India?
Hire a freelancer for scope under roughly ₹2 lakh involving a single skill. Hire a platform agency for ₹2–12 lakh of standard hosted commerce work. Hire a development company above ₹12 lakh, or at any budget where the build involves ERP integration, account-level pricing or custom checkout logic — those need more than one discipline working together, which is where individual contributors break down.
Who owns the code when an agency builds my eCommerce store?
It depends entirely on your contract, and the default in many Indian agreements is worse than buyers assume. Insist that IP assignment vests at each payment milestone rather than at project completion, and that you have repository access from day one. Assignment at completion means an abandoned or disputed project leaves you owning nothing.
How do I verify an eCommerce development company's claims?
Three methods, in ascending order of usefulness. Read project descriptions rather than star ratings in directory reviews. Request two references, one recent and one at least two years old, and ask what they had to fix after launch. Then audit three of their live client sites yourself — run PageSpeed Insights on mobile, check for product structured data, and go through the checkout. A consistent pattern across three sites tells you the vendor's real baseline.
What are the biggest red flags when hiring an eCommerce developer?
A quote within 24 hours with no discovery, inability to name the engineers who would build it, SEO treated as a post-launch concern, payment front-loaded above 40%, no mention of code ownership, and — most predictive of all — a vendor who agrees with every element of your brief. Experienced commerce teams have opinions, and some of them will contradict what you asked for.
How much should I pay upfront to an eCommerce development company?
Between 20% and 40% at kickoff is standard in India. Above 40% shifts most of the risk to you before any working software exists. Structure the remainder against milestones with written acceptance criteria you sign off individually, and tie IP assignment to those same milestones so ownership tracks payment.
What should a good eCommerce development proposal include?
An itemised scope with integrations named individually, a discrete line for data migration, performance targets expressed as numbers, a defined discovery phase, a sprint-level timeline including UAT, an explicit list of what is excluded, code ownership terms, and a post-launch handover deliverable. A proposal with a single line reading "eCommerce website development" is not a proposal.
How long should choosing an eCommerce development company take?
Three to five weeks for a build above ₹12 lakh: one week to write a specified brief, one to two weeks for vendor conversations and technical calls, one week for reference checks and independent verification, and a final week for commercial negotiation. Compressing this below two weeks is where most poor selections happen, and the time saved is trivial against a platform you will run for five years.
Where This Leaves You
The instinct in vendor selection is to look for reassurance. The better instinct is to look for specificity.
A vendor who names the ERPs they have integrated, describes a project that went wrong, tells you which part of your brief is premature, and agrees to IP assignment at milestones has given you evidence. A vendor who is confident, agreeable and ₹4 lakh cheaper has given you a feeling. Both are pleasant conversations. Only one of them predicts what the platform will be like in year three.
Run the scorecard. Ask the fourteen questions. Make the reference calls. It costs three weeks and it is the cheapest insurance available on a decision you will live with for five years.
If you want a second pair of eyes on proposals you have already received, we will score them against this framework and tell you where the gaps are — including on our own proposal, if we submitted one. We would rather lose a pitch to a better-matched vendor than win one we are wrong for. As an eCommerce development company in India building custom platforms, B2B portals and marketplaces, most of what we work on arrives from businesses whose first build was chosen on price.
Related reading
Get In Touch Now
View More Our Blog
