DEV Community: Rishabh Sethia

Shopify Speed Optimization: How We Improved Core Web Vitals and Boosted Conversions

Rishabh Sethia — Thu, 30 Jul 2026 04:30:01 +0000

FloraSoul India had a problem that's more common than most D2C founders realise: a visually stunning Shopify store with a mobile conversion rate that didn't reflect the quality of the product or the brand.

When they came to us, the store had been live for several months. Traffic was healthy. The product photography was excellent. The brand story was compelling. But mobile conversion sat below 1%.

We ran the audit. Within 20 minutes, we'd identified four issues that any experienced frontend engineer would spot immediately. None of them required a redesign. None required switching themes or moving to headless. They required clean engineering — the kind that page builder tools and agency generalists tend to leave undone.

The outcome: +41% mobile conversion lift after fixes were shipped. This tutorial walks through exactly what we found, why each issue mattered, and the specific code fixes we applied.

The Diagnostic Stack We Use

Before writing a single line of fix code, we run a structured diagnostic. Three tools, in order:

1. Google PageSpeed Insights — Field data (CrUX) shows real-user performance. Lab data shows what's fixable. The "Opportunities" and "Diagnostics" sections are your starting point. Always test the product page URL, not just the homepage — product pages are where mobile conversion happens.

2. Shopify Theme Inspector — A Chrome extension that profiles Liquid template render time section-by-section. It tells you which parts of your theme are slow to render on Shopify's servers, before a single byte hits the browser. Most developers never use this. It's the Shopify-specific tool that cuts hours off a performance audit.

3. Chrome DevTools Performance tab — For deep INP and long task analysis. Record a typical user interaction (page load → product page → add to cart) and review the flame chart. Long tasks blocking the main thread for 50ms+ are your INP killers.

As a Shopify Partner, we also have access to Shopify's internal theme performance guidelines — which give us a higher ceiling on what "optimised" actually means for a given theme architecture.

Issue 1: Render-Blocking Animation Library

What we found: FloraSoul's theme was loading an animation library (animate.css + a custom JS animation controller) synchronously in the <head> of theme.liquid. The library was being used for subtle product card entrance animations — a nice visual touch, but not critical to the page rendering path.

Why it matters: Scripts and stylesheets loaded synchronously in <head> block the browser from rendering anything below them until they've fully downloaded, parsed, and executed. On a mobile device on a 4G connection, a 180KB animation library can add 1.2-2 seconds to Time to First Contentful Paint. The user stares at a blank screen.

The fix: We moved the animation script to load with defer, which tells the browser to download it in parallel but not execute it until after the page has parsed. We also lazy-loaded animate.css via a <link rel="preload"> with onload swap:

<!-- Before: blocking -->
<link rel="stylesheet" href="animate.min.css">
<script src="animations.js"></script>

<!-- After: non-blocking -->
<link rel="preload" href="animate.min.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="animate.min.css"></noscript>
<script src="animations.js" defer></script>

Result: FCP dropped by approximately 1.4 seconds on mobile. The animations still work — they initialise ~300ms after page paint, which is imperceptible to users.

Issue 2: LCP Image Not Preloaded

What we found: The hero product image on every product page — the Largest Contentful Paint element — was being loaded as a regular <img> tag with loading="lazy". This is one of the most common LCP performance mistakes we encounter, and it directly contradicts Google's guidance.

Why it matters: loading="lazy" tells the browser to defer loading this image until it's near the viewport. For the LCP image, which is by definition in the viewport on load, this delays the most important paint event on the page. Combined with no preload hint, the browser discovers the LCP image only after it has parsed the full HTML — wasting critical connection time.

The fix: We identified the LCP image in the product template (sections/main-product.liquid) and added an explicit preload hint in the <head> and removed loading="lazy" from the primary image:

{% comment %} In theme.liquid <head>, injected via section schema: {% endcomment %}
{% if template == 'product' %}
  <link
    rel="preload"
    as="image"
    href="{{ product.featured_image | img_url: '1200x' }}"
    imagesrcset="{{ product.featured_image | img_url: '400x' }} 400w,
                 {{ product.featured_image | img_url: '800x' }} 800w,
                 {{ product.featured_image | img_url: '1200x' }} 1200w"
    imagesizes="(max-width: 768px) 100vw, 50vw"
  >
{% endif %}

And in the product image template, the primary image:

<img
  src="{{ product.featured_image | img_url: '800x' }}"
  srcset="{{ product.featured_image | img_url: '400x' }} 400w,
          {{ product.featured_image | img_url: '800x' }} 800w,
          {{ product.featured_image | img_url: '1200x' }} 1200w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="{{ product.featured_image.alt | escape }}"
  width="800"
  height="800"
  fetchpriority="high"
  {%- comment %} No loading=lazy on LCP image {%- endcomment %}
>

Secondary images in the gallery kept loading="lazy" since they're below the fold.

Result: LCP on mobile moved from 4.1 seconds to 2.3 seconds — crossing the "Good" threshold for the first time.

Issue 3: Oversized Product Images Without srcset

What we found: All product images were being served at their original upload resolution — averaging 2400x2400px at 1.8MB per image. Mobile devices were downloading desktop-sized images and then scaling them down via CSS. On a product page with 6 images, that's over 10MB of image data downloaded before the user has seen a single product detail.

Why it matters: Image weight is the single largest contributor to slow LCP and high Total Blocking Time on Shopify product pages. Shopify's CDN serves WebP automatically, but it serves the full resolution unless you specify a resize in the URL. Without srcset, every device gets the largest image.

The fix: We applied srcset across all product image elements (the gallery, thumbnails, and zoom view), using Shopify's built-in image URL filter to request device-appropriate sizes:

{%- for image in product.images -%}
  <img
    src="{{ image | img_url: '600x' }}"
    srcset="{{ image | img_url: '300x' }} 300w,
            {{ image | img_url: '600x' }} 600w,
            {{ image | img_url: '1200x' }} 1200w"
    sizes="(max-width: 480px) 90vw,
           (max-width: 900px) 50vw,
           40vw"
    alt="{{ image.alt | escape }}"
    width="600"
    height="600"
    loading="{% if forloop.first %}eager{% else %}lazy{% endif %}"
  >
{%- endfor -%}

Note the forloop.first logic: the first image gets loading="eager" (matching the fetchpriority="high" LCP fix), all subsequent gallery images get loading="lazy".

Result: Median image payload on product pages dropped from 10.2MB to 1.4MB on mobile. Visible page weight in DevTools Network tab went from 12.8MB to 2.1MB total for an average product page load.

Issue 4: Third-Party Tracking Scripts Firing Synchronously

What we found: FloraSoul had five tracking integrations installed: Facebook Pixel, Google Analytics 4, a heatmap tool, an email capture popup, and a WhatsApp chat widget. All five were being injected into <head> as synchronous scripts, either by apps or by manual snippet additions to theme.liquid.

Why it matters: Each synchronous third-party script is a single point of failure for your entire page render. If any one of these services has a slow response (which happens regularly with ad tracking endpoints), your page waits. Combined, five synchronous tracking scripts were adding 800ms-1.2 seconds of network round-trip time before the browser could paint anything.

The fix: We consolidated all third-party scripts under Google Tag Manager with the GTM container loading async. Within GTM, we configured all tags to fire on DOM Ready or Window Loaded events, not Page View. This decouples the tracking instrumentation from the critical rendering path entirely:

<!-- In theme.liquid <head>: only GTM loads here -->
<script>
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');
</script>

All five tracking scripts were then moved into GTM and configured to fire post-render. The WhatsApp widget in particular was set to trigger only after the first user interaction (click event), eliminating its zero-interaction load cost entirely.

Result: Total Blocking Time dropped from 1,840ms to 290ms on mobile — crossing the "Good" threshold. The INP score moved from "Needs Improvement" to "Good" across most user sessions.

The Combined Result

These four fixes shipped over two development sprints. No redesign. No theme switch. No Hydrogen migration (our comparison of Liquid vs Hydrogen architecture covers when that conversation becomes relevant). Just clean engineering on an existing Liquid store.

Before:

Mobile LCP: 4.1s
Total Blocking Time: 1,840ms
Image payload per product page: 10.2MB
Mobile PageSpeed score: 31

After:

Mobile LCP: 2.3s
Total Blocking Time: 290ms
Image payload per product page: 1.4MB
Mobile PageSpeed score: 78

Business outcome: +41% mobile conversion rate lift over the following 8 weeks. FloraSoul also saw a +28% improvement in average order value, which we attribute partly to faster load enabling users to browse more products per session.

What To Do Next For Your Store

If you want to run this same diagnostic on your store, start with our full Shopify SEO checklist — it covers all the CWV items in audit format with a priority ordering for which fixes to address first.

If you'd rather have our team do it, we offer full Shopify performance audits and implementation through our Shopify development service. We use the exact diagnostic process and fix patterns above on every store we touch. As a DPIIT-recognised startup and official Shopify Partner, we combine the credibility of a verified agency with the technical depth of an engineering team that has shipped 50+ production Shopify builds.

Frequently Asked Questions

How much does Shopify speed optimisation cost?
For a targeted performance fix project (similar to the FloraSoul engagement), typical scope runs 2–3 weeks of development work. For a combined audit + implementation engagement, budget 3–4 weeks. Exact scope depends on theme complexity and number of third-party integrations installed.

Will speed optimisation affect my store's design?
Not if done correctly. The four fixes in this tutorial — deferring scripts, preloading LCP images, implementing srcset, and consolidating trackers into GTM — are invisible to end users. The store looks and feels identical. Only the performance metrics change.

My PageSpeed score is 30 on mobile. Is that fixable without changing themes?
In most cases, yes. A score of 30 typically indicates one or more of: render-blocking scripts, oversized images, no LCP preload, or heavy third-party payloads. All of these are fixable in your existing theme. We've seen stores go from 28 to 74 without a single design change.

What's the difference between PageSpeed score and Core Web Vitals?
PageSpeed Insights shows both. The score (0–100) is a lab-based synthetic measurement useful for benchmarking. Core Web Vitals (LCP, INP, CLS) are field data metrics pulled from real Chrome user sessions — this is what Google uses for ranking. Both matter, but CWV is the more important one for SEO.

Does page speed directly affect Shopify conversion rates?
Yes. Google's own research shows conversion rates drop approximately 12% for every second of mobile load time after the first second. For a mobile-first market like India — where most shoppers are on 4G connections and mid-range Android devices — page speed is one of the most direct levers on conversion you can pull.

Should I use a Shopify speed optimisation app?
Most "speed optimisation" apps add more script weight than they remove. The legitimate fixes require code access — modifying theme.liquid, section templates, and image rendering logic. These aren't things an app can do safely at scale. Avoid apps that promise PageSpeed score improvements through automatic optimisation. Do the engineering work instead.

Rishabh Sethia — Founder & CEO of Innovatrix Infotech. Former Senior Software Engineer and Head of Engineering. DPIIT Recognised Startup. Shopify Partner.

Originally published at Innovatrix Infotech

Mobile-First Design in 2026: Why It's No Longer Optional

Rishabh Sethia — Wed, 29 Jul 2026 09:30:01 +0000

Mobile-first design isn't a trend anymore. In India, it's the baseline. Here's why it matters more in 2026 than ever, and what it actually means in practice.

The Numbers

In India:

75%+ of web traffic comes from mobile devices
85%+ of e-commerce purchases happen on mobile
Average mobile screen size: 5.5-6.5 inches
Average internet speed: 30-50 Mbps (4G), but significant 3G usage in Tier 2/3 cities

Your website's primary user is a person on an Android phone with a 6-inch screen. Design for that person first.

What "Mobile-First" Actually Means

"Mobile-first" is often misunderstood. It doesn't mean:

Making a desktop site responsive
Hiding elements on mobile
Building a separate m.yoursite.com

It means:

Designing for mobile constraints first, then progressively enhancing for larger screens
Prioritizing content and actions that mobile users actually need
Optimizing performance for slower connections and smaller processors
Touch-first interactions (no hover states as primary UI)

Core Mobile-First Design Principles

1. Thumb-Friendly Tap Targets

The average thumb is 2.5cm wide. Minimum tap target: 44x44 pixels. Buttons, links, and form fields should all meet this minimum. Navigation items especially — small touch targets are the most frustrating mobile experience.

2. Single-Column Layouts

Most content should be single-column on mobile. Two-column grids compress poorly on 360px wide screens. The exception: product cards in a 2-column grid can work if the cards are simple.

3. Progressive Disclosure

Don't try to show everything at once. Use expandable sections (accordions) for FAQs, specifications, and secondary content. Show primary content, let users request more.

4. Fast Load Times

Mobile users on 4G expect pages to load in under 3 seconds. Every 100ms of additional load time reduces conversions by ~1%. For Indian users on mixed 4G/3G:

Compress all images to WebP
Lazy load below-fold images
Minimize JavaScript bundle size
Use a CDN (Cloudflare handles this)

5. Bottom Navigation for Apps

For mobile apps and PWAs, primary navigation belongs at the bottom of the screen (where thumbs reach). The top navbar is for secondary navigation and search.

6. Native Mobile Features

Click-to-call for phone numbers
Click-to-WhatsApp for support links
Location services for local/delivery features
Camera for QR codes, AR try-on, document upload

7. Form Design for Mobile

Use appropriate input types: type="tel" for phone, type="email" for email (summons right keyboard)
Make form fields at least 48px tall
Place labels above fields, not inside (placeholder text disappears when typing)
Auto-advance to next field after completion where logical

Common Mobile Design Mistakes

Text too small: Body text below 16px is unreadable on mobile. Use 16-18px for body, 20-24px for subheadings.

Horizontal scroll: Any element wider than the viewport causes horizontal scrolling. Overflow hidden is not the fix — responsive layout is.

Desktop navigation on mobile: Hamburger menus are acceptable, but dropdown megamenus never work well on mobile. Simplify navigation for mobile users.

Pop-ups at page load: Full-screen pop-ups that trigger immediately on mobile are a Google ranking signal and a user experience disaster. Use bottom sheets or slide-ins instead.

Non-responsive tables: Data tables don't work on small screens. Use horizontal scroll, card layout, or hide secondary columns on mobile.

Need expert help? Innovatrix Infotech builds mobile-first web solutions for businesses across India. Get a free consultation.

Originally published at Innovatrix Infotech

How to Build a Custom Shopify App: Step-by-Step for Developers in 2026

Rishabh Sethia — Mon, 27 Jul 2026 09:30:02 +0000

How to Build a Custom Shopify App: Step-by-Step for Developers in 2026

Most Shopify app tutorials teach you how to build a public app for the Shopify App Store. That's useful if you want to build a SaaS product — but most agencies and in-house teams need custom apps: private apps built for a single store that solve a specific business problem.

This guide covers both. Whether you're a developer who knows JavaScript/Node.js but has never touched Shopify, or an ecommerce operator evaluating whether to build or buy — this is the walkthrough we wish existed when we started building Shopify solutions.

Public vs. Custom Apps: The Distinction That Changes Everything

Public apps are listed on the Shopify App Store. They go through Shopify's review process, need to handle multi-tenant authentication, and can be installed by any merchant. Revenue comes from app subscriptions via Shopify's Billing API.

Custom apps (formerly "private apps") are built for one specific store. They're created directly in the store's admin under Settings > Apps and sales channels > Develop apps. No review process, no App Store listing, no multi-tenant complexity.

When to build custom:

Your store needs functionality no existing app provides
You want full control over data flow and no third-party dependency
The logic is specific to your business (custom order tagging, vendor-specific workflows, bespoke reporting)
You need to integrate Shopify with internal systems (ERP, custom CRM, warehouse management)

When to buy from the App Store:

The functionality is commodity (reviews, email popups, countdown timers)
Multiple apps compete in the space (competition drives quality)
The total cost of ownership for building exceeds 12 months of app subscription fees
You don't have a developer or agency on retainer

Setting Up Your Development Environment

Prerequisites

Node.js 18+ (LTS recommended)
npm or yarn
A Shopify Partner account (free at partners.shopify.com)
A development store (create one from your Partner dashboard)

Step 1: Install Shopify CLI

npm install -g @shopify/cli @shopify/app

Verify the installation:

shopify version

You should see version 3.x or later. The CLI handles app scaffolding, local development tunneling, and deployment.

Step 2: Scaffold Your App

shopify app init

The CLI will prompt you to choose:

App template: Choose the Remix template (Shopify's recommended framework since 2024) or the Node.js template if you prefer Express-style architecture.
Language: TypeScript is recommended for anything beyond a weekend project.
App name: Something descriptive — you can change this later.

This creates a project with:

OAuth authentication flow (already configured)
App Bridge integration (for embedding in Shopify admin)
Prisma ORM for database operations
A basic admin UI using Polaris components

Step 3: Start Local Development

cd your-app-name
shopify app dev

This spins up a local server, creates a secure tunnel (via Cloudflare), and opens your development store with the app installed. Every code change hot-reloads.

Building a Real App: The Order Tagger

Let's build something practical: an app that automatically tags orders based on custom rules. For example, tag orders over ₹5,000 as "high-value," tag orders containing specific products as "gift-bundle," and tag repeat customers' orders as "returning."

This is a common need that most store owners solve with Shopify Flow (if they're on Plus) or with paid apps. Building it custom gives you full control.

Step 4: Register Webhooks

Webhooks are how Shopify tells your app that something happened. For order tagging, you need the orders/create webhook.

In your app's webhook configuration (typically shopify.app.toml):

[webhooks]
api_version = "2026-01"

  [[webhooks.subscriptions]]
  topics = ["orders/create"]
  uri = "/webhooks/orders-create"

Step 5: Handle the Webhook

Create a webhook handler that processes incoming orders:

// app/routes/webhooks.orders-create.tsx
import type { ActionFunction } from '@remix-run/node'
import { authenticate } from '../shopify.server'

export const action: ActionFunction = async ({ request }) => {
  const { topic, shop, payload } = await authenticate.webhook(request)

  const order = payload
  const tags: string[] = []

  // Rule 1: High-value orders
  if (parseFloat(order.total_price) > 5000) {
    tags.push('high-value')
  }

  // Rule 2: Repeat customer
  if (order.customer?.orders_count > 1) {
    tags.push('returning-customer')
  }

  // Rule 3: Gift bundle detection
  const hasGiftProduct = order.line_items?.some(
    (item: any) => item.product_id === YOUR_GIFT_PRODUCT_ID
  )
  if (hasGiftProduct) {
    tags.push('gift-bundle')
  }

  // Apply tags via GraphQL
  if (tags.length > 0) {
    const client = new shopify.clients.Graphql({ session })
    await client.query({
      data: {
        query: `mutation orderUpdate($input: OrderInput!) {
          orderUpdate(input: $input) {
            order { id tags }
            userErrors { field message }
          }
        }`,
        variables: {
          input: {
            id: `gid://shopify/Order/${order.id}`,
            tags: tags
          }
        }
      }
    })
  }

  return new Response('OK', { status: 200 })
}

Step 6: Handle Rate Limits

Shopify's API uses a leaky bucket algorithm for rate limiting. For REST, you get 40 requests per app per store, replenishing at 2 per second. For GraphQL, it's a cost-based system with 1,000 points, replenishing at 50 per second.

In production, implement retry logic:

async function shopifyRequest(fn: () => Promise<any>, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await fn()
    } catch (error: any) {
      if (error.response?.code === 429) {
        const retryAfter = parseFloat(
          error.response.headers['retry-after'] || '2'
        )
        await new Promise(resolve =>
          setTimeout(resolve, retryAfter * 1000)
        )
        continue
      }
      throw error
    }
  }
  throw new Error('Max retries exceeded')
}

For bulk operations (syncing hundreds of products, processing historical orders), use Shopify's Bulk Operations API instead of paginated queries. It runs asynchronously and doesn't count against rate limits.

Metafields vs. Metaobjects: Custom Data Storage

Metafields attach key-value data to existing Shopify resources (products, orders, customers). Use them for simple data like cost-per-unit, vendor tags, or custom attributes.

mutation {
  metafieldsSet(metafields: [
    {
      ownerId: "gid://shopify/Product/123456789"
      namespace: "custom"
      key: "cost_per_unit"
      value: "450.00"
      type: "number_decimal"
    }
  ]) {
    metafields { id key value }
    userErrors { field message }
  }
}

Metaobjects are standalone data entities with their own schema. Use them when you need structured data that doesn't naturally belong to a product or order — vendor profiles, custom lookup tables, configuration objects.

The rule of thumb: if the data describes something that already exists in Shopify (a product, a customer), use Metafields. If it's a new concept your store needs to track, use Metaobjects.

App Bridge: Embedding in Shopify Admin

App Bridge 3 lets your app render inside the Shopify admin as a seamless embedded experience. The Remix template includes this by default, but understanding the key concepts helps:

Navigation: Your app gets a left-nav item in the Shopify admin. Each route in your Remix app maps to a page within that navigation.

Session tokens: App Bridge handles authentication via session tokens instead of cookies. This means your app works in the embedded iframe without third-party cookie issues.

Polaris components: Shopify's design system. Using Polaris ensures your app looks native and follows Shopify's UX patterns. Don't fight it — merchants expect consistency.

The Billing API: Charging Merchants

If you're building a public app, Shopify takes a revenue share (currently 0% for the first $1M in annual revenue, then 15%). You charge merchants through the Billing API:

mutation {
  appSubscriptionCreate(
    name: "Pro Plan"
    returnUrl: "https://your-app.com/billing/callback"
    lineItems: [
      {
        plan: {
          appRecurringPricingDetails: {
            price: { amount: 29.99, currencyCode: USD }
            interval: EVERY_30_DAYS
          }
        }
      }
    ]
  ) {
    appSubscription { id }
    confirmationUrl
    userErrors { field message }
  }
}

For custom apps, billing is handled directly between you and your client — no Shopify involvement.

Hosting Your App in Production

For custom apps serving a single store, hosting requirements are modest:

AWS Lambda + API Gateway: Serverless, pay-per-invocation. Ideal for webhook-driven apps like our Order Tagger. As an AWS Partner, this is our default recommendation for lightweight custom apps. Cold starts can add 1–2 seconds to the first request, but for webhook processing this is rarely noticeable.

AWS App Runner: Container-based, always-warm. Better for apps with admin UIs that merchants interact with regularly. Starts at ~$5/month for a minimal instance.

Heroku or Railway: Simpler deployment, higher per-unit cost. Good for prototyping, less ideal for production apps that need to scale.

Vercel: If you chose the Remix template, Vercel deployment is nearly zero-config. The free tier handles most custom apps comfortably.

Build vs. Buy: Total Cost of Ownership

Before building anything, run this calculation:

Build cost:

Development time × developer rate (20–80 hours for a simple app)
Hosting cost per month ($5–$50)
Maintenance time per month (2–5 hours for updates, Shopify API version bumps)

Buy cost:

App subscription × 12 months
Customization limitations (workarounds, manual processes)
Data dependency (what happens if the app shuts down?)

If building costs less than 18 months of subscription fees AND gives you meaningfully better functionality, build. Otherwise, buy.

For most stores, the breakeven point is around $150–$200/month in app subscription costs. Below that, buying is almost always more efficient. Above that — especially if you're paying for multiple apps that a single custom app could replace — building starts making sense.

What's Next

Once you've built your first custom app, the natural extension is connecting it with your broader web development stack. Custom apps become the glue between Shopify and your internal systems — syncing inventory with your warehouse, pushing order data to your accounting software, or triggering custom workflows that no off-the-shelf app supports.

If you're evaluating whether to build or buy for your specific use case, book a discovery call. We'll scope the project honestly and tell you if a $15/month app store solution does the job better.

Building a custom Shopify app and need architecture guidance? Talk to our team — we've built custom apps for stores across India, Dubai, and Singapore.

Originally published at Innovatrix Infotech

I'm Building a Tech Company Where AI Does All the Marketing

Rishabh Sethia — Thu, 23 Jul 2026 04:30:01 +0000

Six months ago, someone I trusted walked out of this company.

They didn't just resign. They took everything. Client contact lists, project documentation, relationships we'd spent two years building. The kind of thing that could end a company.

I had a choice: rebuild quietly, or rebuild publicly.

I chose publicly. And I chose to do it without a marketing team.

No growth hacker. No content strategist. No social media manager. No agency. Not even a freelancer on retainer.

Just me, a 12-person engineering team, and AI.

And it's working.

The Problem With How Most Tech Companies Market Themselves

Most tech companies do one of two things:

Hire a marketing team they can't yet afford and burn cash trying to outspend competitors
Do nothing and hope referrals carry the business forever

Neither made sense for me.

I'm a former Senior Software Engineer. I ran engineering teams. I know how to build systems. And when I looked at content marketing, SEO, and lead generation — I realised it's a systems problem, not a creativity problem.

Systems are something I can build.

What AI-Powered Marketing Actually Looks Like

When I say AI does all the marketing, I mean this literally.

Every blog post on this site was planned by AI. Researched by AI. Written by AI — using our content operating system, a structured framework that embeds our real case studies, our technical opinions, and our company credentials into every piece of content.

The AI publishes directly to our CMS via an MCP (Model Context Protocol) connection. No copy-paste. No manual formatting. The pipeline goes from strategy → research → draft → publish in one continuous flow.

The AI automation workflows powering our marketing are the same class of workflows we build for clients — n8n pipelines, Make.com automations, custom Python logic. We are our own case study.

The SEO strategy was built using AI-assisted keyword research, competitor gap analysis, and topical authority mapping. I reviewed it. I made the strategic decisions. But the legwork? AI.

This doesn't mean I'm absent. It means I'm upstream.

What I Actually Do

I architect the strategy.

I decide which topics to cover and why. I define our positioning. I review content before it publishes. I flag anything that doesn't sound like us.

I also feed the machine with real data. Our actual case studies. Our real pricing. Our honest opinions about tools and platforms. The AI can write. It cannot replace the decades of engineering experience that make the content credible.

There's a critical distinction between AI-generated content and AI-executed content. Generic AI content reads like no one wrote it. Our content reads like a technical founder wrote it — because a technical founder directed every word.

The managed services model we offer clients — where we become their outsourced tech team — is essentially what we're doing ourselves. AI is the execution layer. I'm the principal.

The Technical Architecture

For anyone curious about the actual stack:

The content system runs on a structured prompt framework with 4 stages: research (web search, competitor gap analysis), interrogate (real experience extraction), create (draft using brand voice and EEAT guidelines), and publish (direct to Directus CMS via MCP).

Each blog post triggers an Unsplash image search, downloads the asset, uploads it to the Directus file library, and attaches it to the post — automatically. The post is saved as draft, not published live, so I retain final review.

The internal linking strategy, category mapping, and meta tag optimisation are all handled within the same pipeline. What previously required a 3-person content team now requires one strategist and a well-built system.

As a DPIIT-recognised startup, we had to demonstrate genuine innovation in our application. This content pipeline is part of what we pointed to. It's not just a marketing trick — it's a proof of concept for the kind of AI automation work we do for clients.

The Numbers So Far

I'll be transparent about where we are:

50+ clients served since founding, growing from zero after the reset
FloraSoul India: +41% mobile conversion lift after speed engineering fixes
Baby Forest India: ₹4.2 lakh launch-month revenue on a store built in under 3 weeks
Zevarly: +55% session duration, +33% repeat purchase rate
Blog content ranking for targeted keywords in under 6 weeks of publication
Inbound inquiries from Dubai and Singapore from content published 3 weeks ago

The content machine is spinning up. Organic leads are starting to come in from markets we'd never reached before — without a rupee of paid media.

Why This Matters If You're a Founder

The question I'm asking myself — and that every founder should ask — is this: how much of your company's output requires human judgment, and how much requires human execution?

Most marketing execution doesn't require human judgment. Research, drafting, formatting, publishing, SEO mechanics — these are pattern-recognition and synthesis tasks. AI handles them well.

What requires human judgment: strategy, authentic story, brand voice, reading the market, deciding what NOT to say.

If you've been avoiding content marketing because you can't afford a team, that excuse doesn't hold anymore in 2026. The tools exist. The frameworks exist. What's required is a founder willing to build the system instead of just doing the tasks.

The Full Story

I'm rebuilding a company that someone tried to take from me.

I'm doing it without a marketing budget. Without the relationships that were stolen. Without the years of client history that disappeared overnight.

But I have the engineering skills built over a career. I have a team of 12 developers who build things properly. I have DPIIT recognition as a verified Indian startup. I have real results from real clients who trusted us.

And I have AI.

This comeback story isn't finished. But it's being written — post by post, page by page, workflow by workflow.

If you want to understand how we're building our AI automation systems, our Shopify development practice, or anything else about how Innovatrix Infotech operates — the blog is where to start.

Frequently Asked Questions

Can AI actually replace a marketing team?
Not entirely. AI is excellent at execution: research, drafting, publishing, SEO mechanics. What it can't replace is strategic direction, authentic experience, and the judgment call about what's worth saying. The model we run is founder-directed AI execution — not autonomous AI marketing.

What tools are you actually using for AI marketing?
Core stack: Claude for content creation (structured content operating system with 4 stages), n8n for automation workflows, Make.com for certain integrations, and Directus CMS connected via MCP. The pipeline from strategy to published draft is largely automated.

Is AI-generated content penalised by Google?
Google evaluates content quality, not how it was created. Our content performs because it contains genuine EEAT signals — real case studies, real metrics, technical insights from actual project work. Thin AI content gets filtered out. Substantive, experience-backed content performs well regardless of production method.

How much time does managing AI marketing actually take?
Currently: 3-4 hours per week of active direction-setting, review, and strategic decisions. Execution (research, drafting, publishing) is handled by the AI pipeline. That compares to a traditional content team effort of 20+ hours per week for equivalent output.

Can you build this kind of AI marketing system for other companies?
Yes. Our AI automation service builds exactly these types of content and workflow automation systems for clients. A properly built AI content pipeline is one of the highest-ROI automation investments a B2B company can make in 2026.

Rishabh Sethia — Founder & CEO of Innovatrix Infotech. Former Senior Software Engineer and Head of Engineering. DPIIT Recognised Startup.

Originally published at Innovatrix Infotech

Website Accessibility in 2026: What Indian Businesses Need to Know

Rishabh Sethia — Wed, 22 Jul 2026 04:30:01 +0000

Website accessibility in India is moving from best practice to legal requirement. The Digital Personal Data Protection Act 2023 and upcoming BIS standards are changing the compliance landscape. Here's what you need to know.

The Legal Landscape in India

Rights of Persons with Disabilities Act 2016 (RPWD Act): Section 46 requires all public-facing websites and apps to follow Web Content Accessibility Guidelines (WCAG) 2.0 Level AA. This applies to government websites mandatorily, and is expected to extend to private sector businesses.

BIS IS 17802:2021: India's national standard for web accessibility, aligned with WCAG 2.1. Increasingly referenced in procurement and compliance contexts.

WHY THIS MATTERS NOW: The Digital India initiative and upcoming consumer protection regulations are accelerating enforcement. Businesses that build accessible sites today avoid retrofit costs later.

WCAG Compliance Levels

Level A: Basic accessibility (minimum requirement)
Level AA: Standard requirement (what most regulations mandate)
Level AAA: Highest level (aspirational for most sites)

Target Level AA for compliance.

The 4 WCAG Principles (POUR)

Perceivable

Information must be presentable to users in ways they can perceive:

Alt text for all images (screen readers read this aloud)
Captions for video content
Sufficient color contrast (4.5:1 for body text, 3:1 for large text)
Text doesn't disappear when zoomed to 200%

Operable

UI components must be operable:

All functionality available via keyboard (no mouse required)
No content that flashes more than 3 times per second (seizure risk)
Skip navigation links for keyboard users
Sufficient time to complete forms (no auto-timeout on critical tasks)

Understandable

Content and UI operation must be understandable:

Language declared in HTML (lang="en")
Error messages that explain what went wrong
Form labels visible and descriptive
Consistent navigation across pages

Robust

Content must be robust enough for assistive technologies:

Valid HTML (use proper semantic elements: <button>, <nav>, <main>, not just <div>)
ARIA labels where semantic HTML isn't sufficient
No reliance on color alone to convey information

Common Accessibility Issues in Indian Sites

Low color contrast: Light grey text on white backgrounds is extremely common in Indian web design. Check every text/background combination with a contrast checker.

Images without alt text: Product images, banners, and icons frequently have missing or generic alt text ("image1.jpg").

Forms without labels: Many Indian sites use placeholder text as the label, which disappears when users start typing.

Non-semantic HTML: Buttons built with <div> and JavaScript instead of <button>. These can't be activated with keyboard.

PDFs without text layers: Scanned PDFs are completely inaccessible to screen readers.

Quick Accessibility Audit

Run these free tools:

WAVE (wave.webaim.org): Browser extension showing accessibility errors visually
axe DevTools: Chrome extension for detailed WCAG testing
Google Lighthouse: Built into Chrome DevTools > Accessibility
Contrast Checker (webaim.org/resources/contrastchecker): For color combinations

Implementation Priority

Add alt text to all images (1 day)
Fix color contrast issues (1-2 days)
Add proper form labels (1 day)
Ensure keyboard navigation works (2-3 days)
Add ARIA landmarks (1 day)
Test with screen reader (NVDA free, VoiceOver on Mac/iOS)

Need expert help? Innovatrix Infotech builds accessible, compliant web solutions for businesses across India. Get a free consultation.

Originally published at Innovatrix Infotech

Multi-Language Website Setup: Complete Guide for Indian Businesses Going Global

Rishabh Sethia — Tue, 21 Jul 2026 04:30:01 +0000

India's linguistic diversity makes multi-language websites a business necessity, not a nice-to-have. With 22 official languages and hundreds of dialects, reaching beyond English-speaking metro audiences requires localization. Here's how to do it right.

Why Multi-Language Matters for Indian Businesses

Only 10-12% of India's population uses English as their primary language
Hindi-medium internet users have overtaken English by 2x
Tier 2/3 city users prefer regional language content significantly
E-commerce conversion rates are 2-3x higher in native language

Technical Approaches

Option 1: Subdomain Structure

en.yoursite.com, hi.yoursite.com, bn.yoursite.com

Pros: Clean separation, easier CDN caching, good for SEO
Cons: More infrastructure, cookies/sessions can be complex
Best for: Large sites with full content translation for each language

Option 2: Subdirectory Structure

yoursite.com/en/, yoursite.com/hi/, yoursite.com/bn/

Pros: Domain authority consolidation, simpler infrastructure
Cons: Slightly more complex routing
Best for: Most businesses. This is Google's recommended approach.

Option 3: Query Parameters (Avoid)

yoursite.com?lang=hi

Cons: Poor SEO (Google often ignores params), bad UX, caching issues. Don't use this.

Implementation for Different Platforms

WordPress

The Polylang plugin (free) or WPML (paid, ₹10,000/year) handle WordPress multilingual well. WPML has better compatibility with WooCommerce for multilingual e-commerce.

Key steps:

Install Polylang/WPML
Add languages
Translate posts, pages, menus, and custom fields
Set up hreflang tags (WPML does this automatically)

Shopify

Shopify Markets (built-in) handles multiple languages from Shopify Admin > Markets. Supports automatic translation with some apps (Transcy, Langify). Manual translation gives better quality.

Next.js / Custom

next-i18next or next-intl for Next.js apps. Set up i18n routing in next.config.js:

i18n: {
  locales: ['en', 'hi', 'bn'],
  defaultLocale: 'en',
}

Each locale gets its own JSON translation file.

Hreflang: Critical for SEO

hreflang tags tell Google which language version to show to which users. Without them, Google may serve the wrong language version and cannibalize your rankings.

For each page, include in <head>:

<link rel="alternate" hreflang="en" href="https://yoursite.com/en/page" />
<link rel="alternate" hreflang="hi" href="https://yoursite.com/hi/page" />
<link rel="alternate" hreflang="x-default" href="https://yoursite.com/page" />

Translation Quality

Machine translation (DeepL, Google Translate) is acceptable for most content. For:

CTAs and hero copy: Use native speaker translation
Legal/compliance content: Professional translator required
Product descriptions: Machine translation + native review
Blog content: Machine + edit works for informational content

For Hindi and Bengali, ensure your font stack includes proper Unicode support. Noto Sans and Google Fonts regional families handle Indian scripts reliably.

Language Detection

Auto-detecting language from browser settings and redirecting is tempting but often annoying. Best practice:

Default to English (or Hindi for Hindi-dominant businesses)
Show a language switcher prominently
Remember language preference with a cookie
Don't auto-redirect without user confirmation

Need expert help? Innovatrix Infotech builds multilingual web solutions for businesses across India. Get a free consultation.

Originally published at Innovatrix Infotech

Shopify Theme Customization: When to Use Apps vs Custom Code

Rishabh Sethia — Thu, 16 Jul 2026 09:30:01 +0000

You need a size chart on your product pages. Do you install an app (₹500/month forever) or pay a developer ₹5,000 once for custom Liquid code? This decision, multiplied across 15–20 features, is the difference between a ₹6,000/month app bill and a lean, fast store.

Most Shopify store owners don't think about this until their monthly app bill crosses ₹10,000. By then, they're locked into a dozen apps, their store loads in 6+ seconds, and they're bleeding money on features that could have been built natively.

Let's fix that.

The App Bloat Problem

Every Shopify app you install adds JavaScript to your storefront. Some add a lot. Here's what happens when you stack 10–15 apps on a single store:

Load time increases by 2–5 seconds. Each app injects its own scripts, stylesheets, and sometimes iframes. Your theme might load in 1.8 seconds on its own, but with 12 apps, you're looking at 4–6 seconds.
Monthly costs compound. That "just ₹300/month" app doesn't feel like much until you have 15 of them. Suddenly you're spending ₹4,500–₹8,000/month on apps alone — more than your Shopify plan.
Conflicts and bugs. Apps modify your theme's DOM. Two apps targeting the same page element will break each other. Debugging this is a nightmare.
You lose control. App developers can change pricing, discontinue features, or shut down entirely. Your store's functionality depends on third parties you don't control.

This isn't hypothetical. We've audited stores spending ₹12,000/month on apps where 60% of the functionality could have been replaced with one-time custom code costing ₹30,000 total.

When Apps Make Sense

Apps aren't the enemy. For certain use cases, they're the right choice.

Install an app when:

The functionality is complex and evolving. Email marketing (Klaviyo), reviews with photo/video UGC (Judge.me), subscription management (Recharge) — these are entire products. Building equivalent functionality from scratch would cost lakhs and require ongoing maintenance.
You need it yesterday. Launching a flash sale tomorrow and need a countdown timer with inventory urgency? Install an app. Speed matters more than optimization when revenue is on the line.
The app handles compliance or security. Cookie consent, GDPR compliance, tax calculation — these involve legal requirements that change. Let specialists handle them.
It integrates with external services. Shipping calculators that pull real-time rates from carriers, accounting sync with Tally or Zoho — these need maintained API connections.
The app is free or nearly free. If a well-maintained free app solves your problem without performance impact, use it.

When Custom Code Wins

Custom Liquid code (or theme modifications) should be your default for anything that's:

Simple and static. Size charts, trust badges, custom announcement bars, FAQ accordions, additional product tabs — these are HTML/CSS with minimal logic. An app is overkill.
Performance-critical. Anything that loads on every page (header modifications, custom navigation, footer content) should be native code, not app-injected scripts.
A one-time implementation. If the feature won't change often, build it once. No monthly fees, no external dependencies.
Core to your brand. Custom product page layouts, unique collection filters, branded checkout messaging — these define your store. They should live in your theme, not in an app that 10,000 other stores also use.

The Hybrid Approach

The smartest Shopify stores use both — strategically. The framework is simple:

List every feature your store needs beyond the base theme.
Categorize each as "complex/evolving" or "simple/static."
Use apps for complex, evolving features that would cost more to build and maintain than the subscription.
Use custom code for simple, static features where a one-time build saves money within 3–6 months.
Review quarterly. Some apps you installed early on may now have native theme equivalents. Some custom code may need upgrading to an app as your needs grow.

Performance Impact: Apps vs Custom Code

We tested a store with 14 apps installed, then replaced 8 of them with custom Liquid code. Here's what changed:

Metric	With 14 Apps	After Replacing 8 with Code	Improvement
Page load time (mobile)	5.8s	2.4s	59% faster
Total page weight	4.2 MB	1.8 MB	57% lighter
JavaScript requests	38	14	63% fewer
Lighthouse Performance	34	78	+44 points
Time to Interactive	8.1s	3.2s	60% faster
First Contentful Paint	3.4s	1.6s	53% faster

That's not a marginal improvement. That's the difference between a store that converts and one that loses visitors before the page finishes loading. Google's data says 53% of mobile visitors leave if a page takes longer than 3 seconds to load. A 5.8-second load time means you're losing more than half your traffic before they see a single product.

Cost Comparison: 12-Month View

Here's what the numbers look like for common customizations over a year:

Feature	App Cost (₹/month)	App Cost (12 months)	Custom Code (One-Time)	Break-Even
Size chart	₹400	₹4,800	₹3,000	Month 8
Trust badges	₹300	₹3,600	₹2,000	Month 7
Announcement bar (advanced)	₹500	₹6,000	₹4,000	Month 8
FAQ accordion	₹350	₹4,200	₹2,500	Month 8
Product tabs	₹400	₹4,800	₹3,500	Month 9
Custom popup	₹600	₹7,200	₹5,000	Month 9
Wishlist (basic)	₹500	₹6,000	₹8,000	Month 16
Reviews (basic)	₹400	₹4,800	₹12,000	Month 30
Total (all 8)	₹3,450	₹41,400	₹40,000	—

For the first six features — size chart through custom popup — custom code pays for itself within 9 months. For wishlists and reviews, the app is cheaper unless you're planning to run the store for 2+ years without changing providers.

The sweet spot: replace simple apps with custom code, keep complex apps as subscriptions. In this example, replacing just the first 6 saves ₹19,400 in the first year and ₹28,600 every year after.

Common Shopify Customizations: App vs Code

Here's a practical decision for the 12 most common store customizations:

Customization	Recommendation	Why
Size chart	Custom code	Static content, simple implementation
Trust badges	Custom code	HTML/CSS only, no logic needed
Announcement bar	Custom code	Unless you need A/B testing or scheduling
FAQ page/accordion	Custom code	Basic HTML/JS, no ongoing changes
Product tabs	Custom code	Theme modification, one-time setup
Exit-intent popup	Depends	Simple popup = code. Smart triggers/A/B testing = app
Wishlist	App	Needs user accounts, persistence, email triggers
Product reviews	App	UGC management, photo moderation, email requests
Upsell/cross-sell	App	Needs AI recommendations, A/B testing, analytics
Email marketing	App	Entire platform, not a theme feature
Subscription/recurring	App	Payment processing, customer portal, dunning
Live chat	App	Real-time infrastructure, agent dashboard

How to Evaluate a Shopify App Before Installing

Before you click "Add app," run through this checklist:

Check the JavaScript payload. Use Chrome DevTools (Network tab) on a demo store or the app's own website. If the app adds more than 100KB of JavaScript, think twice.
Read the 1-star reviews. Not to find problems — every app has some — but to see how the developer responds. Slow or dismissive responses = avoid.
Look at the update history. An app last updated 6+ months ago on a platform that changes quarterly is a risk.
Test on PageSpeed Insights before and after. Install the app on a dev store, run Lighthouse, compare scores. If it drops more than 5 points, that's a red flag.
Calculate the 2-year cost. ₹500/month feels small. ₹12,000 over two years feels different. Compare against a one-time custom build.
Check for theme conflicts. Does the app modify your theme files directly? If yes, updating your theme later could break the app.
Verify the uninstall process. Some apps leave code snippets in your theme even after uninstall. Check their docs for cleanup instructions.

Finding a Good Shopify Developer

If you're going the custom code route, the developer matters more than the code.

What to look for:

Liquid expertise specifically. A great React developer who's never touched Shopify will struggle. Liquid is its own templating language with specific patterns.
Theme architecture knowledge. They should understand sections, blocks, schema settings, and the Online Store 2.0 structure.
Performance awareness. Ask how they'd minimize render-blocking resources. If they can't answer clearly, keep looking.
A portfolio of Shopify work. Not just "web development" — actual Shopify stores they've built or customized.

Red flags:

They want to install an app instead of writing code (for simple features).
They can't explain the difference between theme.liquid and a section file.
They quote a timeline before understanding the requirement.
They don't mention testing on mobile.
They can't provide a staging/dev store for review before pushing live.

Liquid Basics: What Non-Developers Should Know

You don't need to become a developer, but understanding Liquid at a conceptual level helps you make better decisions and evaluate proposals.

Liquid is Shopify's templating language. It lets you insert dynamic data (product names, prices, variant options) into HTML templates.

Three things it does:

Objects pull data: {{ product.title }} displays the product name.
Tags add logic: {% if product.available %} shows content only if in stock.
Filters transform data: {{ product.price | money }} formats the price with currency.

Every Shopify theme is built with Liquid files (.liquid extension). When a developer says they'll "add custom Liquid," they mean they'll edit or create these template files to add your feature directly into the theme — no external app, no extra JavaScript, no monthly fee.

The key insight: most simple customizations are just Liquid + CSS. A size chart is a Liquid snippet that renders an HTML table with CSS styling. A trust badge section is an image and text in a Liquid section with theme editor settings. These aren't complex engineering tasks.

Migration: Replacing Apps with Custom Code

If you're already running a store with too many apps, here's how to clean house without breaking anything:

Step 1: Audit your current apps.
Go to Settings > Apps and sales channels. List every app, its monthly cost, and what it does. Be specific — "adds size chart to product pages" not just "size chart."

Step 2: Categorize each app.
Mark each as "keep" (complex, evolving, worth the subscription) or "replace" (simple, static, could be custom code).

Step 3: Prioritize by cost and simplicity.
Start with the easiest, most expensive apps to replace. A ₹500/month trust badge app that's just displaying images is a quick win.

Step 4: Build replacements on a development theme.
Never modify your live theme directly. Duplicate it, build the custom replacements, and test thoroughly.

Step 5: Test everything.
Check on mobile, tablet, and desktop. Test across browsers. Verify that the custom code works with your other apps (the ones you're keeping).

Step 6: Deploy and uninstall.
Publish the updated theme, verify everything works on production, then uninstall the replaced apps one at a time. Wait 24 hours between each uninstall to catch issues.

Step 7: Clean up leftover code.
Many apps inject code into your theme files during installation. After uninstalling, check theme.liquid, product.liquid, and other templates for orphaned app snippets. Remove them.

Step 8: Run a final performance test.
Compare your Lighthouse scores before and after the migration. Document the improvement — it's satisfying, and it justifies the investment.

FAQ

Will custom code break when Shopify updates my theme?
It depends on how it's built. Code written as standalone sections and snippets (the correct approach) survives theme updates. Code that modifies core theme files may need adjustment. A good developer builds for durability.

Can I edit custom Liquid code myself?
Simple changes like updating text, swapping images, or adjusting colors — yes, if the developer builds it with theme editor settings. Complex logic changes will need a developer.

How do I know if an app is slowing down my store?
Install the app on a test/dev store and run Google PageSpeed Insights before and after. Or use Chrome DevTools' Network tab to see exactly what scripts the app loads and how long they take.

Is it worth replacing a ₹200/month app?
Do the math. If custom code costs ₹3,000, you'll break even in 15 months. If you plan to run the store for 2+ years, yes. If you might close or pivot in 6 months, keep the app.

What about Shopify's built-in features?
Shopify keeps adding native functionality (metafields, sections everywhere, built-in markets). Before installing an app or commissioning custom code, check if Shopify already does it. Many store owners are paying for apps that duplicate features Shopify added in recent updates.

Can apps and custom code coexist?
Absolutely. The hybrid approach is ideal. Use apps for complex features and custom code for simple ones. Just ensure your developer tests compatibility with your installed apps.

How long does it take to replace an app with custom code?
Simple features (size chart, trust badges, FAQ): 1–2 days. Medium complexity (custom product page layout, advanced filtering): 3–5 days. The timeline depends on the feature, not the developer's speed.

Should I replace all my apps at once?
No. Migrate one at a time, test thoroughly between each replacement, and keep your old app active until you've verified the custom code works perfectly. Rushing this process causes preventable downtime.

Want to audit your Shopify apps and identify what can be replaced with custom code? We'll analyze your store's performance and create an optimization plan. Get your free store audit

Originally published at Innovatrix Infotech

How to Use Claude Code: A Real Developer's Setup Guide (Not the Docs Version)

Rishabh Sethia — Thu, 16 Jul 2026 04:30:02 +0000

Most developers read the official Claude Code docs, install it, type a vague prompt, get confused output, and conclude the tool is overhyped.

We've been running Claude Code across a 12-person development team at Innovatrix Infotech — building Shopify stores, Next.js applications, and React Native apps for clients. What we've learned is that the tool isn't the variable. The setup is.

This guide skips everything that's already in the docs and gets straight to what actually matters.

The Installation Decision That Trips Up Most Teams

The official Anthropic documentation shows two installation paths: npm global install (npm install -g @anthropic-ai/claude-code) and the native installer.

Use the native installer. Every time.

# macOS/Linux
curl -fsSL https://claude.ai/install.sh | sh

# Or via Homebrew
brew install claude-code

The npm approach works, but it creates a dependency on your Node.js version and doesn't auto-update. When you're managing a team and you want everyone on the same version without anyone thinking about it, the native installer handles that invisibly. We switched to it across our entire team after too many "it worked for me but not for you" conversations traced back to version mismatches.

On Windows, use the PowerShell equivalent. Claude Code works on Windows 11 — avoid WSL if you can, the file system overhead is real on large codebases.

CLAUDE.md Is Not Optional — It's the Whole Game

The single highest-leverage thing you can do before writing a single prompt is investing 30–45 minutes in a CLAUDE.md file. This file lives at the root of your repository and tells Claude Code everything it needs to know about how your project works.

Here's a template we use for Next.js projects:

# Project Overview
[Client name] ecommerce platform — Next.js 15 with TypeScript, Tailwind CSS, and a headless Shopify backend via the Storefront API.

# Tech Stack
- Frontend: Next.js 15, TypeScript, Tailwind CSS
- Backend: Next.js API routes, Shopify Storefront API
- Auth: NextAuth.js
- Testing: Vitest, React Testing Library
- Deployment: Vercel

# Key Commands
- `npm run dev` — Start dev server on port 3000
- `npm run test` — Run all tests
- `npm run lint` — ESLint + TypeScript type check
- `npm run build` — Production build

# Code Standards
- Functional components only — no class components
- Named exports preferred over default exports
- Tailwind utility classes only — no custom CSS files
- All API calls must go through `/lib/api/` — never call Shopify directly from components

# Key Architecture
- `/app` — App Router pages and layouts
- `/components` — Shared UI components (atomic, no business logic)
- `/features` — Feature-specific components and hooks
- `/lib` — API clients, utilities, type definitions

# Workflow Rules
- Create feature branches before any changes
- Run tests before committing
- Never modify `/lib/api/shopify.ts` without testing against staging first

What makes a CLAUDE.md file actually useful isn't length — it's precision. The Anthropic best practices docs put it well: for each line, ask whether removing it would cause Claude to make mistakes. If not, cut it. An overly long CLAUDE.md is worse than a concise one because Claude loses track of the important rules buried in the noise.

One pattern we've adopted: run /init on a new repo first to get an auto-generated CLAUDE.md baseline, then heavily edit it down. The auto-generated version catches things you'd forget to document but tends to be verbose.

The Explore-Plan-Code-Commit Workflow

The docs mention this workflow. What the docs don't emphasize enough is that Plan Mode is the difference between Claude Code being useful and Claude Code being dangerous on a shared codebase.

Before Claude touches any code in a session:

Explore: Point Claude at the relevant files and ask it to explain what it sees before doing anything. Critical on projects you inherited.

Plan: Switch to Plan Mode (Shift+Tab twice from Normal Mode — it cycles through Normal → Auto-Accept → Plan Mode). Ask Claude to plan the change, then read the plan. If the plan touches files you didn't expect, ask why.

Code: Let Claude execute. Review the diff before accepting anything that touches shared components.

Commit: Commit after each logical change, not at the end of a long session. If Claude made a mistake, you want a clean revert point.

The most expensive mistake we've made with Claude Code is running it in Auto-Accept mode on a shared component that cascaded changes through 20 files. The fix took longer than the original task. Plan Mode would have caught it in 30 seconds.

MCP Servers: Where Claude Code Becomes a Real Workflow Tool

The native Claude Code installation gives you the ability to connect MCP (Model Context Protocol) servers, which give Claude direct access to your development environment. For a web agency, the practical wins here are significant.

For our Directus CMS work, we connect an MCP server so Claude Code can read the schema, query collections, and understand the full data structure when writing API integration code — without us having to copy-paste schema dumps into every prompt.

To add an MCP server, edit .claude/settings.json:

{
  "mcpServers": {
    "directus": {
      "type": "url",
      "url": "https://your-cms.domain.com/mcp?access_token=YOUR_TOKEN"
    }
  }
}

For Shopify work, MCP servers connect to the Partner API. For Next.js projects with a database, connecting Supabase or Postgres via MCP means Claude Code can generate correct queries against your actual schema instead of hallucinating field names.

Context Management for Long Sessions

Claude Code compresses its context window during long sessions — the equivalent of an intern who loses track of early decisions as the day goes on. Two patterns help:

Session notes: Keep a running .claude/session-notes.md that captures architectural decisions made during the session. Point Claude to this file at the start of any continuation session.

Worktree isolation: For complex features that require parallel work, Claude Code supports git worktrees with the --worktree flag. Each worktree gets an isolated context, which prevents debugging conversations from bleeding into architecture decisions.

# Start Claude in an isolated worktree for a specific feature
claude -w "implement the new product filter component"

What Nobody Tells You About Team Adoption

The hardest part of rolling Claude Code out to a team isn't the technical setup. It's calibrating what level of autonomy to grant in different contexts.

Our current framework for a 12-person team:

Greenfield features with good test coverage: Auto-Accept mode is fine. Claude has a safety net.
Shared components or library code: Plan Mode only. Review every diff.
Legacy code without tests: Explore only — never let Claude auto-edit legacy code without a human reviewing the plan in detail.
New repository: Always start with /init to generate CLAUDE.md, then edit before running any tasks.

As an Official Shopify Partner and DPIIT-recognised startup, we build under real client SLAs. Claude Code is a productivity multiplier when used with discipline — and a liability when treated as autocomplete on steroids.

FAQ

Do I need a paid Claude plan to use Claude Code?
Yes. Claude Code requires Claude Pro ($20/month) at minimum. For teams, API pricing is often more cost-effective at scale.

Does Claude Code work without an internet connection?
No. Claude Code is cloud-based and requires connectivity. For air-gapped environments, look at Tabnine or self-hosted Ollama with Cline.

How do I prevent Claude Code from modifying files I don't want touched?
Add explicit rules to your CLAUDE.md: "Never modify /lib/api/shopify.ts without explicit instruction." You can also use --allowed-paths to restrict which directories Claude can write to.

What's the difference between Normal Mode, Auto-Accept, and Plan Mode?
Normal Mode asks for permission before each file edit. Auto-Accept applies edits without prompting. Plan Mode produces a plan without executing. Use Plan Mode for anything touching shared components.

Can Claude Code write tests, not just features?
Yes, and it does this well. Add a custom command in .claude/commands/write-tests.md with your testing patterns and Claude Code generates tests that match your existing test style.

Is my code sent to Anthropic and used for training?
API and Claude Code usage is not used for training by default. Verify in Anthropic's privacy documentation. Enterprise plans offer additional data processing agreements.

How does Claude Code handle monorepos?
Set CLAUDE.md at the monorepo root with workspace-level conventions, then create separate CLAUDE.md files in each package directory for package-specific rules.

What's the best way to use Claude Code for code reviews?
Point Claude at a diff: claude "review the changes in this PR for security issues and edge cases" with the diff piped in. Best at catching edge cases — pair it with ESLint for stylistic issues.

Rishabh Sethia, Founder & CEO of Innovatrix Infotech. Former SSE/Head of Engineering. DPIIT Recognized Startup.

Originally published at Innovatrix Infotech

OpenAI Codex in 2026: What It Can Do, What It Can't, and When to Use It

Rishabh Sethia — Wed, 15 Jul 2026 04:30:01 +0000

OpenAI Codex has had a genuinely interesting evolution. When it launched in April 2025, it was positioned as a cloud-based coding agent — a meaningful departure from the original 2021 Codex API that most developers know from GitHub Copilot's early days. By early 2026, it's matured enough to be a serious tool, but it's also well-defined enough that its limitations are clear.

This isn't a restatement of the official documentation. It's what the tool actually does, where it falls short, and how to decide whether it belongs in your stack.

What Codex Actually Is in 2026

Codex is a cloud-based software engineering agent. The key word is cloud-based. Unlike Claude Code (which runs in your local terminal and touches your filesystem directly) or Cursor (which is an IDE you run on your machine), Codex operates entirely in isolated cloud sandboxes. You connect your GitHub repository, queue tasks, and the agent works asynchronously in its own environment.

The current default model is GPT-5.4-Codex — OpenAI's most capable frontier model for professional work — which brings a 1M context window and native computer-use capabilities for complex, long-horizon tasks. Each task runs in a sandboxed container preloaded with your repository and configured dependencies, and you can queue multiple tasks to run in parallel. When Codex finishes, it commits its changes to a branch and provides you with a diff, terminal logs, and test results as verifiable evidence of what it did.

The March 2026 desktop app for macOS and Windows added a visual supervision layer that made managing parallel agent threads genuinely practical. Before the desktop app, the web interface worked but felt like a compromise. Now it's closer to a proper workflow.

What Codex Does Well

Batch maintenance tasks. This is Codex's strongest use case. Renaming patterns across a large codebase, updating deprecated API calls, standardising error handling, migrating configuration formats — tasks where the pattern is clear and repetitive. When there's a failing test and a clear bug description, Codex's approach of making the test pass without breaking anything else works reliably.

Background delegation. When you're in a flow state on one problem and don't want to context-switch, queuing a well-scoped task to Codex and reviewing the output later is genuinely productive. OpenAI's internal teams use this model: triage on-call issues, plan tasks at day start, and offload background work to keep focus.

PR scaffolding and documentation. Codex handles writing features, answering questions about the codebase, fixing bugs, and proposing pull requests. Task completion typically takes between 1 and 30 minutes depending on complexity, and each task runs independently in its own environment.

Parallel execution. The ability to run 4–5 tasks simultaneously is a real differentiator for certain workflows. If you're working on a multi-sprint project and want to queue several independent tickets in parallel, this is a capability neither Claude Code nor Cursor offers in the same way.

What Codex Doesn't Do Well

Real-time interactive coding. Codex isn't built for the experience of typing and having AI suggestions appear inline. The workflow is fundamentally asynchronous — you queue a task, it runs, you review the output. If you want AI assistance while you're actively writing code, this isn't the tool. Claude Code or Cursor will serve that use case far better.

Frontend work without visual context. As OpenAI themselves acknowledge, Codex currently lacks image inputs for frontend work. If you're building UI and need to match a Figma design or debug a visual layout issue, Codex can't see what you're seeing. This is a meaningful gap for frontend-heavy agencies.

Air-gapped or offline work. Every Codex task runs in a cloud sandbox with your repository preloaded. If your project can't be on GitHub, or if you're working in an environment where internet access is restricted, Codex doesn't work at all. For client projects with strict data residency requirements, this becomes a blocker.

Mid-task course correction. While recent versions improved the ability to steer tasks in progress, it's still not as fluid as Claude Code's interactive session model. Delegating to a remote agent takes longer than interactive editing, and getting used to that latency is a real behavioural shift.

Model selection control. The system routes tasks based on complexity, and you don't choose which model handles which task directly. Cursor's explicit model selection — choosing Claude Opus for architectural reasoning versus a faster model for routine work — is more transparent.

Pricing and Access in 2026

Codex is included with ChatGPT Plus, Pro, Business, and Enterprise plans. Plus users get rate-limited access; Pro and Business get more generous allocation. When you hit limits, there's a smaller model (GPT-5.4-Codex-Mini) that provides roughly 4x more usage within your subscription.

For developers building directly with the models, the API offers codex-mini-latest at $1.50 per million input tokens and $6 per million output tokens, with a 75% prompt caching discount on repeated context — which matters a lot for large codebases.

The desktop app is free with any qualifying subscription. The CLI, IDE extension, and Codex Cloud web interface are all included.

Where Codex Fits in a Real Dev Workflow

As a DPIIT-recognised startup running a 12-person team across Shopify builds, Next.js platforms, and React Native projects, we've found a clear pattern: Codex works best as a delegated background worker, not as your primary coding assistant.

The mental model that works is treating Codex like a well-briefed contractor. Give it clear, scoped tasks. Write context files that explain your project conventions. Review the output as you would a PR. Don't expect it to function as an interactive pair programmer — that's not what it was built for.

For agencies doing intensive development where time-to-review matters, combining Codex for delegated batch work with Claude Code for interactive complex sessions and Copilot for daily inline work is the stack that actually makes sense. Each tool serves a distinct role rather than competing for the same use case.

The Codex desktop app's visual dashboard, showing running, queued, and completed tasks across projects, is worth spending time with if you're considering it seriously. The workflow shift it enables — treating coding tasks like a queue rather than a stream — is real, but it requires building new habits around task scoping and review cadence.

Where This Leaves Things

Codex is a solid tool for what it does. Cloud-based async task execution, parallel work streams, auditable outputs. The fact that it runs on GPT-5.4, the same model powering OpenAI's most capable professional workflows, means the quality ceiling is high.

What it's not is a replacement for interactive AI coding tools. It occupies a specific niche: well-scoped background work that doesn't require you to be present while it runs. If that's a bottleneck in your current workflow, it's worth evaluating seriously. If you primarily need AI that helps you while you're actively coding, look at Cursor or Claude Code instead.

For dev teams interested in how we're building AI automation workflows and using tools like this in production, our Shopify development engagements often involve exactly the kind of multi-tool AI stack we've described here.

Frequently Asked Questions

Is the 2026 Codex the same as the original OpenAI Codex API from 2021?
No — they share a name but are fundamentally different. The original Codex was a code completion model powering early Copilot. The current Codex is a full cloud-based coding agent built on GPT-5.4. The 2021 model was deprecated in 2023.

Does Codex support private repositories?
Yes. You connect Codex to your GitHub account, including private repos. Tasks run in isolated sandboxes with internet access disabled during execution, so your code doesn't leave the sandbox to hit external APIs mid-task.

How is Codex different from Claude Code?
Codex is cloud-based and asynchronous — you queue tasks and review results later. Claude Code runs locally in your terminal and is interactive and real-time. Claude Code handles complex multi-step reasoning in an active session. Codex handles delegated background work in parallel. Most serious teams use both.

What happens when Codex makes a mistake?
Codex creates a new branch rather than committing to main, so mistakes are contained. It provides terminal logs, test output, and a diff for every task, giving you full visibility into what it did before you merge anything.

Can Codex work on Shopify Liquid codebases?
Yes, though you'll want detailed context files explaining your theme architecture and any Shopify-specific patterns like metafield structures and cart AJAX. Without that context, Codex may generate generic patterns rather than Shopify-native ones.

Does Codex replace a CI/CD pipeline?
No. It generates code and PRs, but your CI/CD pipeline still handles testing, linting, deployment, and approval workflows. Codex is an input to the pipeline, not a replacement for it.

Is Codex suitable for regulated industries like fintech or healthcare?
For highly regulated environments, check OpenAI's enterprise data handling agreements. Codex runs in cloud sandboxes, which means code is processed on OpenAI's infrastructure. Air-gapped deployments aren't supported. Enterprise contracts can include data processing agreements that may satisfy compliance requirements, but verify before committing.

What's the main reason teams avoid Codex?
The asynchronous workflow takes adjustment. Developers used to real-time AI assistance find the queue-and-review model unintuitive at first. If your primary need is inline code completion while actively writing, Codex isn't the right fit.

Rishabh Sethia, Founder & CEO of Innovatrix Infotech. Former SSE/Head of Engineering. DPIIT Recognized Startup.

Originally published at Innovatrix Infotech

Cursor vs GitHub Copilot vs Claude Code: The Honest Breakdown for Dev Teams

Rishabh Sethia — Tue, 14 Jul 2026 04:30:01 +0000

Three tools dominate the serious AI coding conversation in 2026: GitHub Copilot, Cursor, and Claude Code. They're not interchangeable. Choosing the wrong one creates real friction — in daily workflow, in team onboarding, in actual cost. Choosing the right one is a measurable advantage.

This comparison is based on running all three across our 12-person team at Innovatrix Infotech on real client projects — Shopify theme builds, Next.js platforms, React Native apps. Not benchmarks or press summaries. Actual use.

The short version: each tool has a different answer to the same question. What should AI actually do while a developer is working?

Copilot answers: assist, inline, everywhere. Cursor answers: understand the whole codebase, apply changes coherently. Claude Code answers: execute complex tasks autonomously, without constant oversight.

GitHub Copilot: The Universal Standard

Copilot is the original mainstream AI coding assistant — launched by GitHub (Microsoft) in 2021, now powered by a rotating selection of models including OpenAI and Anthropic models depending on task type.

Its core experience is inline autocomplete. As you type, Copilot suggests completions from single tokens to entire functions. It integrates natively across every major editor — VS Code, the complete JetBrains suite, Visual Studio 2022, Xcode, Eclipse, Neovim, Azure Data Studio — which is a genuine differentiator when you have a team using different IDEs.

Where Copilot excels:

Inline boilerplate generation: API endpoints, database queries, component scaffolding, TypeScript interfaces, test stubs
GitHub ecosystem integration: PR summaries, Autofix in Actions, Copilot Workspace
IP indemnity protection at the Business tier ($19/user/month) — a real enterprise requirement that neither Cursor nor Claude Code provides
Maximum IDE compatibility for mixed teams
Free tier available for verified students and open-source maintainers

Where Copilot falls short:

Multi-file coordination: when you need a pattern applied consistently across a codebase, Copilot's file-level focus becomes limiting. It doesn't understand how a change in one component affects the five components that consume it.
Reasoning quality on complex architectural questions lags slightly behind Claude-based tools. Not dramatically, but noticeably on hard problems.

Pricing: $10/month (Copilot Starter) or $19/month (Copilot Pro) for individuals; $19/user/month (Business) or $39/user/month (Enterprise) for teams. Included in GitHub's higher-tier organisation plans.

Choose Copilot if: Your team spans multiple IDEs, you need enterprise compliance features (IP indemnity, SSO, audit logs), you're already deep in the GitHub ecosystem, or you want the lowest-cost AI coding baseline for a larger team.

Cursor: The IDE That Understands Your Codebase

Cursor is a fork of VS Code with AI built into the core of the editor rather than bolted on as an extension. Its defining capability is codebase indexing — it semantically indexes your entire project so the AI understands relationships between files, components, functions, and patterns.

Composer mode is the feature that generates the strongest reactions from developers who switch. Describe a change, point Composer at the relevant directories, and it plans and applies the change coherently across as many files as the task requires. It understands which components consume the interfaces being modified, which tests cover the code being touched, and which utilities already implement similar patterns.

Where Cursor excels:

Multi-file refactoring and large feature work: making consistent changes across complex codebases is where Cursor is genuinely ahead
Model flexibility: you can explicitly choose which AI model handles which task (Claude Opus for architectural reasoning, a faster model for routine autocomplete)
Codebase-aware context: the difference between suggestions based on "what's in this file" versus "what's in this project" is substantial on large codebases
The /chat and inline edit experience for developers who prefer IDE-native interaction

Where Cursor falls short:

VS Code only: if any team members use JetBrains, Visual Studio, or Xcode, they can't use Cursor. This either requires a tooling split or standardising everyone on VS Code.
Code is indexed on Cursor's servers: privacy-sensitive teams may be wary, though you can opt out of training data usage
Higher cost than Copilot for the same inline autocomplete use case
Less mature enterprise compliance compared to Copilot's established SOC 2 Type 1 certification

Pricing: Pro at $20/month (individual); Teams at $40/user/month (centralised billing, privacy controls, usage analytics). The recent shift to usage-based pricing for some tiers means heavy users should check current limits.

Choose Cursor if: Your team can standardise on VS Code, you're working on large TypeScript or Next.js codebases where codebase-wide context matters, you need multi-file refactoring capabilities regularly, or you want model flexibility rather than being locked to one provider.

Claude Code: The Autonomous Agent

Claude Code is Anthropic's terminal-based coding agent. It's not an IDE extension or an autocomplete tool — it reads your entire codebase, makes multi-step changes, runs tests, commits code, and creates pull requests from natural language prompts. It operates from your terminal and touches your local filesystem directly.

The 200K context window is genuinely useful on large codebases. During extended sessions, Claude Code can maintain awareness of architectural decisions made earlier in the conversation — something that matters when you're doing a substantial refactor over multiple hours.

Where Claude Code excels:

Autonomous multi-step execution: write code, run tests, fix failures, commit, create PR — all without you reviewing every intermediate step
Complex, long-horizon tasks that require understanding how many pieces fit together
Terminal power users and agencies doing intensive autonomous development
MCP server integration: connecting Claude Code directly to your CMS, database, or internal APIs via the Model Context Protocol gives it direct access to your actual data structures rather than requiring you to paste schemas into context
GitHub Actions integration for automated PR review, issue triage, and CI-driven coding tasks

Where Claude Code falls short:

No inline autocomplete: if you want suggestions as you type in your editor, you need a separate tool alongside Claude Code
Terminal-first interface requires CLI comfort. If your team isn't comfortable in a terminal, the onboarding cost is real
Mistakes can be larger in scope: because it acts autonomously, an incorrect direction can change more than you expected before you catch it. Plan Mode (Shift+Tab to enter) and careful diff review are essential habits
No IDE integration beyond extensions for VS Code and JetBrains

Pricing: Claude Pro at $20/month for individuals; Teams plan for organisations. Heavy users doing intensive work often find the API pay-per-token model more economical than flat subscriptions.

Choose Claude Code if: You're building complex features that need autonomous multi-step execution, you lead a team where developer attention is the bottleneck, you're comfortable in the terminal, or you need the most capable agentic tool available regardless of interface.

How to Actually Pick

For most serious dev teams, the honest answer is two tools rather than one. The tools don't fully overlap.

The most common serious setup: Claude Code for autonomous task execution + GitHub Copilot for inline daily assistance = $30/month per developer. You get both paradigms at a cost below Cursor Teams.

For large Next.js/TypeScript projects where codebase context is the primary bottleneck: Cursor Pro at $20/month gives you capabilities that neither Copilot nor Claude Code's terminal interface replicates in the same IDE-native way.

For enterprise teams with compliance requirements: GitHub Copilot Business at $19/user/month is the only option with IP indemnity and mature SOC 2 certifications at this price point.

For agencies doing intensive work: The combination we run on real client projects — Claude Code for heavy autonomous lifting, Copilot for daily inline coding, Cursor for sessions where codebase-wide context matters most — is the highest-capability setup. The total per-developer cost at this combination is higher, but the velocity gains on complex multi-sprint projects justify it.

The choice between these tools isn't primarily about which one is "best." It's about which friction points are most expensive in your current workflow, and which capability gap costs you the most time.

For teams we work with on Shopify builds and Next.js platforms, the answer depends on the project complexity, team IDE preferences, and whether autonomous execution or codebase-wide intelligence is the bigger bottleneck.

Frequently Asked Questions

Can I use all three tools simultaneously?
Technically yes — Copilot for inline editing, Claude Code in the terminal, and Cursor open as your IDE. In practice, paying for all three simultaneously gets expensive, and there's overlap between Cursor and Copilot for inline use. Pairing Claude Code with one of the other two is the more economical approach.

Which handles Shopify Liquid best?
All three handle Liquid reasonably well, but Claude Code performs best because its large context window can fit entire themes at once. Cursor's indexing also works well for non-JavaScript projects. Copilot shines most on mainstream languages where its training data is richest.

Is Cursor worth the extra cost over Copilot for a small team?
For teams working on complex codebases — large TypeScript projects, design systems, legacy code with tangled dependencies — the codebase-wide context Cursor provides often pays for itself quickly. For simpler projects like MVPs or small sites where the entire project fits in one developer's head, Copilot's cost and simplicity are hard to beat.

Which tool is best for junior developers?
GitHub Copilot. The IDE-native inline autocomplete is the lowest-friction entry point, doesn't require CLI comfort, and the instant feedback loop matters more at early career stages than autonomous execution. Claude Code's terminal interface has a real learning curve.

How does privacy work for each tool?
GitHub Copilot Business has the most mature enterprise controls with IP indemnity and you can opt out of training at the organisation level. Claude Code's API architecture keeps code within Anthropic's systems. Cursor indexes code on their servers but offers opt-out from training. For regulated industries, Copilot's established compliance certifications are the safest starting point.

Which tool handles React Native best?
Claude Code's large context window and autonomous execution are particularly useful for React Native projects, where platform-specific code paths (iOS/Android branches, native modules) can span many files. Cursor's codebase indexing also works well. Copilot is fine for individual component work but less useful for cross-platform architecture decisions.

If I can only afford one, which should I pick?
For a solo developer or very small team: Claude Code ($20/month) if you're terminal-comfortable and do complex multi-file work; GitHub Copilot Pro ($19/month) if you want inline assistance without a terminal workflow change. Cursor Pro ($20/month) if you're doing large TypeScript/Next.js projects and codebase context is your bottleneck.

Rishabh Sethia, Founder & CEO of Innovatrix Infotech. Former SSE/Head of Engineering. DPIIT Recognized Startup.

Originally published at Innovatrix Infotech

Why We Switched Our Dev Team to Cursor (And What We Miss About Copilot)

Rishabh Sethia — Mon, 13 Jul 2026 09:30:01 +0000

We ran GitHub Copilot across our whole team for months. It worked. $10 per developer, clean IDE integration, no friction during onboarding. For most of our projects — smaller client builds, feature work that stayed mostly in one file — Copilot was exactly what it needed to be.

The switch to Cursor wasn't driven by Copilot failing. It was driven by a single task that revealed the ceiling.

The Task That Changed the Decision

We were building a Next.js platform with 60+ components using App Router and TypeScript, with a custom Tailwind-based design system. The client needed standardised loading states across 23 button components. These components had been built incrementally by different developers, and the implementations were inconsistent — some used a loading boolean, some had their own spinner logic, a few had no loading state at all.

With Copilot, the workflow was: open each file, look at the suggestion, accept or adjust, close, next file. Copilot could suggest what a loading state should look like in the current component, but it had no awareness of the pattern we were establishing across the other 22. We had to mentally maintain that consistency ourselves.

A team member suggested trying Cursor's Composer mode on the same task. The experience was different in a way that's hard to overstate.

We described the loading state pattern once, pointed Composer at the component directory, and it planned the change across all 23 files with awareness of each component's existing interface. It identified two edge cases we'd missed — a button inside a form that needed different loading state handling, and a ghost variant that didn't take a disabled prop the same way as the others. The entire refactor took about 20 minutes instead of most of an afternoon.

That was the moment. Not because the task was impossible in Copilot, but because Cursor understood the problem as a codebase problem rather than 23 separate file problems.

What's Actually Different

Copilot and Cursor both provide inline code completion and chat. The visible surface is similar enough that the switch feels incremental. But the underlying model of how AI interacts with your code is genuinely different.

Copilot works at the file level. It sees the current file, the imports, some surrounding context — but it doesn't have a semantic model of the whole project. When you ask it to refactor something that touches multiple files, it can help you do that file by file. What it can't do is reason about the whole change at once.

Cursor indexes the entire project semantically. When you ask it to make a change, it understands which components consume the interface being modified, which tests cover the affected code, and which utilities already implement similar patterns. The suggestions aren't “based on what you've typed” — they're based on how the change fits into everything.

For our work — complex Shopify builds, large Next.js apps, React Native projects with shared component libraries — that distinction is the difference between a tool that assists you and a tool that understands your intent.

The Trade-offs We Accepted

Switching wasn't cost-free. We made deliberate trade-offs.

Cost. Cursor Pro is $20 per developer per month versus Copilot's $10. For our team, that's an extra $1,200 per year. We decided it was worth it, but it's not trivial, and for a larger team the number compounds.

JetBrains. Cursor is a VS Code fork. Two developers on our team use IntelliJ IDEA for certain Java-adjacent tooling. They still run Copilot — we have a split tool environment now. Cursor doesn't work in JetBrains, and that's not going to change any time soon. For teams with mixed IDEs, this is a real issue.

Setup overhead. Copilot works immediately after install. Cursor needs to index your project first — typically 2 to 5 minutes on a medium Next.js project, incremental after that — and for large monorepos you sometimes need to configure which directories to index. Not a big deal, but it's friction that Copilot doesn't have.

GitHub-native features. Copilot's PR summary generation, Autofix in Actions, and Copilot Workspace integrations are genuinely good. We lost access to those when we shifted primary tools. Claude Code fills some of that gap for us, but it's worth acknowledging the loss.

When We Use What Now

Most of the team runs Cursor as the primary IDE tool. For the two developers on JetBrains, it's still Copilot. Claude Code runs in the terminal for autonomous tasks — the kind of multi-step work where you write a clear prompt and want Claude to execute, test, and commit without constant review.

The practical split is:

Cursor: Large features on complex projects where codebase-aware suggestions matter, design system work, refactors that touch multiple components, anything where understanding the whole project is important
Copilot: JetBrains users, GitHub Actions integrations, teams where IDE standardisation isn't feasible
Claude Code: Autonomous terminal execution for well-scoped tasks, heavy refactors where you want AI to work autonomously, MCP-connected sessions where Claude talks directly to our CMS or APIs

When Copilot Would Still Be the Right Call

We don't recommend Cursor for every team or every project.

For smaller, self-contained projects — MVPs, landing pages, simple client sites — the indexing overhead isn't justified. When the entire project fits in one developer's mental model, Cursor's codebase intelligence doesn't add proportional value. Copilot's cost and simplicity are more appropriate.

For teams using multiple IDEs, Cursor's VS Code-only constraint is a hard blocker. A team where half the developers are on JetBrains can't standardise on Cursor without forcing an IDE switch that has its own significant cost.

For teams where GitHub ecosystem integration — PR workflows, Actions, Copilot Workspace — is a real part of the workflow, Copilot's native integrations are better than anything Cursor offers in that space.

As an Official Shopify Partner running projects across Shopify, Next.js, and React Native, we've found the decision hinges on project scale more than anything else. Complex builds with large component libraries justify the switch. Smaller engagements don't.

The Honest Takeaway

Cursor is a better tool for our specific work. Complex projects, large codebases, codebase-wide consistency problems. For that category of work, the extra $10 per developer per month is clearly worth it.

What we miss about Copilot: the zero-friction install, the GitHub-native integrations, and the fact that it works everywhere. Those aren't small things. Copilot is a very good tool that's the right choice for a large category of teams and projects.

If you're evaluating the switch, the question isn't which tool is better in the abstract. It's whether codebase-wide context is the bottleneck in your current work. If it is, Cursor will be a noticeable improvement. If it isn't, the cost premium doesn't make sense.

For teams interested in how we structure AI tooling across client engagements, our web development and AI automation services both reflect this kind of tool-considered approach.

Frequently Asked Questions

How long does it take to switch a team from Copilot to Cursor?
The technical switch is fast — install Cursor, import your VS Code settings and extensions, done. The workflow adjustment takes longer. Developers need to build habits around using Composer mode rather than just inline autocomplete. Give it two weeks of deliberate use on a real project before judging whether it's worth it.

Does Cursor work with JetBrains IDEs?
No. Cursor is a VS Code fork and runs only on VS Code. If your team uses JetBrains IDEs (IntelliJ, WebStorm, PyCharm, etc.), you'll need to keep Copilot for those developers or ask them to switch editors.

Is there a free tier for Cursor?
Cursor has a Hobby tier with limited usage. For any serious team use, you'll want Cursor Pro at $20/month or Teams at $40/user/month.

Can you run Cursor and Copilot at the same time?
You can install both, but running Copilot as an extension inside Cursor creates conflicts. Most developers choose one as their primary inline tool and use the other only in specific contexts (e.g., Copilot for GitHub Actions integrations, Cursor for everything else in the editor).

How does Cursor handle large monorepos?
Well, but you may need to configure which directories to index. The default indexing handles most projects fine. For very large monorepos, selectively indexing the packages you're actively working in reduces indexing time and improves relevance.

Does the switch affect code quality for junior developers?
The learning curve matters more for juniors. Copilot's inline suggestions feel familiar and are easy to evaluate. Cursor's Composer mode, which generates multi-file changes, requires more judgment to review and use responsibly. We'd lean toward starting junior developers on Copilot and introducing Cursor once they have enough context to evaluate multi-file changes confidently.

What about Cursor's privacy policy for client code?
Cursor indexes your code on their servers for the semantic search features. You can opt out of training data usage. For sensitive client work, review Cursor's data processing agreement. For clients with strict data residency or confidentiality requirements, the indexing behaviour is worth discussing with your legal team before deploying widely.

Rishabh Sethia, Founder & CEO of Innovatrix Infotech. Former SSE/Head of Engineering. DPIIT Recognized Startup.

Originally published at Innovatrix Infotech

WordPress to Headless CMS: Is It Worth the Migration in 2026?

Rishabh Sethia — Mon, 13 Jul 2026 04:30:02 +0000

Your WordPress site takes 4 seconds to load, gets hacked twice a year, and your content team fights with the editor daily. A headless CMS could fix all three problems — or create entirely new ones. Here's how to decide.

I've helped teams migrate from WordPress to headless setups, and I've also talked founders out of it. The truth is that headless CMS isn't universally better — it's a different set of trade-offs. This article gives you everything you need to make the call for your specific situation.

What "Headless CMS" Actually Means

Traditional WordPress is a monolithic system. The CMS (where you write content) and the frontend (what visitors see) are welded together. Your theme, your plugins, your database, your PHP rendering engine — all one unit.

A headless CMS rips that apart. The CMS becomes a pure content repository with an API. Your frontend — built with React, Next.js, Vue, whatever — fetches content through that API and renders it however you want.

Think of it like this:

Traditional WordPress: The kitchen and the dining room are the same room. The chef cooks and serves at the same counter.
Headless CMS: The kitchen (CMS) sends dishes through a window (API) to a separate dining room (frontend). The dining room can be redesigned without touching the kitchen.

This separation unlocks real advantages. It also introduces real complexity.

The Honest Case FOR Migration

1. Performance That Actually Matters

Headless architectures paired with static site generation (SSG) or incremental static regeneration (ISR) deliver pages in under 500ms consistently. Traditional WordPress, even with aggressive caching, typically lands between 1.5-4 seconds.

Why? WordPress renders pages on every request using PHP. Even with object caching and page caching plugins, you're still dealing with a database query layer, plugin overhead, and server-side rendering bottlenecks.

A headless setup with Next.js serves pre-built HTML from a CDN edge node. No PHP execution. No database queries at request time. The content was already fetched and baked into static HTML during the build step.

Real-world benchmark data:

Metric	Traditional WordPress (Optimized)	Headless + Next.js (SSG)
Time to First Byte (TTFB)	800ms – 1.8s	50ms – 150ms
Largest Contentful Paint (LCP)	2.2s – 4.5s	0.8s – 1.5s
Total Blocking Time (TBT)	300ms – 900ms	0ms – 50ms
Core Web Vitals pass rate	~45% of WP sites pass	~90% of headless sites pass
CDN-edge serving	Plugin-dependent	Native

These aren't theoretical numbers. Google's CWV report consistently shows WordPress sites underperforming compared to Jamstack/headless architectures.

2. Security You Don't Have to Think About

WordPress powers 43% of the web. That makes it the single biggest target for automated attacks. Brute force login attempts, SQL injection through plugins, XSS vulnerabilities in themes — the attack surface is enormous.

With a headless setup, your CMS sits behind a firewall, unexposed to the public internet. Visitors interact with static files on a CDN — there's no database to inject, no login page to brute force, no PHP to exploit.

The security model shifts from "patch everything constantly and hope nothing slips through" to "there's nothing to attack on the public-facing side."

3. Multi-Channel Content Delivery

If your content needs to appear on a website, a mobile app, a kiosk display, and a partner's platform — WordPress makes this painful. You end up duplicating content or building hacky integrations.

A headless CMS serves content as structured data through an API. Any frontend can consume it. Write once, publish everywhere. This matters if you're building beyond just a website.

4. Developer Experience and Velocity

Modern frontend developers work in React, Vue, or Svelte. Asking them to build in PHP with WordPress theme conventions is like asking a Formula 1 engineer to tune a tractor. They'll do it, but slowly and unhappily.

Headless lets your frontend team use the tools they're fastest with. Component-based architecture, TypeScript, hot module replacement, proper version control — all the things that make developers ship faster.

The Honest Case AGAINST Migration

1. Cost: It's Not Even Close (Initially)

Let me be direct about this. A headless setup costs more upfront. Significantly more.

Cost Component	Traditional WordPress (INR)	Headless CMS + Next.js (INR)
Initial build (brochure site, 8-12 pages)	₹80,000 – ₹2,00,000	₹2,50,000 – ₹6,00,000
CMS license (annual)	₹0 (self-hosted WP)	₹0 – ₹3,00,000 (depends on CMS)
Hosting (annual)	₹3,000 – ₹15,000	₹6,000 – ₹36,000
Ongoing maintenance (annual)	₹30,000 – ₹80,000	₹60,000 – ₹1,50,000
Plugin/integration costs	₹5,000 – ₹30,000/year	Custom development
Year 1 total (typical)	₹1,18,000 – ₹3,25,000	₹3,16,000 – ₹10,86,000

The headless setup costs 2-3x more in year one. That gap narrows over time as you avoid the WordPress plugin tax and security patching cycle — but it takes 2-3 years to break even on cost alone.

If budget is your primary constraint, WordPress is still the rational choice for most small businesses.

2. Editorial Experience: A Real Step Backward

WordPress's editor — especially Gutenberg — gives content teams a visual, block-based editing experience. They see something close to the final page as they write. Headers, images, columns, buttons — all visual.

Most headless CMS editors show you form fields. Title field. Body field (Markdown or rich text). Image upload field. Your content team types into boxes and has no idea what the final page looks like until it's published.

Some headless CMS platforms (Sanity with its Studio, Directus with custom layouts) are closing this gap. But out of the box, the editorial experience is worse than WordPress for non-technical users. If your content team isn't technically inclined, this is a real friction point.

3. Complexity: More Moving Parts

Traditional WordPress: one server, one application, one database. Done.

Headless setup: CMS server, API layer, frontend application, CDN configuration, build pipeline, preview environment, webhook integrations. That's six things that can break instead of one.

Every additional component is a potential failure point, a configuration surface, and something someone needs to understand and maintain.

4. The Talent Problem in India

This one doesn't get discussed enough. Finding a WordPress developer in India takes a day. Finding a developer who understands headless CMS architecture, API design, modern frontend frameworks, and deployment pipelines? That takes weeks.

The talent pool for headless CMS development in India is growing but still small compared to WordPress. This affects:

Hiring costs: Headless-capable developers command 40-80% higher salaries
Agency availability: Fewer agencies offer headless CMS services competently
Knowledge transfer: If your developer leaves, finding a replacement is harder
Community support: WordPress has forums, YouTube tutorials, and Stack Overflow answers for everything. Headless CMS solutions have smaller communities

This is improving rapidly — the Next.js ecosystem in India has grown enormously — but it's still a factor for teams building in-house.

Popular Headless CMS Options Compared

Not all headless CMS platforms are equal. Here's how the major players stack up:

Feature	Directus	Strapi	Contentful	Sanity
Open source	Yes (GPL)	Yes (MIT)	No	Partially
Self-hosted option	Yes	Yes	No (SaaS only)	No (SaaS only)
Database	Any SQL (Postgres, MySQL, SQLite)	Postgres, MySQL, SQLite	Proprietary	Proprietary
API type	REST + GraphQL	REST + GraphQL	REST + GraphQL	GROQ (proprietary)
Free tier	Unlimited (self-hosted)	Unlimited (self-hosted)	1 space, 5 users	3 users, 10k docs
Editorial UX	Good (custom layouts possible)	Good	Excellent	Excellent (Studio)
Learning curve	Moderate	Moderate	Low	Steep (GROQ)
Best for	Teams wanting full control	Startups, rapid prototyping	Enterprise, large teams	Developer-heavy teams
India hosting	Any cloud (AWS Mumbai, etc.)	Any cloud	US/EU only (SaaS)	US/EU only (SaaS)
Data ownership	Full (your database)	Full (your database)	Vendor-locked	Vendor-locked

Our take: For teams in India and those who value data ownership, self-hosted options like Directus or Strapi make the most sense. You control your data, host in your region for lower latency, and avoid SaaS pricing that scales with usage.

Contentful and Sanity are strong products, but vendor lock-in and SaaS costs become significant at scale. Sanity's proprietary query language (GROQ) is powerful but means your team's skills don't transfer to other platforms.

WordPress as Headless: The Hybrid Approach

Here's something most "headless CMS" articles skip: you can use WordPress itself as a headless CMS.

WordPress ships with a REST API out of the box. You can keep your WordPress backend — the editor your team already knows — and build a separate frontend in Next.js, Astro, or any framework that consumes the WordPress REST API.

This gives you:

Familiar editor: Your content team keeps using Gutenberg
Existing content: No migration needed — your posts and pages are already there
Plugin ecosystem: Most plugins that affect content (ACF, Yoast, etc.) expose data via the API
Lower migration cost: You're only rebuilding the frontend, not replacing the entire CMS

The downsides:

WordPress maintenance continues: You still need to update WordPress, PHP, and plugins
Performance overhead: The API is slower than purpose-built headless CMS APIs
API limitations: Not everything in WordPress translates cleanly to API responses
Security surface remains: Your WordPress admin is still exposed (though visitors never touch it)

Key insight: WordPress-as-headless is the most underrated migration strategy. It gives you 70% of the headless benefits at 40% of the cost and complexity. For many teams, this is the right first step — not a full CMS replacement.

Performance Deep Dive: Real Numbers

Let's look at what actually happens to site performance when you move from traditional WordPress to headless.

We measured across multiple client projects (8-15 page business sites, similar content complexity):

Traditional WordPress (managed hosting, caching enabled, optimized images):

Homepage load: 2.1s (first visit), 1.4s (cached)
Lighthouse Performance score: 62-78
Time to Interactive: 3.2s
Server response time: 420ms average

Same content, headless CMS + Next.js (Vercel hosting, ISR enabled):

Homepage load: 0.8s (first visit), 0.4s (cached)
Lighthouse Performance score: 94-100
Time to Interactive: 1.1s
Server response time: 45ms average

That's roughly a 60% improvement across the board. For businesses where page speed directly affects conversion (e-commerce, SaaS landing pages, lead generation), this translates to measurable revenue impact.

But here's the nuance: if your WordPress site already scores 85+ on Lighthouse and loads in under 2 seconds, the performance gains from going headless are marginal. You'd be spending ₹3-5 lakhs to shave 500ms off your load time. The ROI doesn't justify it.

Migration Approaches: Big Bang vs. Incremental

Big Bang Migration

You rebuild everything at once. New CMS, new frontend, new hosting. Flip the switch on launch day.

When it works: Small sites (under 50 pages), teams with clear requirements, projects where the old site is fundamentally broken.

Risks: Everything breaks at once if something goes wrong. No fallback. High pressure on launch day.

Timeline: 8-16 weeks for a typical business site.

Incremental Migration (Recommended)

You migrate piece by piece. Start with high-impact pages (blog, landing pages), keep the rest on WordPress, and gradually move everything over.

Phase 1 (Weeks 1-4): Set up headless CMS, migrate blog content, build blog frontend. WordPress handles everything else.

Phase 2 (Weeks 5-8): Migrate landing pages and high-traffic pages. Set up redirects.

Phase 3 (Weeks 9-12): Migrate remaining pages. Decommission WordPress frontend (keep as headless backend if using WP-as-headless approach).

Phase 4 (Weeks 13-16): Performance optimization, SEO validation, monitoring setup.

Why incremental wins: You catch problems early, maintain a working site throughout, and can pause or reverse if priorities change. The business never goes offline.

The Decision Framework: Who Needs Headless?

Stop asking "should I go headless?" and start asking these five questions:

1. Does your site need to serve content to multiple platforms?
If yes (website + app + kiosk + partner feeds) → headless makes strong sense.
If no (website only) → headless is optional.

2. Is performance a direct revenue driver?
If yes (e-commerce, SaaS with conversion funnels) → headless pays for itself.
If no (informational site, internal tool) → WordPress with caching is fine.

3. Does your development team work in modern JavaScript frameworks?
If yes → headless lets them work at full speed.
If no → you'll need to hire or retrain, adding cost and time.

4. Is your content team technically comfortable?
If yes → they'll adapt to a headless editor.
If no → the WordPress editor is genuinely better for non-technical users.

5. What's your annual technology budget?
If under ₹3 lakhs/year → stay on WordPress, optimize what you have.
If ₹3-8 lakhs/year → consider WordPress-as-headless hybrid.
If above ₹8 lakhs/year → full headless is feasible.

Score yourself: If you answered "yes" to 3+ of the first four questions AND have the budget → migrate. Otherwise → optimize your WordPress setup first.

Migration Checklist

If you've decided to proceed, here's what the process looks like:

Pre-Migration (Week 1-2)

Audit existing content (pages, posts, custom post types, media library)
Map URL structure and plan redirects
Choose headless CMS based on team skills and requirements
Define content model (structured types, not WordPress's freeform approach)
Set up staging environments for both CMS and frontend

Content Migration (Week 2-4)

Export WordPress content (WP CLI or REST API export)
Transform content to match new content model
Import into headless CMS
Validate all content transferred correctly (automated checks)
Migrate media assets (images, documents, videos)

Frontend Build (Week 3-8)

Build component library matching existing design
Implement page templates consuming CMS API
Set up preview mode for content team
Implement SEO elements (meta tags, structured data, sitemap)
Configure CDN and caching strategy

Testing and Launch (Week 8-12)

SEO audit: compare old and new meta tags, structured data, internal links
Performance testing across devices
Content team training on new CMS
Redirect testing (every old URL must resolve)
Staged rollout (DNS switch with monitoring)

Post-Launch (Week 12-16)

Monitor 404s and fix redirect gaps
Track Core Web Vitals improvement
Compare search rankings (expect 2-4 week settling period)
Gather content team feedback and iterate on CMS workflows

Timeline Expectations

Simple brochure site (5-15 pages): 6-10 weeks
Content-heavy blog (100+ posts): 10-14 weeks
E-commerce catalog (500+ products): 14-20 weeks
Enterprise site with custom integrations: 16-24+ weeks

Double these timelines if you're also redesigning the site simultaneously. Migration and redesign at the same time is the number one cause of project delays and budget overruns.

FAQ

Will I lose SEO rankings when migrating to headless?
Temporarily, yes — expect a 2-4 week settling period. If you maintain the same URL structure, implement proper 301 redirects, preserve meta tags and structured data, and keep content identical, your rankings should recover and likely improve due to better Core Web Vitals. The biggest risk is broken redirects.

Can I use WordPress plugins with a headless setup?
Plugins that affect content (ACF, Yoast SEO, WPML) generally expose data via the REST API and work fine. Plugins that affect the frontend (page builders, slider plugins, popup plugins) won't work — their output is tied to the WordPress theme layer. You'll rebuild that functionality in your frontend framework.

How much does headless CMS hosting cost in India?
Self-hosted (Directus or Strapi on AWS Mumbai or DigitalOcean Bangalore): ₹2,000-₹8,000/month for a small-to-medium site. SaaS options (Contentful, Sanity): ₹5,000-₹25,000/month depending on usage. Frontend hosting (Vercel, Netlify): free tier covers most small sites, ₹1,500-₹5,000/month for production workloads.

Is headless CMS good for e-commerce?
Yes, but with caveats. Headless commerce (Shopify Storefront API, Medusa, Saleor) delivers excellent performance. However, you lose the plug-and-play nature of Shopify themes or WooCommerce. Every checkout flow, product filter, and cart interaction needs custom frontend development. Budget 2-3x more for headless e-commerce compared to traditional setups.

What happens to my WordPress site during migration?
Nothing — it stays live until you're ready to switch. With incremental migration, both systems run in parallel. Your visitors experience zero downtime. The DNS switch (pointing your domain to the new frontend) takes 5-15 minutes.

Can a non-technical team manage a headless CMS?
It depends on the CMS. Directus and Contentful have intuitive interfaces that non-technical users can learn in a few hours. Sanity requires some technical comfort. Strapi is developer-friendly but can overwhelm content editors. The key is investing in proper content team training — budget 2-3 days of hands-on training during migration.

Should I migrate my blog first or my main site?
Blog first, always. Blog content is typically the most structured (title, body, author, date, tags), making it the simplest migration target. It lets your team learn the new system on low-risk content before tackling complex pages. If the blog migration goes poorly, you can reverse it without affecting your main site.

How do I handle forms and dynamic features in a headless setup?
Forms, search, comments, and other dynamic features need separate solutions. Options include serverless functions (API routes in Next.js), third-party services (Formspree, Algolia), or your headless CMS's built-in features (Directus supports custom endpoints and flows). Plan these integrations during the architecture phase — they're often the most underestimated part of a headless migration.

Considering a headless CMS migration? We've migrated WordPress sites to headless for clients across India, UK, and US. Let's evaluate if it makes sense for your specific case. Book a free discovery call

Originally published at Innovatrix Infotech