An evaluation checklist for choosing a Shopify app development partner in India: criteria, first-call questions, red flags, contract and IP points, and what a proper handover looks like.
India has more Shopify developers than any founder can evaluate, and the range in quality is wide. Some are excellent engineers who happen to be priced in rupees; some are a sales team in front of a rotating bench. Both have polished websites and a portfolio. The difference shows up months later, when a Shopify API version is deprecated or the developer who wrote the app has moved on and nobody else can deploy it.
We wrote earlier about the seven engineering questions that separate a real team from a demo. This post is the companion: how to run the evaluation itself, what a first engagement should look like, the points that are specific to contracting in India, and what you should be holding when the work is done.
Decide what you are buying before you compare anyone
Partners are optimised for different things, and comparing a product studio against a staffing company is how you end up with the wrong one at the right price. Be clear about which of these you need:
- A public app for the Shopify App Store, where listing review, billing, onboarding and support for strangers are most of the work.
- A private or custom app for your own store, where the job is a specific workflow and the audience is your team.
- Storefront work, such as theme customisation or a headless build, where design and performance matter more than backend engineering.
- Ongoing capacity, a retainer for a queue of small changes, where reliability and responsiveness matter more than any one deliverable.
A partner who has shipped a public app understands billing APIs, listing review and support at scale. One who mostly does theme work will be faster and cheaper on a storefront. Ask which they have actually done, and ask to see it running.
The evaluation criteria that matter
Strip the pitch away and you are evaluating five things. Technical depth on the Shopify platform specifically, not web development in general: the Admin GraphQL API, webhooks, app extensions, OAuth, rate limits. Engineering discipline: automated tests, a release process, monitoring. Continuity: who does the work and whether they will still be there next year. Communication: whether you get straight answers in plain language and a written record of decisions. And commercial clarity: a scope you both understand, a price attached to it, and a stated process for changes.
Weight them for your situation. A public app that will bill hundreds of merchants needs the discipline and depth more than anything. A one-off storefront project can lean on communication and price. But continuity matters in every case, because Shopify does not stand still and neither will your requirements.
Then check references properly. Ask for two past clients and call them rather than reading the testimonial. The useful questions are not whether the work was good but what happened afterwards: how quickly a production issue was picked up, whether the same developer was still answering a year later, and whether the client could have moved the work elsewhere if they had wanted to. A partner who cannot produce a client willing to take that call is telling you something.
Questions to ask on the first call
- Who, by name, will write the code, and can I speak to them before signing?
- Show me a Shopify app you built that is live today. What broke in the last year and how did you find out?
- Which Shopify API version are your apps on, and when did you last upgrade one?
- How do you test before a release, and what runs automatically?
- What will I receive at the end: source, deployment, documentation, credentials?
- If we stop working together, how long would another developer need to make a safe change?
- What is your process when I ask for something you think is a mistake?
- How is the work priced, and what happens when the scope changes?
The value is less in the answers than in how they are given. A good partner answers specifically, admits what they have not done, and pushes back on at least one thing you say. A weak one agrees with everything and promises a date before understanding the problem.
Red flags worth walking away from
- No live product or client store they can show running. Screenshots are not evidence.
- A quote before any discovery, particularly a low one. It means the scope will be discovered during the build, at your expense.
- Refusal to name the individual developers, or a team that changes between the sales call and the kick-off.
- Everything runs on their accounts: the Shopify Partner organisation, the hosting, the domain, the repository. That is a lease, not a purchase.
- No mention of testing, monitoring or API versioning unless you raise it.
- Reviews that are all five stars and all sound alike.
- Pressure to sign a long retainer before a single deliverable has shipped.
India-specific points to settle in writing
Working with an Indian partner, whether you are in India or abroad, involves a few points that are easy to leave implicit and painful to argue about later.
- Intellectual property: in India, copyright in work done by an independent contractor stays with the contractor unless it is assigned in writing. The contract needs an explicit assignment of all code, designs and documentation to you, effective on payment.
- Invoicing: a registered partner will issue GST invoices. If you are an Indian business, check the GST registration and the SAC code so your input credit works; if you are abroad, confirm how export invoicing and currency are handled.
- Withholding: Indian clients paying an Indian vendor for professional services usually need to deduct TDS at source. Agree whether quoted prices are before or after it.
- Accounts and access: the Shopify Partner organisation that owns the app, the hosting account, the code repository and the domain should be in your name, with the partner added as a collaborator or staff member. Reversing this later is disruptive.
- Data: if the app handles customer data, India's Digital Personal Data Protection Act applies alongside Shopify's own requirements. Ask how customer data is stored, where, and for how long.
- Time zones: if your team is in the US or Europe, agree the overlap hours and the response time for production issues in writing. The gap is manageable when it is planned and frustrating when it is not.
How to structure the first engagement
Do not begin with the big project. Begin with a paid discovery of a week or two, whose deliverable is a written statement of the problem in your words, the proposed solution, the scope of a first version, and a fixed price and timeline for it. If the discovery output is vague, you have learned what you need for a small fee. If it is sharp, you have a plan that a second partner could also quote against.
Then build the smallest complete version. One workflow, end to end, in production, with monitoring, rather than half of five features. Pay on milestones tied to working software you can see in your own store, not on calendar dates. Keep the change process simple: a written request, an estimate, a yes or no. This is how we run engagements at LeelaRam Technologies, and it is also how we would want to be engaged if we were the client, because it puts the first real evidence on the table within weeks.
On pricing model, a fixed price suits a scope that discovery has made clear; time and materials suits ongoing work where the queue changes weekly. Be wary of a fixed price for an undefined scope, which is a guess dressed as a commitment, and of open-ended hourly billing with no estimate, which shifts all the risk to you. Whichever you choose, agree what happens when the scope changes before it does.
What a good handover looks like
The engagement is not finished when the app works. It is finished when you could hand the whole thing to a different developer and they could ship a change safely. Concretely, that means:
- The complete source in a repository you own, with a history of commits, not a zip file.
- A written deployment process that someone else can follow from a clean machine to a running app.
- Environment configuration and secrets documented, stored in your accounts, and rotated at handover.
- The automated tests, and instructions for running them.
- Monitoring and alerting pointed at an address you control.
- A short architecture note: what the app does, which Shopify APIs and webhooks it depends on, and which API version it is on.
- A list of known limitations and the next things the partner would do, in their own words.
A partner who is happy to provide all of this is a partner who is confident you will stay because the work is good, not because leaving is hard. That, more than any price or portfolio, is the thing to select for.
