Hire Shopify Developers in India

Why Is Shopify Developer the Hardest Title on a CV to Read?

Shopify has the lowest entry floor of any commerce platform in wide use. Anyone who has bought a Theme Store theme, changed the colours, installed six apps and launched a store can call themselves a Shopify developer, and thousands of people do. The platform is built that way on purpose. It is supposed to let a merchant get trading without an engineer. The side effect is that the title tells you almost nothing about what the person can do, and the difference between the two ends of the range is enormous.

The floor is a weekend and the ceiling is a different job

At one end sits somebody who is fluent in the admin. They know which app does subscriptions, they can configure a discount, they can rearrange sections in the theme editor. That is a real skill and plenty of merchants need exactly that person. At the other end sits somebody who writes Shopify Functions in Rust, models a catalogue in metaobjects, ships an embedded app against the Admin GraphQL API and knows why a webhook handler has to be idempotent. Both answer to the same job title. Only one of them can do the work you are probably hiring for, and the CV rarely makes it obvious which you are talking to.

Shopify constrains you in a way WordPress does not

This is where the comparison people reach for breaks down. On WordPress, if the platform will not do something, you write the code and it does it, and the only real limit is your own discipline. Shopify is a hosted platform with walls. You cannot query the database. You cannot run arbitrary code in the request path of a page view. You cannot rewrite checkout markup. You get the extension points Shopify chose to give you, and you get them in the shape Shopify chose to give them. That constraint is genuinely good for reliability and genuinely infuriating the first time it blocks a requirement.

Which means the valuable hire is not the one who says yes to everything. It is the one who knows where the walls are, tells you before the estimate rather than after it, and can propose the version of your requirement that fits inside the platform. Somebody who has only worked on the configuration side has never been anywhere near a wall, so they say yes to everything and discover the wall in week four, usually with your launch date attached to it. If you want the same problem examined on a platform with the opposite failure mode, look at what happens on WordPress, where there are no walls at all and the discipline has to come entirely from the team.

What a portfolio of storefronts proves

Not very much, unfortunately. A beautiful store might be a heavily configured paid theme with good photography, and there is no way to tell from the outside. Open the source and you can make a better guess. Look for whether sections carry sensible schema, how many third-party scripts load before anything renders, whether product data is coming from metafields or from a wall of hard-coded HTML in the template. Better still, ask the candidate which parts of a store they wrote and which came with the theme. The honest ones separate the two without being pushed, and that answer alone sorts most shortlists.

Price signals are unreliable here too

Configuration work and engineering work are quoted from the same pool, and the market has not separated them. You can pay a serious rate for somebody who will solve your problem with three overlapping apps, and you can find a genuine Liquid engineer buried in a marketplace listing under an unhelpful headline. The only reliable filter is a technical conversation about the specific platform, which is why the interview section further down this page is longer than the sales pitch.

Liquid, Theme Architecture and Why Just Edit the Theme Breaks

Liquid is Shopify template language. It renders on Shopify servers, it has no access to a database, and it deliberately cannot do arbitrary computation. You get objects the platform hands you, a set of filters and tags, and loops with limits. Developers arriving from PHP or JavaScript find it restrictive for about a fortnight and then stop noticing, because most storefront logic really is presentation.

Online Store 2.0 changed the unit of work

Older themes had fixed page templates written in Liquid, so every layout change was a code change. Online Store 2.0 moved the storefront to JSON templates: a file that lists which sections render on a page and in what order, with each section living in its own file with a schema describing its settings. Merchandisers reorder those sections in the theme editor. Section groups extend the same idea to the header and footer, so an announcement bar or a campaign navigation variant no longer needs a developer at all.

Blocks are where the real design work sits. A section that accepts blocks gives your team repeatable, reorderable units rather than forty flat settings, and app blocks let an installed app render inside a section without anybody editing theme files. The judgement a good developer makes is simple to state and hard to do well: anything a merchandiser will want to change more than once becomes a setting, anything structural stays in code, and the schema is named in the words your team uses about the store rather than the words the developer used in the template.

The theme update problem, which is the real answer to just edit the theme

Here is the thing that catches most merchants. When you update a Theme Store theme, Shopify installs a fresh copy of the vendor code. Your settings and content mostly survive because they live in JSON. Your edits to Liquid files do not, because those files are replaced by the new versions. If your developer solved every requirement by opening the nearest template and typing into it, you now have a choice between staying on an old theme forever or paying somebody to redo the work by hand, and they have to find it first.

The way out is architectural and it has to be decided at the start. Keep customisation in your own sections and snippets rather than in the vendor files. Push content into metafields and metaobjects so it is data rather than markup. Where a vendor file genuinely must change, keep the diff small and write down what and why. Ask a candidate what happens to their customisations on an update and listen for whether they have actually lived through one. The ones who have will bring up the diff without prompting.

Forks, paid themes and the question nobody asks early enough

There are three states a store can be in and they are maintained completely differently. A Theme Store theme lightly configured can be updated more or less on demand. A Theme Store theme heavily forked cannot, and pretending otherwise wastes a quarter. A custom theme built from Dawn or from scratch has no upstream at all, which sounds worse and is often simpler, because there is nothing to merge and one team owns everything. Establishing which of the three you have is the first question on any scoping call, because it determines whether the next twelve months are maintenance or archaeology.

Tooling that tells you something about the candidate

Ask how they work locally. The Shopify CLI runs a theme development server against a real store with hot reload, and the GitHub integration syncs theme code to a branch so changes go through review instead of through the code editor in the admin. Theme Check catches Liquid and schema mistakes before they ship. A developer who edits live theme files in the admin browser is telling you something about how the rest of the engagement will go, and it is worth hearing early.

What Can You Actually Change About Shopify Checkout?

Checkout is the biggest constraint on the platform and the source of more scoping arguments than everything else combined. Shopify owns it, hosts it, optimises it and will not let you rewrite it, because it is the part of the system carrying the money and it is shared across every store. Understanding what is open and what is closed is most of what separates a Shopify developer from a web developer who has seen Shopify.

checkout.liquid is gone, and with it a decade of hacks

There used to be a file. Stores on Plus could edit it and did, sometimes wildly, and the additional scripts box on the order status page absorbed everything else: analytics tags, upsell widgets, trust badges, survey embeds. Shopify has retired that model in favour of checkout extensibility. If you inherited a store with years of accumulated checkout customisation, the migration is a project with its own audit, not a ticket, and roughly a third of what you find will turn out to be decorative and worth retiring rather than rebuilding.

Checkout UI extensions

Anything you want to appear between the cart and the thank-you page is now a Checkout UI extension. It renders into a defined extension point using a fixed component set, it runs sandboxed rather than as a script on the page, and it cannot repaint the checkout to look like your brand guidelines. Delivery date pickers, gift messages, custom order fields, subscription notices, upsells and post-purchase offers all live here. Visual branding is handled separately through checkout branding settings, which cover typography, colour and some layout, and stop well short of a redesign. The sandbox is the single most common surprise for merchants coming from a hand-built checkout, and it is better delivered in the first conversation than in week three.

Shopify Functions for anything that changes the numbers

Presentation is one thing. Changing what is charged is another, and that is what Functions are for. A Function is a small module compiled to WebAssembly, written in Rust or JavaScript, that Shopify executes inside its own infrastructure with a defined input query and a defined output. Discount Functions express promotions the native engine cannot, such as tiered thresholds across one collection with exclusions. Delivery and payment customisation Functions reorder, rename or hide methods, which is how a wholesale account stops seeing a retail courier option. Cart transform Functions expand a bundle into component lines or apply per-line pricing. Because they run server-side, the behaviour holds whether the order arrives through the online store, the Shop app or a headless front end, which is exactly what the old client-side hacks could never promise.

Functions execute under strict limits on input size and running time, which is a design constraint rather than a footnote. Ask a candidate how they would keep an input query narrow, and what they would do if the rule needs data the input does not expose. There is a real answer involving metafields on the resources the Function can see, and a wrong answer involving an external API call.

What Plus actually buys you here

Some of the checkout surfaces are gated to Shopify Plus rather than available on every plan, and the gating has moved more than once, so treat any list you read as dated and check the current Shopify documentation against your plan before you scope. The stable parts of the picture: Plus is where native B2B lives, with company accounts, buyer contacts, payment terms and catalogues carrying per-company price lists, which replaces the tag-driven wholesale pricing hacks that came before it. Plus is where several storefronts sit under one organisation, which raises its own questions about keeping theme code, metaobject definitions and app installs in step. And Plus carries higher API limits, which matters for integrations rather than for shoppers.

Payments, and the part that varies by country

Shopify Payments is not available everywhere, and where it is not, you are on a third-party gateway with its own onboarding, its own settlement behaviour and its own failure modes. Merchants selling into India, the Gulf or parts of Southeast Asia usually end up with a local acquirer alongside the platform default, and the integration work sits partly in Shopify and partly outside it. If that is your situation, our payment gateway integration services in India page covers the gateway side of the same problem in more detail.

The API Surface Your Integration Will Live On

If your brief involves an ERP, a warehouse, a PIM, a marketplace feed or a subscription engine, the theme is barely relevant and the API surface is the whole job. This is where a back-end engineer earns their place, and where a theme specialist will produce something that works in a demo and falls over on a Monday.

Admin GraphQL, and why REST is the legacy path

Shopify offers a REST Admin API and a GraphQL Admin API. Shopify has been clear that GraphQL is the path forward and that REST is the legacy surface, with newer capabilities landing on GraphQL first or only. Practically, that means any integration you commission now should be written against the GraphQL Admin API, and a candidate whose entire Shopify API experience is REST endpoints is telling you when they last did integration work. Ask what they do about bulk operations, because pulling a large catalogue page by page through the normal query path is the wrong tool and Shopify provides a bulk operation flow specifically for it.

Rate limits are calculated, not counted

This trips up developers arriving from other platforms. The GraphQL Admin API does not count your requests, it prices them. Every query has a calculated cost based on how much it asks for, you spend from a bucket that refills at a steady rate, and an expensive query costs far more than a cheap one even though both are a single call. REST uses a different mechanism again. Do not design against numbers you read in a blog post, including this one: the limits differ by plan and Shopify changes them, so check the current documentation and, more importantly, read the cost information Shopify returns in the response and back off against that rather than against a hard-coded sleep. A candidate who mentions reading the throttle status out of the response has done this for real.

Storefront API and customer accounts

The Storefront API is the read-mostly public surface for building a shopping experience outside the theme: product and collection data, cart creation and mutation, checkout hand-off. It is what a Hydrogen site queries, what a mobile app would use, and what any custom front end depends on. Customer-facing account functionality has its own newer surface, which matters if your brief includes order history, reorder flows or account portals, and it is worth asking a candidate which one they have built against, because the older approaches are being retired.

Webhooks, and why you must handle replays

Webhooks are how Shopify tells your system something happened: an order was paid, a product changed, a customer was created. Three things about them decide whether your integration is trustworthy. Verify the HMAC signature on every delivery, because an unverified endpoint is an open door into your order pipeline. Handle duplicates, because delivery is at-least-once and you will receive the same event twice, which means an order handler that appends rather than upserts will eventually double-charge somebody or double-ship something. And handle absence, because if your endpoint fails often enough Shopify will stop sending, and the failure mode is silence rather than an error. Serious integrations dedupe on the webhook identifier, make handlers idempotent, and run a reconciliation job that queries the Admin API on a schedule to catch what the stream missed. If a candidate does not raise replays and idempotency when you describe an order sync, that is the answer to the interview.

API versioning is a maintenance calendar

Shopify ships dated API versions on a regular cycle and supports each one for a defined window before it stops working. Pinning a version is correct. Pinning it and forgetting is how an integration breaks quietly about a year later, usually when the person who wrote it has moved on. Whoever owns the integration needs a recurring task to read the changelog and move the pin, and that upkeep belongs in the engagement rather than in a surprise invoice.

Why Shopify Stores Are Slow, and What Actually Fixes It

Almost nobody has a slow store because Shopify is slow. Shopify hosts the platform, runs the CDN and has strong commercial reasons to keep response times down. When a store is slow, the cause is nearly always something the merchant added, and the two biggest categories are apps and images. That is a boring answer and it is the true one.

Start by measuring the right thing

The score in the Shopify admin is a rolling average across a sample of pages and it is close to useless for debugging. So is a desktop score on a fast connection. Measure the page that matters, usually a product page, on a mid-range mobile profile on a throttled connection, and identify the largest contentful element before touching anything. Field data from real visitors beats a lab run, because your traffic is not on your laptop. Half of all performance work goes wrong because somebody optimised the page that was already fine.

Images, which are usually the largest contentful element

Shopify CDN will resize and reformat on request, so there is no excuse for a 2400 pixel hero being served to a 390 pixel phone. Use the image URL filters to request appropriate sizes, produce a proper srcset with width descriptors, set explicit width and height so the layout does not shift while loading, and preload only the hero. Everything below the fold is lazy-loaded. A single carousel eagerly loading five full-size slides can be most of your problem, and fixing it takes an afternoon.

The app tax and the render budget

Every storefront script has a cost, and the ones added by apps are usually loaded on every template because that is the easy install. Move app embeds to the templates that need them, remove the apps nobody uses, and check whether two of them are shipping the same library. On the Liquid side, watch loops. Iterating over a large collection to compute something, or fetching related products by looping over the catalogue, spends server render time in a way the CDN cannot fix. Slow time-to-first-byte on a Shopify page is almost always the theme doing too much per request.

The screening question that reveals method

Ask how they would debug a product page that takes four seconds on mobile. The answer you want is a sequence, not a fix. Reproduce on a throttled mobile profile, open the waterfall, separate server time from render time, identify the largest contentful element and what is blocking it, attribute every third-party request to an app, then change one thing and measure again. The answer that should worry you is a list of tools they would install, particularly if a speed optimisation app is on it. Adding a script to make a page faster is a strange plan and it goes wrong often enough to be a genuine signal.

What Should You Ask a Shopify Developer in an Interview?

Four questions will sort almost any Shopify shortlist, and you do not need to be technical to run them. The signal you want is simple. Has this person lived inside the platform, or only read about it?

How would you add a custom field to a product without an app?

Covered above, and it is the fastest filter there is. Metafield definition, correct type, admin input, rendered in the template with a conditional. If the reply names an app, you are talking to a configurator. If the reply also mentions where the definition should live so it is reusable across a product type, you are talking to somebody who has maintained a catalogue rather than launched one.

What happens to your theme customisations when the theme updates?

This separates people who have owned a store for two years from people who have launched several and left. You want to hear that direct edits to vendor files are replaced, that the defence is keeping work in your own sections and snippets and in metafields, and that any unavoidable change to a vendor file gets recorded so it can be reapplied. A confident nothing happens is wrong, and worth knowing early.

Walk me through debugging a product page that takes four seconds on mobile

You are testing method, not knowledge. Good answers reproduce first, measure on a realistic device profile, separate server time from front-end time, attribute third-party requests to specific apps, and change one variable at a time. Weak answers jump to a solution in the first sentence, and the solution is usually installing something.

When would you tell a client not to go headless?

The best question on the list, because it tests judgement and honesty at once. You want somebody who reaches for the merchandising cost immediately: the theme editor disappears, every layout change becomes a deploy, and a small team without front-end engineering capacity will regret it. A candidate who is enthusiastic about headless in every situation is optimising for the interesting project rather than for your store, and that tendency does not stop after they are hired.

One non-technical question worth adding

Ask how they would hand a change over to a marketing team that does not write code. The answer reveals whether they build settings or hard-code values, whether they document, and whether they think of your team as the eventual owner of the work or as people who will keep raising tickets. Developers who cannot answer this are the ones whose work becomes a permanent dependency.

How We Screen and Place Shopify Engineers in India

Our screening is run against the platform rather than against a language, because strong PHP or React on a CV predicts very little about whether somebody can build a section a merchandiser can operate.

The theme exercise

Candidates get a real theme and a merchandising requirement, and we watch where they put the code. Editing a vendor template directly is a fail on its own. What we read afterwards is the schema: are the setting labels written in the language a marketing manager uses, are blocks used where the content repeats, does the section degrade sensibly when a setting is left empty. Whether it renders is the least interesting part of the review.

The second round, chosen against your brief

For an integration role, a paginated Admin GraphQL query with a discussion of query cost and how they would back off when throttled, plus a webhook handler that survives a duplicate delivery. For a checkout or promotions role, a discount Function against a written rule, with attention to what the input query asks for. For an operations role, a slow product page and a think-aloud debugging session. One of these, not all three, because the point is the job you are hiring for.

Written English, because this job is written

Across a timezone gap, most communication is a pull request description, a ticket comment or an end-of-day summary. We read what candidates write, not just how they speak, because a developer who cannot explain a trade-off in three clear sentences will cost you more in clarification than they save in code.

Why the timeline is short

Engineers are kept on the bench rather than recruited once a brief arrives, which is the whole reason the dates work. Matching against your requirement runs within 48 hours, and most engagements are working in your store within 7 days of that. Nobody is being recruited against your brief, which is what removes the usual wait between deciding to hire and somebody actually starting.

Access, Ownership and What Happens If It Is Not Working

Three questions worth settling before the first commit rather than at the point you need the answer.

Access, and giving less of it than you are about to

Shopify has two ways to let an outsider in and the difference matters. A staff account consumes a seat on your plan and belongs to your organisation. A collaborator account is requested by the developer using a code you control, does not use a seat, and can be revoked by you at any time without asking anybody. For agency and contractor work the collaborator route is usually the right one. Either way, grant only the permissions the work needs, keep two-factor authentication enforced, and review who still has access every quarter, because the account nobody removed is a recurring theme in the stores we are asked to clean up.

Who owns the theme code, the app code and the data

You do. Who owns the output, what stays confidential, and how the customer records held inside Shopify are treated all get settled in writing before a first branch exists, and that wording is something worked out with you rather than presented to you. The stronger protection is structural though. Theme code sits in your repository. Custom app code sits in your repository and deploys onto infrastructure you pay for. Nothing accumulates in a private copy somewhere you cannot look.

When the engineer is not the right fit

Everyone asks about this and most answers are deliberately soft, so here is the plain one. Should the engineer placed with you turn out to be wrong for the work, you get a replacement inside 48 hours, and the shortlist belongs to you rather than one name being presented as the answer. Raising it early costs nothing and is far cheaper than three months of hoping it settles down.

Getting out cleanly

Plan for the engagement ending, because one day it will. The thing that protects you is not a clause. It is that everything happened in daylight from the first week: your repository, your Shopify organisation, your app infrastructure, decisions recorded somewhere you can find them, and a document listing which theme settings your team now controls and where each custom surface lives. On that footing a handover is a walkthrough and an afternoon. Without it, a handover is an investigation. Notice and handover terms get settled with you at the point the engagement is set up, so nothing about them is assumed on this page.

Frequently Asked Questions