What to Look for When
Hiring an eCommerce
Developer in Chennai

The only evidence of eCommerce development capability that actually transfers to your project is a live store that has processed real Indian orders. Staging environments show that the developer completed the build. Mockups show that the designer produced visuals. Neither demonstrates that the payment integration works under real transaction conditions, that the order management system processes correctly, that the GST invoices generate in the right format, or that the store has survived a real traffic spike.

When asking for portfolio stores, apply three specific filters: the store must be live on a public URL (not a password-protected staging link), it must be an Indian store processing Indian orders (not an international store with Stripe or PayPal only), and it must be less than 24 months old (Shopify's platform has changed significantly and an older build does not demonstrate current knowledge).

For each portfolio store provided, spend 10 minutes testing it yourself. Open it on your mobile phone and go through the checkout flow. Add a product to the cart. Check what payment options appear at checkout - if UPI and COD are not prominently displayed, the store has not been configured for Indian buyers specifically. Check how fast the store loads on your mobile data - if it takes more than 4 seconds to show product images, the developer has not optimised for Indian mobile performance. Check whether a WhatsApp contact option is visible on the homepage without scrolling.

Shopify's Partner Program is a free enrollment that any developer can join by creating a Partner account at partners.shopify.com. The presence of a Partner account does not by itself guarantee quality - anyone can create one in 10 minutes. What Partner status reveals is the development store count, the number of live stores transferred to paying clients, and the partner tier (Associate, Partner, or Plus Partner). These metrics are visible in a developer's Partner dashboard and a serious developer will have no hesitation showing you this dashboard during a call.

What Partner Program enrollment does provide is access to development stores, Shopify's partner resources, early access to new Shopify features, and the ability to access Shopify's built-in store review tools. More importantly, it provides a Shopify Partner ID that you can use to verify the developer's identity and track record through Shopify's partner ecosystem.

A developer who claims to have built 20 Shopify stores but cannot show you their Partner dashboard with 20 transferred stores has almost certainly either built the stores incorrectly (without using the development store workflow that shows up in Partner metrics) or is exaggerating their portfolio. Asking to see the Partner dashboard is a simple, non-confrontational way to verify claims.

For Indian eCommerce builds specifically, Shopify Partner status also indicates access to Shopify's India-specific payment gateway documentation and the Shopify Razorpay integration support that Partners receive. Developers without Partner status are building Indian stores with less access to official Indian payment integration resources.

In 2021, Shopify released Online Store 2.0, a fundamentally redesigned theme architecture that replaced the older, less flexible theme structure used by most Shopify stores built before 2022. The new architecture is based on app blocks, section everywhere, JSON template files, and the Dawn reference theme. The difference for a business owner is significant: Online Store 2.0 stores are significantly faster, more customisable without code, and receive ongoing Shopify performance improvements. Stores built on old theme architecture are slower, less flexible, and progressively less supported.

The majority of Shopify developers in Chennai who have been building stores for 3 to 5 years have a portfolio primarily of pre-2.0 stores. If asked, they may say they "know Shopify" without clarifying that their experience is primarily with the older architecture. Asking specifically about Online Store 2.0 and the Dawn theme reveals immediately whether the developer has updated their knowledge to the current standard or is building new stores on outdated architecture.

For the business owner, the question to ask is: "Are you building on Shopify Online Store 2.0 with the Dawn theme as a base, and what customisations do you typically make to the JSON template files?" A developer with current knowledge will answer this specifically. A developer primarily experienced with older themes will either not know what JSON template files are or will say they use a different premium theme from before 2021.

Every Shopify developer in India knows that Razorpay is the primary Indian payment gateway. Installing the Razorpay Shopify app takes 15 minutes and requires no development skill. What distinguishes a developer with genuine Indian payment integration knowledge is whether they understand and have configured the operational components that make the integration work reliably under real transaction conditions.

The five payment integration depths that separate a capable Indian eCommerce developer from one who just installed an app:

• Razorpay webhook configuration for order status synchronisation: When a buyer completes a UPI payment and closes the browser before the redirect, the order status in Shopify may not update automatically without correct webhook configuration. A developer who has configured Razorpay webhooks has solved this problem. A developer who has only installed the app has not - and "missing orders" after UPI payments is one of the most common post-launch problems in Indian Shopify stores.
• UPI intent flow configuration for mobile: There are two UPI flows in Razorpay: UPI collect (sends a collect request to the buyer's UPI app) and UPI intent (directly opens the buyer's UPI app). Intent flow converts significantly better on mobile. A developer who understands this has configured intent flow. A developer who has not will use whichever option appears by default.
• COD configuration with pin code serviceability filtering: Cash on Delivery cannot be enabled for all pin codes uniformly. The store must check whether the buyer's pin code is serviceable by the shipping partner before displaying COD as an option. A developer who has built Indian eCommerce stores will describe this immediately when asked. One who has not will say COD is simply a payment option to toggle on.
• Payment failure handling that preserves the order: Indian payment flows have a higher failure rate than Western markets due to UPI authentication issues, bank server timeouts, and app switching. A developer who understands this builds explicit order recovery flows. One who does not leaves buyers at a failed payment screen with no path forward.
• EMI and Buy Now Pay Later configuration: For stores with products above Rs 3,000, offering EMI options through Razorpay significantly increases conversion rate. This requires specific Razorpay configuration beyond the basic payment app. Ask whether the developer has configured EMI for any previous stores.

Three India-specific compliance areas distinguish an eCommerce developer who has actually built Indian stores from one who has built stores in India without understanding Indian requirements. A developer who cannot explain their approach to all three has not completed a production-ready Indian eCommerce build.

GST invoice compliance: Every Indian eCommerce business registered under GST must generate invoices with the correct format: GSTIN of the seller, HSN codes per product category, correct CGST and SGST split for intra-state transactions, IGST for inter-state transactions, invoice numbering in the financial year format, and the buyer's GSTIN for B2B transactions where they need to claim input tax credit. Ask the developer: "How do you configure GST calculation and invoice generation? Can you show a sample invoice from a previous store?" The answer should be specific and demonstrable.

COD flow configuration: COD (Cash on Delivery) is not simply a payment option to toggle on. Correct Indian COD configuration requires: pin code serviceability check before displaying COD as an option, a separate order confirmation message for COD orders (different from prepaid), a COD order management workflow for the business owner, and COD reconciliation in the backend. A developer who says "COD is just another payment method" has not configured it correctly for Indian logistics.

DPDP Act compliance: India's Digital Personal Data Protection Act 2023, with rules notified in November 2025, requires cookie consent management, a privacy policy, and data handling procedures for any Indian website collecting visitor data - which includes every eCommerce store with checkout, analytics, and marketing pixels. A developer who is not aware of DPDP Act requirements is building stores that do not meet India's current data protection legal standard.

A developer who can build a fast, well-configured Shopify store but has no understanding of eCommerce SEO is building a store that will depend on paid advertising for every order indefinitely. eCommerce SEO for Indian stores is a distinct skill from general website SEO. Product pages need structured data markup so Google can display price, availability, and rating directly in search results. Category pages need unique content beyond just a grid of products. URL structures need to follow Indian buyer search patterns (e.g., "buy-handmade-diyas-online" rather than "product-category-12").

The specific eCommerce SEO knowledge to look for:

• Product schema markup configuration (can they implement Product, Offer, and AggregateRating schema for Shopify products?)
• Category page meta title strategy for Indian buyer intent ("Buy Brass Diyas Online India" rather than just "Diyas")
• Canonical URL handling for Shopify product variant pages (a common technical SEO problem in Shopify stores)
• Collection page content strategy (unique text content on category pages, not just a filtered product grid)
• Image optimisation for both performance and image search (WebP format, descriptive alt text with Indian search terms)

Ask the developer: "How do you handle product schema markup in Shopify, and how do you approach category page SEO for Indian search intent?" A developer with genuine eCommerce SEO knowledge will describe their approach to structured data and explain the difference between how Indian buyers search for products versus how products are typically named by sellers.

For a Chennai business, a developer who is available and responsive during Indian Standard Time business hours (9AM to 7PM IST) is fundamentally different from one who is not. When a payment processing issue occurs during a Friday evening sale, an unresponsive developer creates direct revenue loss with every hour of delay. This matters regardless of whether the developer is based in Chennai, Bangalore, or remotely.

The specific post-launch support expectations that should be documented before any engagement:

• Response time for critical issues (payment failures, checkout errors, orders not processing): This should be 2 to 4 hours maximum during IST business hours. Any developer who cannot commit to this for a paid support period is not an appropriate choice for a store that processes orders continuously.
• Response time for standard issues (layout bugs, content updates, product configuration): 24 to 48 hours is a reasonable expectation. More than 48 hours for standard issues indicates a developer who is either overcommitted or not treating your project as an active account.
• Support duration included with the project: At minimum 30 days, ideally 60 days, of post-launch support should be included as part of the project scope before any additional maintenance contract is required.
• Communication channel: WhatsApp is the Indian standard for business communication. A developer who only communicates via email during Indian business hours is creating unnecessary friction for urgent issues.

Any developer who provides these commitments only verbally during a sales call and resists putting them in the project contract is a developer who is not intending to honour them. Written terms in a contract are the only terms that exist.

A single developer who is the only person with admin access to your store and the only person who can fix issues is a single point of failure for your business. When that developer is sick, on vacation, working on a larger project, or simply unreachable, your eCommerce store has no technical support. For Indian eCommerce businesses where a Diwali sale or a weekend flash sale generates a significant portion of monthly revenue, a 24-hour technical support blackout during peak sales has direct, measurable financial consequences.

This is not an argument against individual developers as a category. It is an argument for understanding the continuity structure before hiring. The questions to ask:

• "If you were unavailable for a week, who would handle critical support requests for the stores you manage?"
• "Do you work with other developers or is this a solo operation?"
• "Who has access to the store admin besides you, and will that person be available if you are not?"
• "Have you ever had a situation where a client's store had a critical issue while you were unavailable? How was it handled?"

An individual developer who has a clear answer to these questions - a backup developer colleague, a documented escalation process, shared access documentation - is a lower risk than one who has no answer because they have never considered it. A team or agency, by definition, has more continuity built in than a solo developer.