DEV Community: Rishabh Sethia

How to Build an Arabic RTL Shopify Store: The Complete Technical Guide

Rishabh Sethia — Wed, 19 Aug 2026 04:30:01 +0000

There's a post I kept wishing existed when we first took on an Arabic Shopify build. A post that covered the real implementation: not just "add dir=rtl to your HTML" (which breaks more than it fixes), but the actual CSS overrides, the font stack decisions, the Liquid conditionals, and the third-party apps that silently wreck your layout the moment a customer switches to Arabic.

This is that post.

As a Shopify Partner that's built RTL stores for clients across Saudi Arabia and the UAE, we've made every mistake this guide warns you about. Consider this the distilled version.

What You'll Learn

How Shopify OS 2.0 handles RTL natively (and where it falls short)
The CSS properties that require manual overrides in RTL
Arabic font stacks that actually render well at small screen sizes
Using Liquid's locale.direction for conditional rendering
Handling bidirectional (bidi) content: Arabic text with embedded English numbers
Which popular Shopify apps break in RTL and how to fix them

Prerequisites

A Shopify store on a 2.0 theme (Dawn, Sense, Refresh, or a premium 2.0-compatible theme)
Access to Online Store > Themes > Edit Code
Arabic added as a language via Settings > Languages
Basic CSS knowledge

Step 1: Enable Arabic as a Language in Shopify

Before any code changes, add Arabic through Shopify's language system.

Go to Settings > Languages
Click Add language and select Arabic (ar)
Use Shopify's Translate & Adapt app (free, from Shopify) to translate your theme strings, or use a third-party translation app
Once Arabic is active, Shopify OS 2.0 themes with dir="rtl" support will automatically flip to RTL layout when a customer's locale is Arabic

What Shopify handles automatically in OS 2.0:

Text direction (dir="rtl" applied to <html>)
Text alignment for paragraph content
Some Flexbox reversals

What it does NOT handle automatically (you must fix these manually):

CSS left/right positioning on absolutely or fixed positioned elements
float declarations (largely legacy but still common in older themes/apps)
margin-left / margin-right asymmetric values
Icon direction (arrows, chevrons that point left in LTR should point right in RTL)
Third-party app widgets injected via JavaScript

Step 2: The Core CSS Overrides

Create a new snippet file called rtl-overrides.css.liquid and include it conditionally. Then add your RTL styles inside a conditional block.

In your theme.liquid (inside the <head> tag), add:

{% if locale.direction == 'rtl' %}
  {{ 'rtl-overrides.css' | asset_url | stylesheet_tag }}
{% endif %}

In your assets/rtl-overrides.css file:

/* =============================================
   INNOVATRIX RTL OVERRIDES: Arabic Shopify Stores
   ============================================= */

/* Flip all left/right margin/padding pairs */
[dir="rtl"] .left-content { margin-left: 0; margin-right: var(--spacing); }
[dir="rtl"] .right-content { margin-right: 0; margin-left: var(--spacing); }

/* Flip Flexbox row direction */
[dir="rtl"] .flex-row { flex-direction: row-reverse; }

/* Product grid: image + content alignment */
[dir="rtl"] .product-card__info { text-align: right; }
[dir="rtl"] .product-card__price { text-align: right; }

/* Navigation: reverse the dropdown direction */
[dir="rtl"] .header__menu-item .header__submenu { 
  left: auto; 
  right: 0; 
}

/* Chevron/arrow icons: flip horizontally */
[dir="rtl"] .icon-arrow-right,
[dir="rtl"] .icon-chevron-right {
  transform: scaleX(-1);
}

/* Breadcrumb separator */
[dir="rtl"] .breadcrumb__separator { transform: scaleX(-1); }

/* Input fields: right-align text */
[dir="rtl"] input,
[dir="rtl"] textarea,
[dir="rtl"] select {
  text-align: right;
  direction: rtl;
}

/* Cart quantity: fix mis-aligned stepper */
[dir="rtl"] .quantity-selector {
  flex-direction: row-reverse;
}

Critical gotcha: Don't use [dir="rtl"] * { direction: rtl; } as a catch-all. It will break embedded iframes (payment widgets, review apps, chat tools) that need to render LTR internally. Target elements explicitly.

Step 3: Arabic Font Stack

Shopify themes ship with Latin fonts by default. Arabic text rendered in a Latin font falls back to the browser's default Arabic font, which is usually inconsistent across devices and rarely legible at small sizes.

The three Arabic Google Fonts that perform well in ecommerce contexts:

Cairo: clean, geometric, excellent readability at all sizes, works at 14px+
Tajawal: slightly more rounded, good for headings and hero text
Noto Sans Arabic: extremely legible at small sizes, ideal for body copy and meta

Add to the <head> in theme.liquid:

{% if locale.direction == 'rtl' %}
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <link href="https://fonts.googleapis.com/css2?family=Cairo:wght@400;500;600;700&family=Tajawal:wght@400;500;700&display=swap" rel="stylesheet">
{% endif %}

In your rtl-overrides.css:

/* Apply Arabic font stack when RTL is active */
[dir="rtl"] body,
[dir="rtl"] p,
[dir="rtl"] .product-card__title,
[dir="rtl"] .cart__item-name {
  font-family: 'Cairo', 'Tajawal', 'Noto Sans Arabic', Arial, sans-serif;
  line-height: 1.7; /* Arabic text needs more line height than Latin */
  font-size: 1.05rem; /* Slight upsize: Arabic at 14px is harder to read */
}

[dir="rtl"] h1,
[dir="rtl"] h2,
[dir="rtl"] h3 {
  font-family: 'Tajawal', 'Cairo', sans-serif;
  font-weight: 700;
  letter-spacing: 0; /* Zero letter-spacing: Arabic glyphs connect */
}

Important: Arabic is a cursive script: glyphs connect to each other. Never apply letter-spacing values to Arabic text. It breaks the visual joining of characters and looks like corrupted text.

Step 4: Liquid Conditional Rendering

Some layout decisions require Liquid logic, not just CSS. The locale.direction variable returns "rtl" or "ltr" based on the active language.

Example: Conditional icon rendering

{% if locale.direction == 'rtl' %}
  {% render 'icon-arrow-left' %}
{% else %}
  {% render 'icon-arrow-right' %}
{% endif %}

Example: RTL-aware product card layout

<div class="product-card {% if locale.direction == 'rtl' %}product-card--rtl{% endif %}">
  <div class="product-card__image">...</div>
  <div class="product-card__info">
    <h3 class="product-card__title">{{ product.title }}</h3>
    <p class="product-card__price">{{ product.price | money }}</p>
  </div>
</div>

Example: RTL-aware <html> tag (add to theme.liquid)

<html lang="{{ request.locale.iso_code }}" dir="{{ locale.direction }}">

This ensures the dir attribute is dynamically set on the document root based on the active language: which is what drives all CSS [dir="rtl"] selectors.

Step 5: Handling Bidirectional (Bidi) Content

Mixed Arabic/English content is common in ecommerce: product names in Arabic, prices in Arabic numerals or English numerals, brand names in Latin characters embedded in Arabic descriptions.

The Unicode bidirectional algorithm handles most of this automatically, but it can produce unexpected results in specific cases: especially around punctuation, numbers at the end of Arabic strings, and parentheses.

Use the unicode-bidi CSS property for mixed-direction containers:

[dir="rtl"] .product-description {
  unicode-bidi: plaintext;
  /* Renders bidi content in its natural direction without forcing the container direction */
}

For product names with embedded English brand names:

<span dir="auto">{{ product.title }}</span>

The dir="auto" HTML attribute uses the first strong character in the text to set direction: if the product name starts with Arabic, it renders RTL; if it starts with a Latin brand name, it renders LTR. This is more reliable than hard-coding for mixed catalogs.

Step 6: Third-Party Apps That Break in RTL

This is the section you won't find in most guides. Here are the apps and widget categories that commonly produce broken layouts in Arabic RTL Shopify stores, and how to handle each:

Review Apps (Judge.me, Loox, Stamped.io)
Stars-and-review widgets inject their own CSS, often with hard-coded text-align: left and float: left. Override via the Shopify theme's custom CSS:

[dir="rtl"] .jdgm-rev__body,
[dir="rtl"] .jdgm-rev__author {
  text-align: right;
  direction: rtl;
}

BNPL Widgets (Tabby, Tamara)
Tabby and Tamara both have Arabic-aware widget options: pass lang="ar" in their embed configuration to get Arabic-localised messaging. Without this, they default to English.

Klaviyo / Email Capture Popups
Klaviyo's popup form renders LTR by default. In Klaviyo's form editor, set text direction to RTL in the form settings for Arabic templates.

Live Chat (Tidio, Freshchat, Intercom)
Most live chat tools auto-detect the user's browser language and flip their own widget. If yours doesn't, check the language configuration in the chat tool's settings: most enterprise-tier chat tools have explicit RTL support.

Search Apps (Searchie, Boost Commerce)
Search result dropdowns and filter panels often have their own CSS scope. You'll need app-specific overrides. Test your search experience in Arabic explicitly: it's commonly broken and commonly overlooked.

Common Issues and Fixes

Problem: Checkout page is still LTR in Arabic mode.
Fix: Shopify's checkout (for non-Shopify Plus merchants) is a Shopify-controlled surface. You cannot customise its RTL behaviour without a Shopify Plus checkout.liquid. For standard plans, the checkout will use Shopify's built-in Arabic support, which is reasonable but not fully customisable.

Problem: Product image gallery carousel swiping direction is inverted (swipe left in Arabic, but it goes right).
Fix: Most carousel libraries (Splide, Swiper) have a dir option. Set dir: 'rtl' in your carousel initialisation when locale.direction == 'rtl'.

Problem: Breadcrumb shows Home / Products / Product Name instead of اسم المنتج / المنتجات / الرئيسية.
Fix: This is a translation issue, not an RTL issue. Use Translate & Adapt to translate breadcrumb strings. The RTL layout will handle direction once translation is in place.

Problem: Email notifications are still LTR.
Fix: Shopify email notification templates are separate from theme files. Go to Settings > Notifications and manually add dir="rtl" to the relevant email HTML templates for Arabic-language notifications.

Results: What Proper RTL Delivers

For one of our Saudi Arabia-facing clients, we implemented the full RTL treatment described above on a mid-size fashion store. The before/after on the Arabic-language variant told the story clearly: session duration in Arabic increased substantially, and cart abandonment on the Arabic checkout path dropped to match the English path: which it had meaningfully underperformed before the RTL work.

Proper RTL is not cosmetic. Saudi and UAE consumers who encounter a broken Arabic layout typically don't report it. They leave. The conversion gap between a properly-built Arabic store and a half-implemented one is measurable in direct revenue.

If you want us to audit your existing Shopify store's Arabic experience or build a new RTL-ready store, start with a discovery call here.

Frequently Asked Questions

Does Shopify natively support Arabic RTL?
Partially. Shopify OS 2.0 themes apply dir="rtl" to the HTML element when Arabic is the active language, and handle basic text direction. However, CSS positioning, flexbox layouts, icon direction, margins, and third-party app widgets all require manual fixes. Native support handles perhaps 60-70% of what a proper Arabic store needs.

Can I build a bilingual English/Arabic store on Shopify?
Yes. Using Shopify Markets with multiple languages, you can serve English (LTR) and Arabic (RTL) from the same store. The locale.direction variable handles layout switching automatically. Translation is handled via Translate & Adapt or a paid app like Weglot.

What Shopify plan do I need for a bilingual store?
Multiple languages are available on all Shopify plans. You can add up to 20 languages on standard plans. Shopify Markets (which lets you configure currency, language, and domains per region) is available from Basic and above.

Which Arabic fonts work best in Shopify?
For body copy: Noto Sans Arabic (most legible at small sizes). For headings: Tajawal or Cairo. Always use line-height: 1.6 to 1.8 for Arabic body text: Arabic scripts need more vertical space than Latin equivalents. Never use letter-spacing on Arabic text.

How do I handle product names that are in English inside an Arabic store?
Use dir="auto" on the element containing the product name. This uses the first strong-directional character to set the display direction automatically: works well for mixed-language product catalogs.

Does this guide work for Shopify Hydrogen (headless) stores?
The Liquid-specific parts don't apply to headless builds, but the CSS principles, font strategy, and bidi content handling are all relevant. In Hydrogen, use React's dir prop on the root element and manage RTL through Tailwind's RTL plugin or a CSS-in-JS RTL helper.

What's the hardest part of building an Arabic Shopify store?
In our experience: third-party app compatibility. The core theme can be handled cleanly with the approach above. The unpredictable part is the 10-15 apps a typical merchant has installed, each injecting their own CSS that may fight your RTL overrides. Audit every installed app in Arabic view before launch.

Originally published at Innovatrix Infotech

Multi-Currency Shopify Setup for GCC: AED, SAR, KWD Step-by-Step

Rishabh Sethia — Tue, 18 Aug 2026 04:30:01 +0000

Here's what most GCC multi-currency guides don't tell you: Shopify Payments is not available in the UAE or Saudi Arabia. That single fact changes your entire architecture.

In Western markets, the standard Shopify multi-currency setup leans on Shopify Payments for currency management. In GCC markets, you're working with third-party payment gateways, and not all of them support settlement in every GCC currency. Getting this wrong means you either can't collect SAR payments, or you collect them and settle in AED at unfavourable exchange rates with margin implications you didn't model for.

As a Shopify Partner that's built multi-currency stores for UAE and Saudi Arabia clients, we've mapped every decision in this setup. This guide gives you the architecture and the specific configuration steps.

What You'll Build

A Shopify store with separate Markets for:

UAE (AED: Arab Emirates Dirham)
Saudi Arabia (SAR: Saudi Riyal)
Kuwait (KWD: Kuwaiti Dinar)
Qatar (QAR: Qatari Riyal) [optional, same pattern]

Each market with: local currency pricing, correct language assignment, payment gateway configuration, and tax settings.

Prerequisites

Shopify Basic plan or above (Markets is available on all paid plans)
A payment gateway that supports multi-currency settlement in your target GCC currencies (we'll cover which ones)
Your store's base currency set (typically AED or USD depending on where you're incorporated)

Step 1: Navigate to Shopify Markets

Go to Settings > Markets in your Shopify admin
You'll see your primary market already configured (likely your home market)
Click Add market to create each GCC market

For each market, you'll configure:

Country/region (which countries are in this market)
Currency
Language
Domain or subdirectory (optional)
Pricing rules

Step 2: Create the GCC Markets

UAE Market (if not already your primary)

Market name: UAE
Countries: United Arab Emirates
Currency: AED (United Arab Emirates Dirham)
Language: English (you can add Arabic as a secondary language)
Click Save

Saudi Arabia Market

Market name: Saudi Arabia
Countries: Saudi Arabia
Currency: SAR (Saudi Arabian Riyal)
Language: Arabic (ar): this is critical; KSA customers have higher conversion on Arabic-first experiences
Click Save

Kuwait Market

Market name: Kuwait
Countries: Kuwait
Currency: KWD (Kuwaiti Dinar)
Language: Arabic or English depending on your customer research
Click Save

Qatar Market (optional)

Market name: Qatar
Countries: Qatar
Currency: QAR (Qatari Riyal)
Language: Arabic or English
Click Save

Step 3: Fixed Local Pricing vs. Automatic Currency Conversion

This is the most consequential decision in your multi-currency setup, and most tutorials gloss over it.

Automatic currency conversion takes your base price (e.g., AED 200) and converts it to the target currency using Shopify's live exchange rate, updated regularly. It's fast to implement and requires no maintenance.

Fixed local pricing means you set the exact price in each currency manually. SAR 210 is SAR 210, regardless of what the AED/SAR exchange rate does on any given day.

Our recommendation: Use fixed local pricing. Here's why:

Consumer experience. SAR 209.73 looks like a foreign price. SAR 210 or SAR 199 looks like a locally-priced product. Pricing psychology is real, and round-number or .99 pricing in local currency converts better than auto-converted amounts with three decimal places.
Margin predictability. If you're pricing AED 200 and the AED/SAR rate moves, your effective SAR price changes. Over a month of fluctuation, your KSA margin can drift materially from what you modelled.
Promotional pricing control. When you run a 20% discount, you want it applied to a clean base price, not to a fluctuating converted amount.

The tradeoff is ongoing maintenance: if your base AED pricing changes, you need to update SAR and KWD prices manually or via a bulk CSV update. For most brands with <1,000 SKUs, this is manageable.

How to set fixed prices per market:

In Settings > Markets, click on your Saudi Arabia market
Click Manage pricing
Under Pricing by country, you'll see options to set fixed prices per product or apply a price adjustment multiplier
For granular control, use the price adjustment approach (e.g., +5% over base price for KSA to account for VAT and logistics) as a starting point, then override individual products that need specific local pricing

Step 4: Payment Gateway Selection: The Critical Decision

As of early 2026, Shopify Payments is not available in the UAE or Saudi Arabia. This means you need a third-party gateway, and not all third-party gateways are equal for GCC multi-currency.

The key question: Does your gateway support settlement in the destination currency, or does it collect in local currency but settle in your base currency (AED or USD) after conversion?

For GCC multi-currency, these are the gateways we recommend and have configured for clients:

Checkout.com

Supports AED, SAR, KWD, QAR collection and settlement
Strong technical documentation and Shopify integration
Settlement accounts can be configured per currency
Our first recommendation for brands targeting multiple GCC markets
Setup requires a Checkout.com account per legal entity or one account with multi-currency settlement enabled

Telr

UAE-founded, strong regional presence
Supports AED, SAR, and other GCC currencies
Popular with UAE-incorporated merchants
Simpler merchant onboarding than Checkout.com for UAE entities

PayTabs

Saudi Arabia-founded, excellent KSA coverage
Supports SAR, AED, KWD, QAR
Good option if your primary market is KSA rather than UAE

What to avoid: Using a single gateway onboarded for AED that claims it "accepts" multi-currency but settles everything to AED. Your SAR revenue gets converted at the gateway's exchange rate before settlement, with both a conversion fee and rate risk.

Shopify + Checkout.com configuration:

Install the Checkout.com app from the Shopify App Store
In Settings > Payments > Payment providers, add Checkout.com as your primary gateway
In your Checkout.com dashboard, enable the currencies corresponding to your Markets (SAR, KWD, QAR in addition to AED)
Verify that each currency has a settlement account configured in Checkout.com

Step 5: Add BNPL Per Market

Buy-now-pay-later is table stakes in GCC ecommerce. The provider selection varies by market:

UAE: Tabby and Tamara are both strong. Tabby has strong brand recognition. Tamara is Saudi-founded but operates in UAE.

Saudi Arabia: Tamara dominates. Install Tamara first. Tabby also operates in KSA.

Kuwait/Qatar: BNPL adoption is growing but less mature than UAE/KSA. Tabby covers both markets.

For Shopify, both Tabby and Tamara have official Shopify apps. Install them and configure them to display in the appropriate markets via Shopify's market-conditional app settings.

One critical configuration note: When setting up Tamara for KSA, pass lang="ar" in the widget configuration to get Arabic-language BNPL messaging on product pages. Without this, it defaults to English even for Arabic-locale visitors.

Step 6: Language Assignment Per Market

Shopify Markets lets you assign a primary language to each market. This is separate from making your store bilingual: it sets which language a customer from that market sees by default.

UAE Market: Set English as primary, add Arabic as secondary (many UAE residents are comfortable in English, but Arabic option matters for the Arabic-speaking majority)

Saudi Arabia Market: Set Arabic as primary. KSA's online consumer base skews more Arabic-primary than UAE's, and Arabic-first experiences have meaningfully higher conversion in our client data.

Kuwait/Qatar: English or Arabic as primary depending on your customer research. If uncertain, start with English primary and add Arabic as secondary.

To enable multiple languages per market:

In Settings > Markets, click on the market
Under Languages, click Add language
Select your target language
Use Translate & Adapt (free Shopify app) to provide translations for theme content

For Arabic specifically, the RTL layout requirements apply as described in our Arabic RTL Shopify guide.

Step 7: Tax Configuration Per Market

GCC tax configuration is an area where mistakes have commercial consequences.

UAE (AED): 5% VAT. In Shopify, go to Settings > Taxes and duties > UAE. Enable VAT at 5%. For B2C (direct to consumer), prices are typically displayed inclusive of VAT in the UAE. Set your tax-inclusive/exclusive display preference in the market's settings.

Saudi Arabia (SAR): 15% VAT. This is not a typo. Saudi Arabia raised VAT from 5% to 15% in 2020. Go to Settings > Taxes and duties > Saudi Arabia. Enable VAT at 15%. If you're pricing SAR products at AED-equivalent levels and not accounting for the 10% VAT differential, your effective price is materially different from what you intended.

Kuwait (KWD): Kuwait does not currently have VAT. No tax configuration required for Kuwait sales. This can be a pricing advantage: your Kuwait prices can be clean without a VAT uplift.

Qatar (QAR): Qatar also does not currently apply VAT on ecommerce sales. Same as Kuwait: no tax configuration required at point of sale.

Step 8: Liquid Code for Currency-Aware Display

For stores that need to customise the display based on the active market, Shopify provides market-aware Liquid variables.

Display currency symbol based on market:

{% assign market_currency = cart.currency %}
{% if market_currency == 'SAR' %}
  <span class="currency-note">س.ر (SAR 15% VAT included)</span>
{% elsif market_currency == 'KWD' %}
  <span class="currency-note">KD (VAT-free)</span>
{% elsif market_currency == 'AED' %}
  <span class="currency-note">AED (5% VAT included)</span>
{% endif %}

Market-conditional announcement bar:

{% case localization.market.handle %}
  {% when 'saudi-arabia' %}
    <p>{{ 'Free shipping on orders over SAR 200' }}</p>
  {% when 'kuwait' %}
    <p>{{ 'Free shipping on orders over KWD 15' }}</p>
  {% else %}
    <p>{{ 'Free shipping on orders over AED 150' }}</p>
{% endcase %}

Market-conditional payment badge display:

{% if localization.market.handle == 'saudi-arabia' %}
  {% render 'payment-badges-ksa' %} {# Shows MADA, Tamara, Visa, MC #}
{% elsif localization.market.handle == 'uae' %}
  {% render 'payment-badges-uae' %} {# Shows Tabby, Tamara, Visa, MC, Apple Pay #}
{% else %}
  {% render 'payment-badges-default' %}
{% endif %}

Common Issues We've Fixed in Client Projects

Problem: SAR prices display correctly on product pages but revert to AED at checkout.
Fix: Check that your payment gateway is configured to accept SAR transactions. If the gateway doesn't support SAR, Shopify falls back to the base currency at checkout. This is the most common multi-currency failure mode in GCC setups.

Problem: KWD prices show with three decimal places (e.g., KWD 12.500).
Fix: KWD is one of the world's highest-value currencies and is denominated to three decimal places. This is technically correct. If you want to display it as KWD 12.5, use Shopify's money filters: {{ product.price | money_without_trailing_zeros }}.

Problem: Arabic locale customers see prices in AED despite being on the SAR market.
Fix: The market assignment is based on the customer's country, not their language selection. Verify that Saudi Arabia is correctly assigned to the SAR market in Settings > Markets. If a Saudi customer is browsing via a VPN from another country, they may see a different market's pricing.

Problem: Tax is being double-applied in UAE (once in Shopify, once at checkout by the gateway).
Fix: Ensure your gateway is configured as a tax-inclusive setup matching your Shopify tax-inclusive display setting. Both Shopify and your gateway should be aware of whether prices already include VAT or are pre-tax.

Results From a Real GCC Multi-Currency Project

For a UAE-based fashion brand we expanded to KSA on Shopify Markets, the transition from automatic currency conversion to fixed SAR pricing was the single highest-impact change in the launch sprint. Checkout abandonment on the KSA variant dropped by approximately 18% in the first two weeks post-launch, which we attribute to cleaner pricing presentation and the trust signal of locally-priced products.

For KSA-specific payment configuration, correctly surfacing MADA via Checkout.com alongside Tamara was the second material lever. MADA usage in KSA is high enough that stores without it visible at checkout are simply not accessible to a significant share of Saudi shoppers.

If you want us to review your current multi-currency setup or build GCC market expansion into your Shopify store from scratch, book a discovery call here.

Frequently Asked Questions

Is Shopify Payments available in the UAE or Saudi Arabia?
No. As of early 2026, Shopify Payments is not available in the UAE, Saudi Arabia, or other GCC countries. You must use a third-party payment gateway. Checkout.com, Telr, and PayTabs are the most commonly used gateways for GCC multi-currency Shopify stores.

Should I use automatic currency conversion or fixed local prices for GCC?
Fixed local prices, for the reasons covered above: better consumer experience, margin predictability, and promotional pricing control. The maintenance overhead is manageable for most brand sizes.

Does Kuwait have VAT?
No. Kuwait does not currently apply VAT to ecommerce purchases. Qatar also has no ecommerce VAT currently. The UAE has 5% VAT; Saudi Arabia has 15% VAT.

How many currencies can I have on one Shopify store?
Shopify supports up to 133 currencies via Shopify Markets. You can have multiple markets, each with different currencies, languages, and pricing. There is no technical limit to the number of GCC markets you configure on a single store.

What happens if a Saudi customer pays in AED instead of SAR?
Shopify assigns the market based on the customer's detected country. If the system correctly identifies a Saudi customer, they'll see SAR pricing and the KSA market configuration. Customers can sometimes manually change their currency: you can restrict this by removing the currency selector from your theme header if you want strict market enforcement.

Can I have different product availability per GCC market?
Yes. Shopify Markets allows you to control which products are available in each market. If certain products aren't compliant for a specific market (e.g., items requiring halal certification that you haven't obtained), you can exclude them from that market's catalogue.

Do I need a separate Shopify store for each GCC country?
No. One Shopify store with properly configured Markets handles all GCC countries from a single codebase, product catalogue, and admin. Separate stores are rarely the right answer and create significant management overhead.

Originally published at Innovatrix Infotech

UAE VAT Compliance for Shopify: The Complete 2026 Setup Guide

Rishabh Sethia — Mon, 17 Aug 2026 09:30:01 +0000

This guide is not tax advice. You should always confirm your specific VAT treatment with a UAE-registered tax agent. What this guide is: a complete, technically accurate walkthrough of how to configure your Shopify store for UAE VAT compliance: one that doesn't gloss over the parts that most generic guides skip.

We've configured UAE VAT for Dubai and UAE-based Shopify clients as part of our work as a Shopify Partner. The technical setup is straightforward. The compliance questions, what needs to be on your invoices, how exports are treated, what changed in January 2026, are where most store owners get it wrong.

What Changed in January 2026

Before we get into the setup, it's worth flagging the VAT rule changes that took effect on January 1, 2026 under Federal Decree-Law No. 16 of 2025 and Federal Decree-Law No. 17 of 2025. These are not minor administrative updates.

Self-invoicing for reverse charge is removed. Previously, when a UAE business purchased services from a foreign supplier (e.g., Shopify subscription fees, Meta advertising), it had to issue a self-invoice to itself under the reverse charge mechanism. From January 2026, this requirement is removed. You no longer self-invoice, but you must maintain the supporting documentation (contracts, purchase orders, payment confirmations) to substantiate the VAT treatment during any FTA audit.

5-year deadline for reclaiming VAT credits. VAT input tax credits from 2021 began expiring in 2026. If you've been carrying forward excess input VAT without filing refund claims, some of that credit may have expired. Check your credit balances and filing history now.

E-invoicing pilot launches July 2026. The UAE is rolling out mandatory e-invoicing in phases. The voluntary pilot starts July 2026, with mandatory compliance for businesses with revenue exceeding AED 50 million starting January 2027. If you're in or approaching that revenue range, start reviewing the requirements now. For most SME Shopify merchants, the mandatory phase arrives in 2027-2028.

Expanded FTA audit powers. The FTA now has explicit authority to deny input VAT recovery if a supply is connected to tax evasion, even if you didn't know about the evasion. Vet your suppliers.

Step 1: Do You Need to Register for VAT?

Before you configure anything in Shopify, you need to know whether you're required to register.

Mandatory registration threshold: AED 375,000 in taxable supplies and imports in any 12-month rolling period. If you've crossed this threshold, you must register within 30 days. Failure to register on time carries an AED 10,000 penalty.

Voluntary registration threshold: AED 187,500. If your taxable supplies are between AED 187,500 and AED 375,000, you can voluntarily register. Voluntary registration is often commercially sensible: it allows you to reclaim input VAT on your business expenses (Shopify subscription, advertising, logistics), which improves your effective cost structure.

If you're a new business: Calculate your projected first-12-month revenue against these thresholds. If you expect to exceed AED 375,000 in year one, register before you start trading to avoid an immediate compliance gap.

Registration is done through the FTA's EmaraTax portal. You'll receive a Tax Registration Number (TRN) that must appear on every VAT invoice you issue.

Step 2: Configure UAE VAT in Shopify

Once you're VAT-registered (or if you're setting up in advance), here's the Shopify configuration:

Go to Settings > Taxes and duties in your Shopify admin
Under Tax regions, click United Arab Emirates
You'll see the option to set a tax rate. The standard rate is 5%
Set the rate to 5% and save

Tax-inclusive vs. tax-exclusive pricing:

In the UAE, B2C ecommerce prices are typically displayed inclusive of VAT: meaning the price your customer sees on the product page already includes the 5% VAT. This is the standard consumer expectation.

To display prices inclusive of VAT:

In Settings > Taxes and duties, check "All prices include tax" under your UAE market
Shopify will calculate the tax component from your price (e.g., if you price at AED 210, Shopify knows AED 10 of that is VAT)

For B2B customers (businesses buying from you who are VAT-registered themselves), you may want to display prices exclusive of VAT. This is a more complex setup requiring different price lists or customer tags. For most D2C Shopify stores, tax-inclusive B2C pricing is the correct default.

Step 3: VAT Invoice Compliance

This is where most Shopify stores have a gap. Shopify's default order confirmation email and invoice template is not fully FTA-compliant out of the box.

What the FTA requires on a UAE VAT invoice:

The word "Tax Invoice" on the document
Your business name and address
Your Tax Registration Number (TRN)
The customer's name and address (for B2B)
A unique, sequential invoice number
The date of the supply
A description of the goods or services
The quantity and unit price
The taxable amount per VAT rate
The VAT rate applied
The total VAT amount
The total amount payable (inclusive of VAT)

What Shopify's default template typically lacks:

Your TRN displayed prominently
A "Tax Invoice" label
Consistent tax-rate breakdowns per line item in some configurations

Fixing this: Two options

Option 1: Sufio (paid app, cleanest solution): Sufio generates FTA-compliant UAE VAT invoices automatically for every order. It handles TRN display, sequential invoice numbering, tax breakdowns, and document formatting. For most SME merchants, this is the fastest path to compliance. Plans start around $19/month.

Option 2: Custom Liquid invoice template: If you want to avoid the ongoing app cost, you can customise Shopify's invoice template yourself. This is a technical task but not an advanced one for anyone comfortable with Liquid.

In your Shopify admin, go to Settings > Notifications > Order invoice. The template uses Liquid syntax. Add your TRN, "Tax Invoice" label, and ensure the tax breakdown renders correctly:

<h1>Tax Invoice</h1>
<p>Tax Registration Number: <strong>{{ shop.metafields.custom.trn }}</strong></p>
<!-- Or hardcode your TRN directly: -->
<p>TRN: <strong>1234567890123456</strong></p>

{% for line in subtotal_line_items %}
  <tr>
    <td>{{ line.title }}</td>
    <td>{{ line.quantity }}</td>
    <td>{{ line.price | money }}</td>
    <td>{{ line.tax_lines | map: 'rate' | first | times: 100 }}%</td>
    <td>{{ line.total_tax | money }}</td>
  </tr>
{% endfor %}

<p>Subtotal (excl. VAT): {{ subtotal_price | minus: tax_price | money }}</p>
<p>VAT (5%): {{ tax_price | money }}</p>
<p><strong>Total (incl. VAT): {{ total_price | money }}</strong></p>

Store your TRN in a Shopify metafield (shop.metafields.custom.trn) so it's maintainable without touching code.

Step 4: Shopify + Accounting Integration for VAT Reporting

Filing your UAE VAT return requires a clear record of your output VAT (VAT you collected from customers) and input VAT (VAT you paid on business expenses). Shopify is your sales system; you need it to flow correctly into your accounting software.

Xero + Shopify:

Xero has a native Shopify integration (or use the A2X connector for more granular control). The integration pulls order revenue, tax, refunds, and payment data into Xero. In your Xero setup:

Create a VAT tax rate in Xero for UAE: 5% on revenue accounts
Map your Shopify income account to your UAE sales account in Xero
Verify that imported Shopify transactions show the correct tax treatment
VAT returns in Xero > Tax > VAT Returns pull this data into the correct FTA return boxes

QuickBooks Online + Shopify:

QuickBooks Online supports UAE VAT (it has a UAE-specific VAT centre). The Shopify connector maps your Shopify sales to QuickBooks. Set up your UAE 5% VAT tax rate in QuickBooks, then run periodic reconciliations between Shopify sales reports and QuickBooks VAT liability.

Key reconciliation items to check monthly:

Total Shopify net revenue should match income in accounting software
Output VAT in your accounting system should match Shopify tax reports (Reports > Taxes > UAE)
Refunds and returns reduce both revenue and VAT: verify these flow correctly
Shopify subscription fees (charged in USD) and Meta/Google ad spend may be subject to reverse charge VAT: confirm with your accountant

Step 5: Cross-Border and Export VAT Treatment

If you're selling from the UAE to customers outside the UAE, the VAT treatment is different, and this is where D2C brands commonly make expensive mistakes.

Exports of goods from UAE are zero-rated (0% VAT). This means you don't charge VAT on goods shipped to customers outside the UAE. You still need to record these as zero-rated supplies on your VAT return, and you need documentation proving the export (airway bill, courier tracking, etc.) because without proof, the FTA can reclassify the sale as standard-rated and assess you for the 5% VAT.

In Shopify, configure export tax handling:

In Settings > Taxes and duties, under UAE tax settings, Shopify can be configured to charge 0% tax for orders shipping to addresses outside the UAE
Verify your shipping zones are correctly mapped: UAE addresses → 5% VAT; international addresses → 0% VAT
Check this configuration in a test order before going live

For KSA customers: Saudi Arabia has its own 15% VAT system. Sales from a UAE store to Saudi Arabia are, for most Shopify merchants, treated as exports from UAE (zero-rated in UAE) and potentially subject to import VAT/customs in KSA at the point of entry. The specifics depend on your product category and delivery structure. Confirm with a UAE tax advisor if this is a significant revenue stream.

Step 6: B2B Customers and Reverse Charge

If you have B2B customers, other VAT-registered UAE businesses buying from you, the invoicing requirements are more stringent, and the reverse charge mechanism may apply in some cases.

For UAE-to-UAE B2B sales, standard 5% VAT applies. Your B2B customer can reclaim this input VAT on their own VAT return, so they'll want a proper VAT invoice from you (see Step 3 above).

For services you purchase from non-UAE suppliers (foreign software, foreign consultants, foreign platforms: including Shopify's own subscription fees if you're not set up with a UAE entity), you as the UAE VAT-registered business account for VAT under the reverse charge mechanism. From January 2026, you no longer need to issue a self-invoice for this, but you must maintain the underlying documentation.

Common Compliance Mistakes We See

No TRN on invoices. The most common and the most obvious gap. If your Shopify order confirmation email doesn't display your TRN, your invoices are technically non-compliant.

Wrong VAT on KSA orders. Stores that haven't configured shipping zones correctly can charge 5% UAE VAT on orders shipping to Saudi Arabia. Saudi-bound shipments from UAE should be zero-rated (export). KSA has its own separate 15% VAT that applies at import.

Ignoring Shopify's own fees. Shopify charges you subscription fees and transaction fees. These may be subject to UAE VAT (Shopify added UAE VAT to its invoices for UAE-registered businesses). Make sure you're capturing this input VAT.

Missing refund VAT adjustments. When you refund a customer, the VAT element of the refund should reduce your output VAT liability. Verify that your accounting integration handles this correctly: some configurations don't pull Shopify refunds into accounting software automatically.

Expired VAT credits. Post-2026, any input VAT credit older than five years expires. If you've been carrying forward credits from 2021, check your position before year-end.

Quick Reference: UAE VAT Setup Checklist

Before going live with a UAE Shopify store, verify:

[ ] VAT registration obtained if above AED 375K threshold (or voluntary registration in place)
[ ] TRN added to Shopify invoice template or via Sufio app
[ ] Shopify tax rate set to 5% for UAE market
[ ] Tax-inclusive pricing enabled for B2C ("All prices include tax")
[ ] Shipping zones configured: UAE = 5% VAT, international = 0% (export)
[ ] Accounting software connected (Xero or QuickBooks) with UAE VAT rates mapped
[ ] Monthly reconciliation process documented
[ ] Export documentation process in place (for international shipments)

If you want a professional review of your Shopify VAT configuration, or you're setting up a new Dubai or UAE ecommerce presence and want it done correctly from day one, book a discovery call here. We don't do tax advisory (for that, you need a UAE-registered tax agent), but we do ensure your Shopify technical configuration matches what your accountant needs.

For KSA context, note that Saudi Arabia's VAT is 15%: three times the UAE rate. Read our multi-currency GCC Shopify guide for how to configure both markets correctly from one store.

Frequently Asked Questions

Is UAE VAT 5% or has it increased?
The UAE standard VAT rate remains 5% as of 2026. There has been no increase. (Saudi Arabia, by contrast, raised its rate from 5% to 15% in 2020. Don't confuse the two.) The 2026 changes were procedural, removal of self-invoicing requirement, 5-year credit expiry, e-invoicing pilot, not a rate change.

Does my Shopify store automatically handle UAE VAT?
Shopify can be configured to collect and display UAE VAT at 5%. But configuration is not automatic: you must set up the tax rate, configure tax-inclusive pricing, and ensure your invoice template includes your TRN. These do not happen by default when you create a Shopify store.

What is the UAE VAT registration threshold?
Mandatory registration: AED 375,000 in taxable supplies in any 12-month rolling period. Voluntary registration: AED 187,500. Failure to register when mandatory carries a AED 10,000 penalty.

Do I need to charge VAT on orders shipped outside the UAE?
No. Exported goods are zero-rated (0% VAT) in the UAE. You must maintain export documentation (courier tracking, airway bills) to substantiate the zero-rating. Without documentation, the FTA can reclassify the sale as standard-rated.

What is the e-invoicing mandate and when does it affect my store?
The UAE is implementing mandatory e-invoicing in phases starting July 2026. The voluntary pilot begins July 2026. Mandatory compliance applies first to businesses with revenue above AED 50 million (from January 2027). Smaller businesses will follow in subsequent phases. For most SME Shopify merchants, mandatory e-invoicing is a 2027-2028 concern, but it's worth understanding the direction now.

What changed with reverse charge VAT in January 2026?
The requirement to issue self-invoices for reverse charge transactions (services purchased from foreign suppliers) was removed. From January 2026, you account for reverse charge VAT without issuing a self-invoice, but you must retain supporting documents (contracts, purchase orders, payment evidence) for audit purposes.

Is Sufio the only option for FTA-compliant Shopify invoices?
No. Sufio is the most popular paid app for this. You can also build compliance into Shopify's native invoice notification template using Liquid: it requires a developer's attention but is technically achievable and has no ongoing monthly cost. For high-volume stores, Sufio's automation saves meaningful admin time.

Originally published at Innovatrix Infotech

How to Add Tabby and Tamara BNPL to Your Shopify Store [UAE Guide]

Rishabh Sethia — Wed, 12 Aug 2026 04:30:02 +0000

UAE shoppers expect Buy Now, Pay Later at checkout. It's not a feature you offer to stand out anymore — it's one you're penalized for not offering. The BNPL market in the UAE is projected to grow from $2.07 billion in 2023 to $4.41 billion by 2029, driven heavily by the 18–35 demographic that makes up a significant portion of online shoppers.

Tabby and Tamara are the two dominant BNPL providers in the UAE. For Shopify merchants, the good news is that both offer official Shopify app integrations. The bad news is that most implementation guides stop at "install the app" — and the stores that just install the app see minimal lift.

The lift comes from where you put the widgets.

This guide walks through the complete installation of both Tabby and Tamara on a Shopify store, the configuration that actually moves conversion metrics, and the gotchas we've encountered building UAE Shopify stores as a Shopify Partner.

What You'll Learn

How Tabby and Tamara work (and the difference between them)
Prerequisites before you apply for merchant accounts
Step-by-step installation for both apps on Shopify
Widget placement strategy: PDP, cart, and checkout
Test mode setup and how to run end-to-end test transactions
Common errors and how to fix them
The AOV optimization layer most stores miss

Prerequisites

Before you start the installation, you need to have the following in place:

For both Tabby and Tamara:

A valid UAE, Saudi Arabia, or Kuwait trade license
A corporate bank account in the same country as your trade license
A live (or near-live) Shopify store URL
An SSL certificate on your domain (Shopify provides this automatically)
Products priced within BNPL eligibility ranges (more on this below)

For Tabby specifically:

Your store must primarily serve UAE, KSA, or Kuwait billing addresses. Tabby only processes orders from these three markets.

For Tamara specifically:

Tamara operates in UAE, Saudi Arabia, Kuwait, and Bahrain. Similar market restrictions apply.

If you don't have a UAE trade license yet, read our guide on how to start an ecommerce business in Dubai first — getting the gateway approved before the business is legally registered is a common sequencing mistake.

Understanding the BNPL Model (Important Before You Apply)

Before integrating, understand exactly how the commercial model works:

For your customers: They split the purchase into 4 equal interest-free installments. For Tabby, 25% is paid upfront at checkout; the remaining 3 payments are auto-debited every 2 weeks or monthly, depending on the plan. For Tamara, options include 2-part or 4-part payments.

For you as the merchant: You receive the full purchase amount upfront. Tabby and Tamara assume the collection risk. Your cost is the merchant discount rate (MDR) — typically 3–6% per transaction, depending on your agreement and monthly volume.

Order eligibility ranges:

Tabby: typically eligible for orders between AED 100 and AED 5,000 (thresholds confirmed at merchant onboarding)
Tamara: similar ranges; confirm specific thresholds during merchant application

Orders below the minimum or above the maximum won't display the BNPL option. Configure your widget display logic accordingly.

Part 1: Installing Tabby on Shopify

Step 1: Apply for a Tabby Merchant Account

Go to tabby.ai and click Become a Partner or Merchant Sign Up.
Fill in your business details: trade license number, business name, website URL, and contact information.
Upload required documents: trade license copy, bank account details (IBAN + bank name), and authorized signatory's ID.
Tabby will review your application. Approval typically takes 2–5 business days. You'll receive your Merchant API Key and Secret Key upon approval.

Do not start Step 2 until you have your API credentials. The app won't function without them.

Step 2: Install the Tabby App from Shopify App Store

In your Shopify Admin, go to Apps → App and sales channel settings → Shopify App Store.
Search for "Tabby" and select the official Tabby app (published by Tabby).
Click Add App and confirm the installation permissions.
You'll be redirected to the Tabby app configuration screen within Shopify Admin.

[SCREENSHOT: Shopify App Store showing the official Tabby app listing]

Step 3: Connect Your Tabby Merchant Account

In the Tabby app, navigate to Settings → API Credentials.
Enter your Public Key and Secret Key from your Tabby merchant portal.
Select your primary market: UAE (AED), Saudi Arabia (SAR), or Kuwait (KWD).
If your store serves multiple GCC markets, Tabby handles currency conversion automatically based on the billing address at checkout.

One thing developers miss here: Tabby processes orders in the customer's billing currency, not your store's base currency. If your store is set to USD base currency but you're serving AED customers, Tabby will convert and process in AED. Ensure your Shopify markets are configured correctly with the right currency enabled for each region.

Step 4: Configure Payment Settings in Shopify

Go to Settings → Payments in Shopify Admin.
Under Alternative Payment Methods, you should now see Tabby listed.
Enable it and confirm the payment method is active.
Set your minimum and maximum order values for Tabby eligibility. This prevents the widget from showing on orders Tabby won't approve.

[SCREENSHOT: Shopify Payments settings showing Tabby enabled as alternative payment method]

Step 5: Add the Tabby Widget to Your Product Pages (Critical Step)

This is where most merchants underperform. Installing the app activates Tabby at checkout. But the conversion lift comes from showing installment amounts on the product page, before the customer even adds to cart.

For Shopify stores using Online Store 2.0 themes:

Go to Online Store → Themes → Customize.
Navigate to your Product template.
Look for "Add block" near your price section.
If the Tabby app has registered a block, it will appear in the block options as "Tabby Installment Widget" or similar.
Add it directly under your price element.

For stores on older themes (not OS 2.0):

You'll need to manually edit the product.liquid or product-template.liquid file. Add the Tabby snippet just below the price display:

<!-- Tabby PDP Widget -->
<div id="TabbyPromo"></div>
<script>
  TabbyPromo.render({
    selector: '#TabbyPromo',
    currency: '{{ shop.currency }}',
    price: {{ product.selected_or_first_available_variant.price | divided_by: 100.0 }},
    lang: 'en',
    source: 'product'
  });
</script>

Note: Tabby provides their own widget initialization script via their merchant portal. The snippet above is illustrative — use the exact script from your Tabby dashboard, as it will include your public key pre-populated.

Also add the widget to your Cart page using the same logic, with source: 'cart' parameter. Showing the installment amount in the cart reinforces the decision already made on the PDP.

[SCREENSHOT: Product page showing Tabby installment widget under price with "4 payments of AED X" display]

Step 6: Enable Test Mode

Before going live, run at least 3 test transactions to verify the full flow.

In your Tabby merchant portal, toggle Test Mode to ON.
Use Tabby's sandbox test credentials (provided in the merchant portal documentation).
Complete a test purchase on your store: add product → proceed to checkout → select Tabby → complete simulated payment.
Verify the order appears in both your Shopify orders dashboard and your Tabby merchant portal.
Test a refund flow as well: initiate a refund in Shopify and confirm Tabby processes it correctly.

Once testing is complete, toggle Test Mode OFF before your store goes live.

Part 2: Installing Tamara on Shopify

Step 1: Apply for a Tamara Merchant Account

Go to tamara.co and navigate to Merchant → Sign Up.
Complete the merchant application with your business license, bank details, and website information.
Tamara is Sharia-compliant and explicitly positioned as such. If your target market includes consumers for whom this matters, Tamara's branding is a selling point you can leverage in your checkout messaging.
Approval timeline: similar to Tabby, typically 3–5 business days.

Step 2: Install the Tamara App from Shopify App Store

Search for "Tamara" in the Shopify App Store.
Install the official Tamara app. The app is listed as free with no installation fees (MDR applies per transaction as negotiated in your merchant agreement).
Confirm installation permissions.

Step 3: Configure Tamara Credentials

In the Tamara app settings, enter your Merchant Token from the Tamara merchant portal.
Select your markets: UAE, Saudi Arabia, Kuwait, or Bahrain.
Configure your installment options: Tamara offers both 2-part and 4-part payment splits. Enable both to give customers maximum flexibility.

Step 4: Add Tamara to Checkout

Like Tabby, Tamara appears as an alternative payment method in your Shopify checkout once the app is installed and credentials are entered. Verify it's enabled under Settings → Payments → Alternative Payment Methods.

Step 5: Widget Placement for Tamara

Follow the same widget placement logic as Tabby — product page under price, cart page, and checkout. Tamara provides its own widget script via the merchant portal.

If you're running both Tabby and Tamara simultaneously, stack the widgets cleanly. Don't clutter the PDP with two separate BNPL badges competing for visual space — use a combined display that shows both options if your theme supports it, or prioritize Tabby (higher UAE adoption) and show Tamara at checkout.

Step 6: Test Tamara

Tamara's test mode works via sandbox credentials in their merchant portal. Follow the same test transaction process as Tabby: full purchase → order confirmation → refund flow.

The AOV Optimization Layer Most Stores Miss

Installing BNPL and having it show at checkout is the floor, not the ceiling.

The stores that see 20–40% AOV lift from BNPL do the following:

1. PDP microcopy placement. "Or 4 payments of AED X with Tabby" placed directly under the price — not below the add-to-cart button, not in a footer FAQ. Under the price.

2. Cart page reinforcement. When a customer has AED 800 in their cart and sees "4 payments of AED 200" in the cart summary, the mental model shifts from "spending AED 800" to "spending AED 200 today." This is the psychological lever.

3. Homepage hero messaging. A one-line callout: "Shop now. Pay in 4 interest-free installments with Tabby." Simple, high-visibility. Especially effective for first-time visitors who don't know BNPL is available.

4. Arabic localization of widgets. If any portion of your traffic is Arabic-speaking, ensure the Tabby/Tamara widgets are configured to display in Arabic. The lift from Arabic mobile users is disproportionate to effort — both Tabby and Tamara support Arabic widget language settings.

5. GA4 tracking. Set a GA4 custom dimension for payment method to track which payment type correlates with higher AOV and lower return rates. Measure before and after BNPL installation with a 30-day comparison window.

We set all of this up as part of our standard UAE Shopify builds. The payment infrastructure isn't just about accepting money — it's a conversion layer that should be engineered, not installed and forgotten. See how we approach this in our Shopify development work for Dubai brands.

Common Issues and Fixes

Issue: Tabby widget not showing on product pages.
Most common cause: the widget is only initialized at checkout, not on the PDP. Check whether you've added the PDP widget snippet separately from the app installation. The app activates checkout; the PDP widget requires a separate implementation step.

Issue: "Tabby cannot process this order" error at checkout.
Likely causes: (1) order amount is below Tabby's minimum or above maximum, (2) customer billing address is outside UAE/KSA/Kuwait, or (3) your API credentials are in test mode on a live store. Check each in order.

Issue: Currency mismatch error.
Tabby processes in AED, SAR, or KWD corresponding to the customer's billing country. If your Shopify market configuration doesn't have the correct currency enabled for the customer's region, you'll see currency mismatch errors. Go to Settings → Markets and verify each market has the correct currency assigned.

Issue: Tamara app not appearing in alternative payment methods.
This usually means your merchant token wasn't saved correctly, or the Tamara app doesn't have the required Shopify permissions. Try removing and reinstalling the app, then re-entering your merchant token.

Issue: BNPL widget is slow to load on mobile.
Both Tabby and Tamara widgets load asynchronously, but a poorly performing theme can delay widget rendering. Load the widget script with async and defer attributes to prevent it from blocking product page load. On mobile, widget render time directly impacts conversion.

What We Typically See in UAT (User Acceptance Testing) Before Launch

Before we hand over any UAE Shopify store with BNPL integrated, our internal checklist covers:

[ ] Tabby widget visible on PDP, positioned under price
[ ] Tamara widget (if installed) visible on PDP
[ ] Cart page shows installment amounts
[ ] Both gateways visible at checkout
[ ] Test transaction completed end-to-end for both Tabby and Tamara
[ ] Refund flow tested and confirmed
[ ] Arabic widget language tested on Arabic language store variant
[ ] Order below minimum threshold — widget correctly hidden
[ ] Order above maximum threshold — widget correctly hidden
[ ] Test mode toggled OFF before handover
[ ] GA4 payment type custom dimension firing correctly

FAQ

Do I need a separate bank account for Tabby and Tamara?
No. Tabby and Tamara settle funds to your existing corporate bank account (the same one registered during merchant onboarding). You don't need a separate account for each provider.

When does Tabby / Tamara pay me as a merchant?
Both providers pay you the full order amount upfront, minus the merchant discount rate. Settlement timing is typically within a few business days, as agreed in your merchant contract.

Can I offer both Tabby and Tamara at the same time?
Yes. Both can coexist as alternative payment methods in Shopify. UAE customers will see both options at checkout and can choose their preferred provider.

What happens if a customer defaults on installment payments?
This is between the customer and the BNPL provider. As a merchant, you've already been paid in full. The default risk sits with Tabby or Tamara, not with you.

Is BNPL available for all product categories in the UAE?
Most physical product categories are eligible. Some BNPL providers restrict certain categories (e.g., financial services, gambling). For standard D2C categories — fashion, beauty, electronics, home goods — there are no restrictions.

Do Tabby and Tamara work with Shopify's draft orders or B2B features?
Both are designed for standard B2C checkout flows. Shopify's draft orders and B2B checkout don't typically trigger BNPL app integrations. For B2B BNPL, you'd need to explore custom API integration directly with the providers.

What BNPL impact should I realistically expect on AOV?
Stores with proper BNPL widget placement (PDP + cart + checkout) typically see AOV increases of 20–40% among orders where BNPL is selected. The overall store AOV uplift depends on BNPL adoption rate. UAE stores we've built have seen BNPL account for 25–35% of order volume within 60 days of launch when properly implemented.

Need help with BNPL integration, payment gateway setup, or a full UAE Shopify build? Our team handles this end-to-end. Book a discovery call to discuss your store.

About the Author

Rishabh Sethia is the Founder & CEO of Innovatrix Infotech. Former Senior Software Engineer and Head of Engineering. DPIIT Recognised Startup | Official Shopify Partner | AWS Partner. He has personally architected payment infrastructure for D2C stores across India, UAE, and Singapore.

Originally published at Innovatrix Infotech

Progressive Web Apps (PWA): Why Your Business Needs One in 2026

Rishabh Sethia — Tue, 11 Aug 2026 09:30:01 +0000

Your competitor just launched an "app" that loads instantly, works offline, and cost them ₹3 lakhs. You quoted ₹15 lakhs for a native iOS + Android app. They used a PWA. Here's what you need to know.

What Is a Progressive Web App (in Plain English)

A Progressive Web App is a website that behaves like a native mobile app. It lives at a URL, runs in a browser engine, but can be "installed" on a phone's home screen — complete with an app icon, splash screen, and full-screen experience. No App Store. No Play Store. No 30% commission.

The magic is in three technologies working together:

Service Workers — background scripts that cache assets and handle offline logic
Web App Manifest — a JSON file that tells the browser "treat this site like an app"
HTTPS — mandatory secure connection (which you should have anyway)

When a user visits your PWA, the browser prompts them to "Add to Home Screen." After that, it looks and feels identical to a native app. The user doesn't know the difference. They don't care.

PWA vs Native App vs Regular Website

Let's kill the confusion with a straight comparison.

Feature	Regular Website	PWA	Native App
Works offline	No	Yes	Yes
Install from browser	No	Yes	No
App Store listing	No	No (usually)	Yes
Push notifications	No	Yes	Yes
Access to camera	Limited	Yes	Yes
Access to GPS	Yes	Yes	Yes
Access to Bluetooth/NFC	No	Limited	Yes
Auto-updates	Instant	Instant	Requires user action
Development cost	Low	Medium	High
Maintenance cost	Low	Low	High (2 codebases)
Discoverability (SEO)	High	High	Low
Performance	Variable	Fast	Fastest
Home screen icon	No	Yes	Yes

The pattern is clear: PWAs sit in the sweet spot between websites and native apps. They give you 80% of native app functionality at 20-30% of the cost.

Why PWAs Matter for Indian Businesses

India isn't Silicon Valley. The ground reality here changes the math completely.

The connectivity problem

Over 300 million smartphone users in India are on inconsistent 3G/4G connections. Pages that take 8 seconds to load on a stable connection take 25 seconds on a flaky tower in Tier 2 and Tier 3 cities. PWAs solve this with aggressive caching — after the first visit, most of the app loads from the device itself.

The storage problem

The average Indian smartphone has 32-64 GB of storage, and it's perpetually full. WhatsApp alone eats 2-5 GB. Users actively avoid downloading new apps. A PWA takes up less than 1 MB of storage. A native app? 50-150 MB minimum.

The cost problem

Building a native app for both iOS and Android means two codebases, two teams (or one expensive cross-platform team), two testing pipelines, and two app store submissions. A PWA is one codebase that works everywhere.

The reach problem

App Store Optimization (ASO) is a grind. Most apps never get discovered. PWAs are websites — they show up in Google search results. Every SEO technique you already use works on a PWA. Your existing traffic becomes your install base.

The real ROI of a PWA isn't just lower development cost — it's the compounding effect of lower acquisition cost, zero app store friction, and instant updates. For most Indian SMBs, this changes the unit economics from "can't afford an app" to "can't afford not to have one."

Real-World PWA Examples That Prove the Point

Flipkart Lite

Flipkart was one of the earliest major PWA adopters. Results: 3x more time spent on site, 40% higher re-engagement rate, 70% increase in conversions. Their PWA loads in under 1 second on 3G connections.

Twitter Lite

Twitter's PWA reduced data consumption by 70% compared to the native app. It loads in under 3 seconds on slow connections and takes up less than 1 MB of storage. It became the default experience for emerging markets.

Starbucks

Starbucks built a PWA for their ordering system. The PWA is 99.84% smaller than their iOS app (233 KB vs 148 MB). Daily active users on the PWA nearly doubled after launch.

OLX

OLX saw a 250% increase in re-engagement after launching their PWA. Page load time dropped by 80%. The lesson: users in price-sensitive markets respond strongly to fast, lightweight experiences.

Cost Breakdown: PWA vs Native App in India (INR)

Let's talk real numbers. These are ranges based on India-based development teams, not US freelancer rates.

Component	PWA Cost (₹)	Native App Cost (₹)
UI/UX Design	1,00,000 – 2,50,000	1,50,000 – 4,00,000
Frontend Development	2,00,000 – 5,00,000	4,00,000 – 12,00,000 (per platform)
Backend/API	1,50,000 – 4,00,000	1,50,000 – 4,00,000
Testing & QA	50,000 – 1,50,000	1,00,000 – 3,00,000
App Store Submission	₹0	₹8,500 (Google) + ₹8,000/yr (Apple)
Total (both platforms)	₹5,00,000 – ₹13,00,000	₹12,00,000 – ₹35,00,000
Annual Maintenance	₹50,000 – ₹1,50,000	₹2,00,000 – ₹6,00,000

That's a 2-3x cost difference on initial build, and a 3-4x difference on ongoing maintenance. For a startup burning through runway, this isn't a minor detail — it's the difference between shipping and not shipping.

Technical Capabilities: What PWAs Can and Cannot Do in 2026

PWA capabilities have expanded dramatically. Here's the honest state of things.

What PWAs can do well

Offline mode — cache pages, data, and media for full offline use
Push notifications — supported on Android, iOS (since iOS 16.4), and desktop
Camera access — photo and video capture via MediaDevices API
Geolocation — GPS access with user permission
Background sync — queue actions offline, sync when connected
File system access — read/write local files (with user permission)
Payment processing — Web Payment API for native-feeling checkout
Biometric auth — fingerprint/face via Web Authentication API
Screen orientation lock — force landscape/portrait
Share target — appear in the OS share sheet
Badging — show notification counts on the app icon

What PWAs still cannot do (or do poorly)

Bluetooth/NFC — Web Bluetooth exists but browser support is patchy
Advanced AR/VR — possible but performance lags behind native
Background audio/location — limited compared to native apps
Inter-app communication — no deep OS integration
App Store presence — you can wrap a PWA in TWA (Trusted Web Activity) for Play Store, but Apple's App Store still resists
iOS limitations — Safari still lags behind Chrome in PWA support (no background sync, limited push notification customization)

The gap is closing every quarter. Chrome ships new PWA APIs almost monthly. The direction is clear — the web platform is absorbing native capabilities.

When to Choose PWA Over Native App

This is the decision framework we use with every client.

Choose PWA when:

Your app is primarily content-driven (news, e-commerce, catalogs, dashboards)
You need to reach users who won't download apps
Budget is under ₹15 lakhs for both platforms
Speed to market matters more than pixel-perfect native feel
SEO and web discoverability are important growth channels
Your target users are on mid-range Android devices
You need instant updates without app store review cycles

The decision flowchart in plain language:

Start here: Does your app need Bluetooth, NFC, advanced AR, or deep OS integration?

Yes → Go native.
No → Next question: Is App Store presence a hard business requirement (investor demand, enterprise policy)?
- Yes → Go native, or consider TWA wrapper for Play Store + native for iOS.
- No → Next question: Is your budget under ₹15 lakhs and timeline under 3 months?
- Yes → PWA is your answer.
- No → Evaluate whether the extra budget buys you capabilities you actually need. If it's just "feels more premium," go PWA.

When NOT to Choose PWA

Honesty builds trust. Here's where PWAs fall short.

Don't build a PWA if:

You need heavy device hardware access — fitness trackers, IoT controllers, medical devices. The Web Bluetooth and Web USB APIs are improving, but they're not production-ready for mission-critical hardware.
Your app is graphics-intensive — gaming apps, complex 3D visualizations, or AR experiences. WebGL and WebXR exist, but native still wins on frame rates and battery efficiency.
Apple ecosystem is your primary market — if 70%+ of your users are on iPhones, you'll constantly fight Safari's PWA limitations. Apple has commercial incentives to keep PWAs second-class citizens.
You need background processing — apps that must run background location tracking, continuous Bluetooth connections, or background audio (like a music player) need native capabilities.
Enterprise MDM is required — if your app needs to be managed through Mobile Device Management systems, native is the only real option.
App Store credibility matters — some B2B buyers and enterprise clients perceive App Store presence as a credibility signal. Irrational? Maybe. Real? Absolutely.

Implementation Roadmap: From Website to PWA in 4 Weeks

If you already have a modern website (React, Next.js, Vue, or similar), converting to a PWA is faster than you think.

Week 1: Audit and Foundation

Performance audit (Lighthouse score baseline)
HTTPS verification (mandatory for service workers)
Create Web App Manifest (app name, icons, theme colors, display mode)
Generate app icons in all required sizes (192x192, 512x512 minimum)
Set up basic service worker with cache-first strategy for static assets

Week 2: Offline Experience

Implement offline fallback page
Cache critical routes and API responses
Add background sync for form submissions and user actions
Test offline behavior across devices
Implement cache versioning and cleanup strategy

Week 3: Engagement Features

Push notification setup (Firebase Cloud Messaging or equivalent)
Add to Home Screen prompt optimization
Implement app shell architecture for instant loading
Add loading skeletons and optimistic UI patterns
Set up analytics for PWA-specific metrics (install rate, offline usage)

Week 4: Testing, Optimization, and Launch

Cross-browser testing (Chrome, Safari, Firefox, Samsung Internet)
Performance optimization (target Lighthouse PWA score of 90+)
Accessibility audit
Submit to Microsoft Store and Google Play Store (via TWA) if desired
Monitor Core Web Vitals post-launch

Performance Metrics: What to Expect

After launching a PWA, here are realistic benchmarks based on projects we've shipped:

First Contentful Paint: Under 1.5 seconds on 4G, under 3 seconds on 3G
Time to Interactive: Under 3 seconds on 4G
Lighthouse PWA Score: 90+ (aim for 95+)
Repeat visit load time: Under 0.5 seconds (cached)
Install rate: 3-8% of regular visitors (varies by prompt strategy)
Engagement increase: 20-40% more time on site vs mobile web
Conversion lift: 15-30% improvement (based on e-commerce benchmarks)
Bounce rate reduction: 20-35% lower than mobile web

These aren't aspirational numbers. They're what happens when you eliminate 3-second load times and give users an app-like experience without the download friction.

FAQ

Do PWAs work on iPhones?

Yes, but with caveats. Since iOS 16.4, Safari supports push notifications for PWAs. However, Apple still restricts background sync, badge updates are limited, and there's a 50 MB storage cap for cached data. PWAs work well on iOS for content-driven apps, but you'll hit walls with advanced features.

Can a PWA be listed on the Google Play Store?

Yes. Using Trusted Web Activities (TWA), you can wrap your PWA and publish it on Google Play Store. It looks and behaves like a native app to the user. Apple's App Store is a different story — they actively resist PWA wrappers.

How much does a PWA cost compared to a native app?

A PWA typically costs 40-60% less than building native apps for both iOS and Android. For an India-based team, expect ₹5-13 lakhs for a PWA vs ₹12-35 lakhs for native apps covering both platforms. Maintenance costs are 3-4x lower for PWAs.

Will a PWA replace my existing website?

A PWA doesn't replace your website — it upgrades it. Your existing URL, content, and SEO rankings stay intact. You're adding capabilities (offline, installability, push notifications) on top of what you already have.

Can PWAs work completely offline?

They can work offline for cached content and pre-loaded data. They cannot fetch new data from a server without an internet connection. The trick is smart caching — pre-loading the content users are most likely to need. E-commerce catalogs, article feeds, and dashboards work great offline. Real-time messaging does not.

Are PWAs secure?

PWAs require HTTPS by default, which means all data in transit is encrypted. Service workers run in a sandboxed environment. The security model is the same as the web — which is more mature and battle-tested than most native app security implementations.

How long does it take to build a PWA?

If you're converting an existing modern website: 3-5 weeks. If you're building from scratch: 8-14 weeks, depending on complexity. That's roughly 40-60% faster than native app development for equivalent functionality.

Do PWAs affect SEO?

Positively. PWAs are websites, so they're fully indexable by search engines. The performance improvements (faster load times, better Core Web Vitals) actively boost your search rankings. Unlike native apps, every page of your PWA can rank independently in search results.

The PWA vs native app debate isn't about which technology is "better." It's about which one fits your budget, timeline, audience, and technical requirements. For most Indian businesses shipping their first mobile experience, the answer is increasingly clear.

Thinking about a PWA for your business? Let's discuss if it's the right move for your specific case.

Originally published at Innovatrix Infotech

How to Integrate Razorpay Payment Gateway in Shopify: Complete 2026 Guide

Rishabh Sethia — Mon, 10 Aug 2026 09:30:01 +0000

Razorpay is India's most popular payment gateway. Shopify is India's fastest-growing e-commerce platform. Getting them to work together properly — with UPI, EMI, COD, and proper GST invoicing — requires more than just installing an app.

This guide covers the complete integration, including the edge cases most tutorials skip.

Step 1: Set Up Your Razorpay Account

Before you touch Shopify:

Create a Razorpay account at razorpay.com
Complete KYC (business documents, bank account, PAN/GST)
Get your Live API Keys from Dashboard > Settings > API Keys
Enable the payment methods you need: UPI, cards, netbanking, wallets, EMI, COD

Note: KYC approval takes 2-7 working days. Don't start Shopify setup until your Razorpay account is live and approved.

Step 2: Install Razorpay on Shopify

Go to Shopify Admin > Settings > Payments
Under "Third-party providers," search for Razorpay
Install the official Razorpay app from Shopify App Store
Enter your Live API Key ID and Key Secret
Enable "Test mode" first to verify the integration

Important: Shopify charges a 2% transaction fee on all third-party payment gateways if you're on Basic or Shopify plans. To eliminate this fee, you need Shopify Advanced (₹21,000/mo) or Shopify Plus. For most Indian stores, the math makes sense to stay on Basic/Shopify plan and absorb the fee until revenue justifies the upgrade.

Step 3: Configure Payment Methods

UPI (Critical for India)

In Razorpay Dashboard > Settings > Configuration:

Enable UPI (VPA, QR Code, and UPI Intent)
Test with a real UPI ID before going live
UPI is the #1 payment method for Indian online stores — don't skip this

EMI

Enable in Razorpay Dashboard under Payment Methods > EMI
Specify minimum order amount for EMI (typically ₹5,000+)
No-cost EMI requires coordination with your bank partner (Razorpay handles this)

COD (Cash on Delivery)

Shopify handles COD natively — you don't need Razorpay for this. Set it up under Settings > Payments > Manual payment methods > Cash on Delivery.

For COD fraud prevention, use Razorpay's COD Intelligence feature (available on Growth/Scale plans) which scores orders for fraud risk.

Step 4: GST and Invoice Setup

India requires GST-compliant invoices for all B2C transactions above ₹50,000 (B2B invoices for all amounts). Shopify's native invoicing is not GST-compliant.

Options:

Razorpay Tax Invoice (built into Razorpay) — Generates GST-compliant invoices automatically. Enable in Razorpay Dashboard > Tax.
Shopify apps like QuickBooks GST or Zoho Books integration — More comprehensive, syncs with accounting.
Custom Liquid template — If you want Shopify's native order confirmation to be GST-compliant.

For most stores, Razorpay's built-in tax invoice is sufficient.

Step 5: Testing Checklist

Before going live, test every payment flow:

[ ] Card payment (domestic and international)
[ ] UPI payment (scan QR + enter VPA)
[ ] Netbanking
[ ] Wallets (Paytm, PhonePe if enabled)
[ ] EMI (if enabled)
[ ] COD
[ ] Refund flow (refund a test order and verify it processes)
[ ] Webhook delivery (verify Shopify receives order confirmation from Razorpay)

Common Issues and Fixes

Order stuck in "Pending Payment": Usually a webhook issue. Verify your webhook URL in Razorpay Dashboard > Settings > Webhooks. The URL should be https://yourstore.myshopify.com/webhook/razorpay.

Duplicate orders: Happens when Razorpay sends multiple webhook events. Enable idempotency in Razorpay settings to prevent duplicate processing.

UPI timeout errors: Default UPI timeout is 3 minutes. For higher-value orders, customers may need more time. Contact Razorpay support to extend timeout.

GST invoices not generating: Ensure your business GST number is added in both Razorpay and Shopify settings.

Need expert help? Innovatrix Infotech is a professional Shopify development agency in Kolkata handling integrations across India. Get a free consultation.

Originally published at Innovatrix Infotech

Next.js vs WordPress: Which Should You Build On?

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

Your developer says WordPress is "legacy" and you should use Next.js. Your marketing person says WordPress is fine. They're both half right. Here's the full picture.

We build on both platforms — roughly 60% of our projects are WordPress, 40% are Next.js (or React-based). We don't have a horse in this race. We recommend whatever makes sense for the project. This post is an honest breakdown to help you decide.

What Is WordPress, Really?

WordPress is a content management system (CMS) that powers about 43% of all websites on the internet. It started as a blogging platform in 2003 and evolved into a full website builder.

In business terms: WordPress is a ready-made building that you customize. You pick a theme (the look), install plugins (the features), and add your content. You don't need to know how to code to manage it day-to-day.

Key characteristics:

Open-source and free (you pay for hosting, themes, and plugins)
Massive plugin ecosystem (60,000+ plugins)
Visual page builders available (Elementor, Divi, Gutenberg)
Content editors can update text, images, and pages without developer help
Widely understood — easy to find developers, designers, and agencies

What Is Next.js, Really?

Next.js is a React-based web framework built by Vercel. It's used to build fast, modern websites and web applications. Companies like Netflix, Nike, Notion, and TikTok use Next.js.

In business terms: Next.js is a custom-built building from the ground up. Every feature is purpose-built. It's faster and more flexible, but you need an architect (developer) for almost everything.

Key characteristics:

Built on React (the most popular JavaScript library)
Server-side rendering (SSR) and static generation (SSG) for speed
No built-in content editor — needs a separate CMS (Directus, Sanity, Contentful, etc.)
Requires developers for most changes
Deployed on platforms like Vercel, Netlify, or AWS

Performance and Speed

This is where the conversation usually starts, and where Next.js has a clear advantage.

Metric	WordPress	Next.js
Average page load (optimized)	1.5–3 seconds	0.5–1.5 seconds
Largest Contentful Paint (LCP)	2–4 seconds	0.8–2 seconds
Time to Interactive (TTI)	3–6 seconds	1–3 seconds
Core Web Vitals pass rate	~33% of WordPress sites	~70% of Next.js sites
CDN/Edge deployment	Requires setup (Cloudflare, etc.)	Built into Vercel/Netlify

Why the gap? WordPress loads PHP on every request (unless heavily cached), pulls from a MySQL database, and typically carries the weight of multiple plugins. Next.js pre-renders pages at build time or on the server, serves them from edge CDNs, and ships minimal JavaScript.

The caveat: A well-optimized WordPress site with proper caching (WP Rocket, Cloudflare, good hosting) can be fast. A poorly built Next.js site can be slow. Platform matters less than implementation. But Next.js makes fast the default; WordPress makes fast something you have to work for.

Content Editing: Who Updates the Website After Launch?

This is the most important question most businesses skip.

If your marketing team needs to update content weekly — blog posts, landing pages, product descriptions, banners — the editing experience matters more than raw performance.

WordPress

Built-in visual editor (Gutenberg block editor)
Page builders like Elementor give non-technical users drag-and-drop control
Media library for image management
Plugins for SEO (Yoast/Rank Math), forms, e-commerce, and more
Your marketing intern can update the homepage without calling a developer

Next.js

No built-in editor. You need a headless CMS (Directus, Sanity, Contentful, Strapi)
Content editors work in the CMS dashboard, which may feel less intuitive than WordPress
Page layout changes almost always require a developer
More powerful for custom content structures, but steeper learning curve for non-technical users

"The best website platform is the one your team will actually use. We've seen businesses spend ₹10 lakhs on a Next.js site and then never update it because nobody on the team could figure out the CMS. That beautiful site becomes stale within 6 months."

Cost: Build and Maintain

Let's talk real numbers. These are based on agency rates in India for a business website (not a basic template site, but a properly designed, functional business website).

Cost Factor	WordPress	Next.js
Design + Development	₹50,000 – ₹3,00,000	₹1,50,000 – ₹8,00,000
Hosting (annual)	₹3,000 – ₹30,000	₹0 – ₹24,000 (Vercel free tier covers most)
CMS	Included (WordPress itself)	₹0 – ₹50,000/year (depends on CMS choice)
Plugins/Integrations	₹0 – ₹20,000/year (premium plugins)	Usually custom-built (included in dev cost)
Ongoing maintenance	₹5,000 – ₹20,000/month	₹3,000 – ₹15,000/month
Content updates (DIY)	Easy — no developer needed	Moderate — CMS-dependent
Content updates (developer)	₹1,000 – ₹3,000 per change	₹2,000 – ₹5,000 per change

The real cost difference isn't the build — it's the ongoing maintenance and updates. WordPress is cheaper to update because non-technical people can do it. Next.js requires developer involvement for anything beyond content text changes.

SEO Capabilities

Both platforms can rank well on Google. The question is how much effort it takes.

WordPress SEO

Plugins like Yoast SEO and Rank Math handle meta tags, sitemaps, schema markup, and content analysis out of the box
Built-in blog with categories, tags, and RSS feeds
URL structure is customizable
Thousands of SEO tutorials and guides available
Risk: Plugin bloat slows the site, which hurts SEO. Many WordPress sites have 30+ plugins, each adding database queries and HTTP requests.

Next.js SEO

Full control over meta tags, structured data, and rendering strategies
Server-side rendering means search engines see fully rendered content (no JavaScript dependency)
Built-in Image Optimization (next/image) for Core Web Vitals
Dynamic sitemap generation
Risk: Requires a developer who understands SEO. React developers often don't think about meta tags, heading hierarchy, or structured data unless specifically asked.

Bottom line: WordPress makes basic SEO easy for everyone. Next.js makes advanced SEO possible for developers who know what they're doing. If you don't have an SEO-aware developer, WordPress with Rank Math will outperform a Next.js site where nobody configured the meta tags.

Developer Availability and Hiring

Factor	WordPress	Next.js
Global developer pool	Massive (millions)	Growing but smaller
Indian freelancer cost	₹500–₹2,000/hour	₹1,000–₹4,000/hour
Agency availability	Nearly every agency	Mid-to-senior agencies
Finding a replacement dev	Easy	Moderate
Code handoff complexity	Low (standard structure)	Higher (depends on architecture)

WordPress developers are everywhere. If your current developer disappears, you can find a replacement within a week. Next.js developers are more specialized. If your developer leaves and didn't document the codebase, onboarding a new one takes time.

When Next.js Wins

Choose Next.js when:

Performance is critical. E-commerce stores, SaaS marketing sites, and any business where page speed directly impacts revenue.
You need custom functionality. Dashboards, calculators, interactive tools, complex filtering, user accounts — things that go beyond a typical "website."
You have developer resources. Either in-house or a reliable agency on retainer.
You're building a web application, not just a website. If your site has user authentication, real-time data, or complex state management, Next.js is the right choice.
You want long-term scalability. Next.js sites don't slow down as you add content. WordPress sites often do.
Brand experience matters. If you want Apple-level scroll animations, micro-interactions, and a polished feel, Next.js gives you full control.

When WordPress Wins

Choose WordPress when:

Your team updates content frequently. Blogs, news sites, magazines, and content-heavy businesses. WordPress's editor is still the best for non-technical content creators.
Budget is tight. You need a professional site for under ₹1,50,000. WordPress gets you there. Next.js at that budget will feel half-finished.
You need to launch fast. A WordPress site can go from zero to live in 2–4 weeks. A Next.js site typically takes 4–8 weeks minimum.
You don't have ongoing developer access. If you can't afford a developer on retainer, WordPress lets you manage most things yourself.
E-commerce with WooCommerce. If you need an online store and Shopify isn't the right fit, WooCommerce on WordPress is mature and well-supported.
You need a simple blog or portfolio. Don't over-engineer it. WordPress is perfectly fine for straightforward content sites.

The Hybrid Option: Headless WordPress + Next.js

There's a third path that combines the strengths of both: use WordPress as your content management system, but render the frontend with Next.js.

How it works:

Your content team writes and manages content in WordPress (familiar interface)
WordPress exposes content via its REST API or GraphQL (using WPGraphQL plugin)
Next.js fetches that content and renders it as a fast, modern frontend
Users see a Next.js site; editors see WordPress

Pros:

Best editing experience (WordPress) + best performance (Next.js)
Content team doesn't need to learn a new CMS
Full frontend control for developers
Better security (WordPress admin is not publicly accessible)

Cons:

Most expensive option. You're maintaining two systems.
Complexity. Debugging issues requires understanding both WordPress and Next.js.
Preview is harder. Previewing drafts requires extra setup to work between the two systems.
Not always worth it. For most small-to-medium business websites, the added complexity isn't justified.

Our recommendation: Headless WordPress makes sense for content-heavy sites (media companies, large blogs, multi-author publications) where the editing experience is paramount but performance can't be compromised. For most business websites, pick one or the other.

Platform Decision Checklist

Answer these questions honestly:

[ ] Will non-technical team members update the website weekly? → Lean WordPress
[ ] Is page speed a direct revenue driver (e-commerce, SaaS)? → Lean Next.js
[ ] Is your budget under ₹1,50,000? → WordPress
[ ] Do you need custom interactive features (calculators, dashboards, filtering)? → Next.js
[ ] Do you have a developer or agency on retainer? → Either works
[ ] Do you need to launch within 2–3 weeks? → WordPress
[ ] Is your site primarily a blog or content hub? → WordPress
[ ] Are you building a web app, not just a website? → Next.js
[ ] Do you want full control over animations and user experience? → Next.js
[ ] Will you realistically maintain this site for 3+ years? → Consider long-term costs above

FAQ

Is WordPress dying?

No. WordPress powers 43% of the web and that number is still growing. What's changing is that modern frameworks like Next.js are capturing a larger share of new builds, especially for tech-savvy companies. WordPress isn't dying; it's just no longer the only serious option.

Is Next.js harder to learn than WordPress?

For non-developers, yes — significantly. WordPress has a visual interface. Next.js requires coding knowledge (React, JavaScript/TypeScript). But this question usually misses the point: you probably won't be coding your site yourself. What matters is whether your team can manage the site after launch.

Can I migrate from WordPress to Next.js later?

Yes, but it's essentially a rebuild. Your content can be exported and re-imported, but the frontend, design, and functionality need to be rebuilt from scratch. Budget for 70–80% of a new build cost. Plan the migration during a slow period.

What about Shopify vs WordPress for e-commerce?

Different comparison entirely. If e-commerce is your primary business, Shopify is usually the better choice over both WordPress (WooCommerce) and Next.js. Shopify handles payments, inventory, shipping, and compliance out of the box. We've written a separate comparison on this.

Which is more secure?

Next.js has a smaller attack surface because there's no admin panel exposed to the internet and no plugin ecosystem to exploit. WordPress is the most attacked CMS on the web — not because it's insecure, but because it's the biggest target. A properly maintained WordPress site with security plugins, strong passwords, and regular updates is secure. But "properly maintained" is the key phrase.

What does Innovatrix Infotech recommend?

It depends on the project. For our own website, we use Next.js with Directus as the headless CMS — because we have the dev team to maintain it and we wanted full control over performance and animations. For many of our clients, especially small businesses and content-driven sites, we recommend WordPress because it gives them independence after launch.

Can I start with WordPress and add Next.js later?

Yes — this is the headless WordPress approach described above. You keep WordPress for content management and add a Next.js frontend on top. It's more complex than starting fresh with Next.js, but it preserves your existing content workflow.

The Honest Answer

There is no universally "better" platform. There's only the right platform for your specific situation, budget, team, and goals.

If you're still unsure, here's the simplest decision framework:

If you need a website (content, services, portfolio, blog) → WordPress
If you need a web *experience* (interactive, fast, custom, branded) → Next.js
If you need both and have the budget → Headless WordPress + Next.js

We build on both. Tell us what your website needs to do and we'll recommend the right stack — honestly.

Tell Us About Your Project →

Need expert help? Innovatrix Infotech offers professional web development services for businesses across India. Get a free consultation.

Originally published at Innovatrix Infotech

Make.com Automation Recipes: 10 Workflows Every D2C Brand Should Run

Rishabh Sethia — Wed, 05 Aug 2026 04:30:02 +0000

Make.com is genuinely excellent for D2C brands. The visual scenario builder is the best in the industry — better than n8n for clients who need to own and modify their automations without a developer present. The native Shopify, Gmail, Slack, and Google Workspace modules are polished and reliable.

Where Make.com gets expensive: operations. Every module execution counts as an operation, and Make.com's pricing is per operation. A 10-module scenario that runs 100 times/day = 1,000 operations. At scale, this is where we evaluate switching to n8n (which charges per workflow execution, not per step). More on that below.

For D2C brands processing up to 200-300 orders/day, Make.com is typically the right choice. Here are the 10 recipes we build and recommend.

The 10 Recipes

Recipe 1: Abandoned Cart WhatsApp Recovery

The scenario: Shopify checkout/abandoned webhook → Wait 60 minutes → Verify order not completed → Send WhatsApp via MSG91/Gupshup

Make.com modules used: Webhook (trigger) → Sleep → Shopify: Search Orders → Router → HTTP: WhatsApp API

Operations per execution: 5 operations

Business outcome: For D2C brands, this is the single highest-ROI automation. WhatsApp recovery outperforms email recovery consistently. We deployed a version of this for Baby Forest India and it contributed to a 22% reduction in cart abandonment during their launch month.

Make.com vs n8n here: Make.com works well for this. The Sleep module handles the 60-minute wait without the queue-mode setup that n8n requires for self-hosted instances. If you're non-technical, Make.com is the easier path.

Recipe 2: Order Confirmation + Upsell Sequence

The scenario: Shopify orders/paid → Send branded WhatsApp/SMS confirmation → Wait 24 hours → Check repeat purchase history → Send personalised upsell for complementary product

Make.com modules used: Shopify (trigger) → Router → HTTP: Messaging API → Sleep → Shopify: Get Customer Orders → Router → HTTP: Upsell message

Operations per execution: 7 operations

Business outcome: Most brands send the transactional confirmation and stop. The upsell branch — triggered only for customers with 0 previous orders (new buyers are most receptive) — has produced measurable lift in average order value. We've seen +15-20% repeat purchase rate improvement in the 90 days following deployment for skincare and wellness brands where the product catalogue naturally lends itself to complementary recommendations.

Pro tip: The Router module is key. One branch sends the upsell to new customers; another branch sends a loyalty acknowledgement to repeat buyers. Same trigger, different message, right person.

Recipe 3: Pre-Shipment Delay Alert

The scenario: Shopify order created → Wait 48 hours → Check if fulfillment_status is still unfulfilled → If yes, send customer a WhatsApp with estimated timeline + customer service link

Make.com modules used: Shopify (trigger) → Sleep → Shopify: Get Order → Filter → HTTP: WhatsApp API

Operations per execution: 5 operations

Business outcome: This one is underrated. Most brands only communicate delays reactively, after the customer emails support asking "where's my order?" This automation sends a proactive message before the complaint arrives. For a fashion brand we work with, deploying this reduced "where's my order?" support tickets by 35% within two months. The customer feels looked after; the support team handles fewer reactive queries.

Recipe 4: Fulfilment Notification + Tracking Link

The scenario: Shopify fulfillments/create webhook → Extract carrier + tracking number → Send WhatsApp with tracking link and estimated delivery date

Make.com modules used: Webhook → Shopify: Get Order → Tools: Set Variable (format tracking URL) → HTTP: WhatsApp API

Operations per execution: 4 operations

Business outcome: Transactional but important. Customers who receive proactive shipping updates are less likely to contact support. The tracking link should be deep-linked to the carrier's tracking page with the order number pre-filled, not just the carrier homepage. This is a detail most off-the-shelf tools miss — Make.com's Tools module lets you construct the exact URL format each carrier uses.

Recipe 5: Post-Purchase Review Request (3-Day Sequence)

The scenario: Shopify orders/fulfilled → Wait 3 days → Send WhatsApp review request with Google Review link → If no review in 5 days, send follow-up email with discount code

Make.com modules used: Shopify (trigger) → Sleep (3 days) → HTTP: WhatsApp → Sleep (5 days) → Gmail: Send review follow-up

Operations per execution: 5 operations

Business outcome: For a Shopify wellness brand, this 3+5 day sequence tripled their review volume in 90 days — Google reviews went from 67 to 190+. The two-channel approach matters: WhatsApp for the initial ask (high open rate), email with an incentive for the follow-up (higher conversion for the segment that didn't respond to WhatsApp). Don't use both on the same day — the 5-day gap is deliberate.

Recipe 6: New Lead → CRM + AI Qualification + Slack Alert

The scenario: New form submission (Typeform/website contact form) → Create HubSpot contact → OpenAI: Score lead quality (1-5) → Router: Route by score → Slack alert for score 4-5

Make.com modules used: Webhook → HubSpot: Create Contact → OpenAI: Chat (scoring prompt) → JSON: Parse score → Router → Slack: Send Message

Operations per execution: 6 operations

Business outcome: See our AI lead qualification workflow for the full story. The key insight: routing hot leads (4-5) to Slack for immediate follow-up while cold leads (1-2) enter a nurture sequence improved sales conversion rate by 34% on scored leads. The team stopped spending time on conversations that were unlikely to close.

Make.com vs n8n here: Make.com's OpenAI module is more limited than n8n's — no streaming, no function calling. For simple scoring prompts where you only need a single text output, it works. For agentic multi-tool behaviour, use n8n.

Recipe 7: Low Stock Alert + Supplier Reorder Email

The scenario: Scheduled trigger (every morning 8 AM) → Shopify: Get All Inventory Levels → Filter: Stock < threshold → Gmail: Send formatted reorder email to supplier with SKU list

Make.com modules used: Scheduler (trigger) → Shopify: List Inventory Levels → Iterator → Filter → Array Aggregator → Gmail: Send

Operations per execution: Variable — approximately 3-5 operations per SKU checked + 1 email. For a 100-SKU catalogue, ~400-500 operations/day. This is where Make.com gets expensive at scale. For brands with 500+ SKUs running daily checks, switch to n8n.

Business outcome: A Kolkata home goods brand went from reactive stockout discovery ("sorry, out of stock" after a customer orders) to proactive same-day reorder decisions. Zero reactive stockouts in four months post-deployment.

Recipe 8: Refund Confirmation + Proactive Status Update

The scenario: Shopify refunds/create webhook → Send WhatsApp confirmation with refund amount + timeline → Wait 5 days → Check if refund is still pending → If yes, send proactive update

Make.com modules used: Webhook → HTTP: WhatsApp → Sleep → Shopify: Get Order → Filter (refund still pending?) → HTTP: WhatsApp follow-up

Operations per execution: 6 operations

Business outcome: For a high-return D2C brand (fashion, baby products), refund communication is a major support ticket driver. This automation cut "where's my refund?" tickets by 40% for a brand processing 50+ returns/month. Proactive communication transforms frustrated customers into neutral or even loyal ones.

Recipe 9: Monthly Revenue Report Auto-Generation

The scenario: Scheduled trigger (1st of month, 9 AM) → Shopify: Get previous month's orders → Tools: Aggregate by metric → Google Sheets: Populate report template → Gmail: Send PDF summary

Make.com modules used: Scheduler → Shopify: List Orders → Iterator → Tools: Set Variables → Array Aggregator → Google Sheets: Update → Gmail: Send

Operations per execution: Roughly 5 operations per order + 3 base operations. For a brand with 800 orders/month: ~4,003 operations once/month.

Business outcome: The report that used to take a founder 3 hours to compile manually arrives automatically before morning chai. Revenue by channel, top SKUs, AOV, new vs. returning split. No manual work, 100% consistent formatting every month.

Make.com cost check: 4,000 operations once a month is negligible. This is one of the most cost-efficient scenarios on this list.

Recipe 10: Social Media Content Scheduler from Google Sheet

The scenario: Google Sheets: Watch for new rows (content calendar) → Router (platform) → Facebook/Instagram: Schedule post OR HTTP: Twitter/X API OR HTTP: LinkedIn API

Make.com modules used: Google Sheets (trigger: new row) → Router → Facebook Pages: Create Post / Instagram for Business: Create Photo → HTTP (Twitter, LinkedIn)

Operations per execution: 3-4 operations per post

Business outcome: The content calendar in Google Sheets becomes the single source of truth. Copy, image URL, platform, date/time — all in one sheet. Make.com polls the sheet every 15 minutes and publishes when the scheduled time arrives. No more logging into 4 platforms to schedule posts. A 5-person brand saved 6 hours/week on social media management.

Our Pick: This is one of the strongest Make.com use cases. The native Facebook and Instagram modules are significantly better than n8n's equivalents because Meta maintains official Make.com integrations. For social scheduling specifically, Make.com wins.

Make.com vs n8n: When to Use Which

Based on our work with D2C brands across India and the Middle East, here's the honest breakdown:

Use Make.com when:

Your team will manage and modify automations without a developer
You need polished native integrations with Meta, Google Workspace, HubSpot
Order volume is moderate (under 300/day)
You want visual scenario building that non-technical team members can read

Use n8n when:

Order volume is high (300+/day) and per-operation costs become significant
You need self-hosting for data sovereignty
You need complex JavaScript logic in Code nodes
You want agentic AI capabilities (n8n's AI Agent node is significantly more capable)
You're building multi-step, complex workflows where debugging transparency matters

For many clients, we actually run both: Make.com for the customer-facing automations (social, messaging) where the native integrations are superior, and n8n for the high-frequency operational automations (order sync, inventory) where execution cost matters.

What These Cost on Make.com

Make.com's free tier includes 1,000 operations/month. For the 10 recipes above, a brand processing 100 orders/day will consume roughly:

Recipes 1-5 (order-triggered): ~25 operations per order × 100 orders = 2,500 operations/day = 75,000/month
Recipes 6-10 (varied triggers): ~5,000-10,000 operations/month

Total: ~80,000-85,000 operations/month

Make.com's Core plan (10,000 operations) costs $10/month. Their Pro plan (50,000 operations) costs $16/month. For 85,000 operations, you're on the Teams plan (~$29/month) or purchasing additional operations.

At 300+ orders/day, the math changes. At that volume, we recommend evaluating n8n self-hosted (€20-55/month regardless of operations).

Want these built for your brand? Our AI automation service includes Make.com and n8n builds, with our managed services covering ongoing maintenance.

Frequently Asked Questions

Does Make.com work with Indian payment gateways like Razorpay and PayU?

Make.com doesn't have native Razorpay or PayU modules, but both support webhooks — use Make.com's Custom Webhook module to receive payment events. For Razorpay specifically: Webhook → Filter (payment.captured event) → your automation chain. Slightly more setup than Shopify's native module, but works reliably.

How do I handle WhatsApp template approvals for Indian brands?

For WhatsApp Business API in India, you need to use a registered BSP (Business Solution Provider) — MSG91, Gupshup, or Interakt are the most common for Indian D2C brands. All three have HTTP API endpoints that work cleanly with Make.com's HTTP module. Template approval through Meta takes 1-3 business days. Build your templates with placeholders before starting development so approval doesn't block your launch.

What happens to a running Make.com scenario if I hit my operation limit?

Make.com pauses further scenario executions until the next billing cycle or until you upgrade. Incomplete executions are stored and can be resumed. This is a real operational risk for high-volume brands — monitor your operation consumption, especially in peak seasons (Diwali, year-end sales). Set up email alerts in Make.com settings for when you reach 80% of your limit.

Can Make.com scenarios be exported and moved to another account?

Yes. Make.com scenarios export as JSON blueprints. You can import them into another account or team workspace. This is how we deliver automation builds to clients — we build in our development account, test, then export the blueprint for the client to import into their own Make.com account. Credentials (API keys, OAuth tokens) don't export and need to be reconnected in the destination account.

How is Make.com different from Zapier for D2C use cases?

Make.com's scenario builder is far more powerful than Zapier for complex, multi-step D2C workflows. The Router, Iterator, and Array Aggregator modules don't have direct Zapier equivalents for many use cases. Make.com is also significantly cheaper at equivalent operation volumes. The trade-off: Make.com has a steeper learning curve than Zapier. For simple 2-step "if this, then that" automations, Zapier's ease of use wins. For everything on this list, Make.com is the better tool.

We already use n8n. Should we migrate to Make.com for these recipes?

Probably not. If your team is already comfortable with n8n, the operational cost savings at scale make n8n the better long-term choice. The Make.com vs n8n decision is primarily about: (1) whether your team can manage n8n's self-hosted complexity, and (2) whether the visual UX of Make.com is important for non-technical team members. If neither is a blocker, stay with n8n.

Rishabh Sethia is the Founder & CEO of Innovatrix Infotech. Former Senior Software Engineer and Head of Engineering. DPIIT Recognised Startup. We build Make.com and n8n automations for D2C brands across India, Dubai, and Singapore via our AI automation service.

Originally published at Innovatrix Infotech

Shopify Hydrogen vs Liquid 2026: When Headless Actually Makes Sense

Rishabh Sethia — Mon, 03 Aug 2026 09:30:01 +0000

There's a conversation that happens more often than it should. A founder reads a Medium post about headless commerce, watches a Shopify Unite talk, and comes to us saying: "We want Hydrogen." They've heard it's faster, more modern, more scalable. Sometimes they're right. More often, they're about to spend 3x more money for a marginal performance gain they could have achieved by cleaning up their Liquid theme.

As a former Senior Software Engineer who has shipped production storefronts on both Liquid and Hydrogen, my take is direct: Liquid is the right choice for the vast majority of Shopify brands in 2026. Hydrogen is a powerful tool for a specific profile of merchant. Confusing which one you are is an expensive mistake.

This post breaks down both architectures — what they actually are, where each wins, and the exact inflection point where switching to headless stops being overkill and starts making engineering sense.

What Liquid Actually Is (And Why It's Underrated)

Liquid is Shopify's templating language. Your storefront lives on Shopify's servers, renders server-side on each request, and is delivered as HTML to the browser. Shopify handles hosting, CDN, SSL, uptime, and scaling automatically.

Developers who dismiss Liquid as "old" are thinking about it wrong. Shopify has invested heavily in Liquid performance: the Online Store 2.0 architecture introduced section-everywhere, app blocks replaced legacy script injection, and Shopify's CDN is globally distributed across Cloudflare edge nodes. When you write clean Liquid — no render-blocking apps, compressed images, minimal third-party scripts — you can hit 90+ mobile PageSpeed scores consistently.

We've done it. For FloraSoul India, we stripped out animation libraries, preloaded the LCP image, and implemented proper srcset on product photos — all within Liquid — and lifted their mobile conversion rate by +41% without touching the storefront architecture.

Liquid's other underrated advantage: the entire Shopify app ecosystem works. Every Shopify app — review platforms, upsell tools, loyalty programs, subscription billing — is built with Liquid theme extensions as the integration layer. This compatibility is worth more than most brands realise.

What Hydrogen Actually Is

Hydrogen is Shopify's React-based headless framework, built on top of Remix (now Shopify's recommended meta-framework). Your storefront runs as a JavaScript application — either on Shopify's own edge hosting platform called Oxygen, or on Vercel, Netlify, or your own infrastructure.

Hydrogen fetches product, collection, and cart data from the Storefront API (GraphQL). The checkout is still Shopify-hosted — that's an important constraint to understand. You own the discovery and browsing experience. Shopify owns checkout.

On Oxygen (Cloudflare Workers-based), Hydrogen storefronts can achieve very low TTFB globally — sub-100ms for cached responses is realistic. For high-traffic, globally distributed brands with complex rendering requirements, this is genuinely valuable.

But there's a catch most agency blogs won't tell you: Shopify's own performance data shows Liquid storefronts pass Core Web Vitals at higher rates than most headless implementations. The reason is simple — most teams underestimate how hard it is to optimise a React SPA for CWV. An optimised Liquid theme scores ~90 mobile. An optimised Hydrogen storefront scores 95-99. That 5-10 point delta is real, but it comes at 3-5x the build cost.

Head-to-Head: The Honest Comparison

Factor	Liquid	Hydrogen
Build time	3–8 weeks	12–20 weeks
Relative cost	Base	3–5x higher
App compatibility	~95%+ of Shopify apps	~20–40% natively
Hosting	Shopify-managed	Oxygen / Vercel / custom
Mobile CWV (optimised)	~90 score	~95–99 score
Developer ecosystem	Liquid + JS	React, Remix, full-stack
Maintenance overhead	Low	Medium–High
Shopify OS updates	Auto / semi-auto	Manual migration required
Ideal revenue range	₹0 – ₹10Cr+	₹10Cr+ (case-by-case)

When Liquid Is the Right Call

The majority of D2C brands should be on Liquid. Here's who that is:

You're under 100,000 monthly sessions
Your product catalog is under 500 SKUs
You rely on Shopify apps for reviews, subscriptions, bundles, or loyalty
You're launching in the next 3 months and need to move fast
Your team doesn't have dedicated React/Node engineers
Your revenue is under ₹10 crore annually

For Baby Forest India, we built and launched their complete Shopify store in under 3 weeks on Liquid. Launch-month revenue hit ₹4.2 lakh. Cart abandonment dropped 22% with WhatsApp and email automation layered on post-launch. We couldn't have done that on Hydrogen in the same timeframe.

As an official Shopify Partner, we have direct access to Shopify's theme architecture guidelines and partner resources. Our position: a well-executed premium Liquid theme with custom sections and clean code will outperform a poorly-executed Hydrogen build on every metric that matters — performance, conversion, and time-to-market.

When Hydrogen Actually Makes Sense

There is a real use case for Hydrogen. You've crossed the inflection point when:

1. Scale demands it: 100,000+ sessions/month, where Shopify's server-side rendering introduces perceptible latency and you need edge-rendered, personalised experiences at scale.

2. Catalog complexity demands it: 500+ SKUs with complex filtering, faceted search, or real-time inventory across multiple warehouses. Hydrogen lets you build custom search layers (Algolia, Typesense) without fighting Shopify's native limitations.

3. Multi-region, multi-language: You're operating in 3+ markets with different currencies, languages, and fulfilment logic. Hydrogen gives you architectural control that the Liquid theme layer doesn't.

4. Custom UI requirements that apps can't satisfy: You need a try-on tool, 3D product viewer, or interactive configurator that fundamentally conflicts with how Liquid renders. With Hydrogen, you own the rendering pipeline entirely.

5. Your engineering team is React-native: If your in-house developers live in React and TypeScript, Hydrogen gives them a familiar stack. Forcing React engineers to learn Liquid's constraints has its own cost.

Critical caveat: before committing to Hydrogen for performance reasons alone, let us audit your current Liquid store first. Our Shopify speed optimisation work has consistently shown that most performance problems are solvable in Liquid — without the architectural complexity of going headless.

The App Compatibility Problem Nobody Mentions

This is the one thing that bites Hydrogen adopters hardest in production. Most Shopify apps — Yotpo, Okendo, Rebuy, Recharge, and dozens of others — are built on the assumption that your storefront is Liquid. They inject snippets into your theme files, use Shopify's theme app extensions, and assume a certain DOM structure.

With Hydrogen, roughly 20-40% of Shopify apps work natively. The rest require:

Custom API integrations built from scratch
Headless-compatible SDK versions (if the vendor has them)
Complete rebuilds of functionality you currently get for free from apps

Before you choose Hydrogen, list every app you're currently running or plan to run. Check each vendor's headless compatibility. The sum of custom integration work required is often the difference between a Hydrogen build being viable and not.

The Development Cost Reality

A quality Liquid theme build from us runs 3–8 weeks with our Shopify development service. A Hydrogen build for the same storefront scope runs 12–20 weeks minimum. The cost differential is 3–5x.

That cost delta is rational if Hydrogen is genuinely solving a problem you have. It's irrational if you're doing it for brand positioning or because a competitor mentioned headless in their funding announcement.

Also consider ongoing cost: when Shopify releases platform updates — new checkout features, Shop Pay integrations, new product metafield types — Liquid stores get these with minimal effort. Hydrogen stores require engineering work to adopt each update. The maintenance overhead compounds over time.

For complex projects at this scale, our web development team works alongside Shopify engineers to architect the right solution from the start — whether that's Liquid, Hydrogen, or a hybrid approach.

Our Verdict

Hydrogen is not the future for every brand. It's the right architecture for a specific tier of merchant: high-traffic, catalog-complex, engineering-resourced, operating at scale.

For 90% of D2C brands — especially those under ₹10Cr in annual revenue — Liquid is faster to market, cheaper to build, easier to maintain, and fully compatible with the apps your business depends on.

When you're generating ₹50Cr+ annually and your performance data shows measurable conversion loss from storefront speed, that's when the Hydrogen conversation becomes a serious business decision rather than a technical preference.

We're equally capable of building both. As a Shopify Partner, we'll tell you which one you actually need — not which one has a better pitch deck.

Frequently Asked Questions

Is Shopify Hydrogen faster than Liquid?
An optimised Hydrogen storefront can score 5–10 points higher on Google PageSpeed than an optimised Liquid store. But an unoptimised Hydrogen build can perform worse than clean Liquid — the architecture doesn't guarantee performance, execution does.

Can I migrate from Liquid to Hydrogen later?
Yes, but it's a full rebuild — not a migration. There's no automated path from Liquid to Hydrogen. If you build on Liquid now and later want Hydrogen, budget for a complete storefront rebuild at that stage.

Do all Shopify apps work with Hydrogen?
No. Only around 20–40% of Shopify apps natively support headless/Hydrogen. Many of the most popular apps — subscriptions, reviews, loyalty — require custom API integration work or headless-compatible SDK versions.

What is Shopify Oxygen?
Oxygen is Shopify's edge hosting platform for Hydrogen storefronts. It runs on Cloudflare Workers infrastructure, providing globally distributed compute close to the user. Oxygen is included with Shopify plans at no additional hosting cost.

How much does a Hydrogen build cost vs Liquid?
A Liquid build typically runs 3–8 weeks. A comparable Hydrogen build runs 12–20 weeks. The cost differential is approximately 3–5x. Total investment depends on catalog size, feature complexity, and app integrations required.

Is headless commerce right for my Shopify store?
Ask yourself: Are you doing 100K+ monthly sessions? Do you have 500+ SKUs requiring complex filtering? Are you operating in multiple countries with different languages and currencies? Do you have in-house React engineers? If you answered no to most of these, start with Liquid.

Can I use Hydrogen with a regular Shopify plan?
You need at least a Shopify Advanced plan or Shopify Plus to get the most out of Oxygen hosting. Basic and Standard plans technically support Shopify's Storefront API, but without Oxygen, you'd need to host your Hydrogen storefront externally on Vercel or similar.

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

No-Code vs Custom Development: Which One Should You Choose in 2026?

Rishabh Sethia — Mon, 03 Aug 2026 04:30:01 +0000

The no-code vs custom development debate is getting louder as tools like Webflow, Bubble, and Framer gain traction. Here's when each makes sense — and when the choice is obvious.

What No-Code Actually Means in 2026

No-code platforms have evolved dramatically. You're no longer choosing between "drag-and-drop toy" and "proper development." The spectrum now looks like:

Website builders (Webflow, Framer, Wix): UI-only, no custom logic
App builders (Bubble, Glide, AppGyver): Full apps with database and logic
Automation platforms (Make, n8n, Zapier): Workflow automation
Backend platforms (Xano, Supabase with no-code UI): Database + API

The right comparison isn't "no-code vs custom code" — it's "which tool (no-code or custom) is right for this specific requirement?"

No-Code Wins When

Speed matters more than flexibility. A Webflow site can be live in 2 weeks. A custom Next.js build takes 6-10 weeks. If you're validating a concept or launching before a funding round, time-to-market can outweigh technical debt.

Your product fits the platform's model. Bubble is excellent for marketplaces, internal tools, and MVPs with standard CRUD patterns. If your product maps to what Bubble does well, you might never need custom code.

Your team is non-technical. No-code tools empower non-technical founders to build, iterate, and manage their own product. Removing developer dependency can dramatically accelerate iteration speed.

Budget is constrained. A Bubble MVP costs ₹3-8 lakh to build vs ₹15-30 lakh for a custom equivalent. The no-code version can be thrown away once you've validated and raised — but it got you there.

Custom Development Wins When

Performance is a core product requirement. No-code platforms add abstraction layers that impact performance. For products where sub-100ms response times matter (trading platforms, real-time logistics), custom is the only option.

Security requirements are strict. Healthcare, fintech, and government applications need audit trails, specific encryption standards, and compliance features that no-code platforms simply can't provide.

Your logic is genuinely unique. No-code platforms are built for standard patterns. Complex pricing algorithms, custom machine learning integration, or deeply specialized workflows eventually hit walls.

You need full data ownership. No-code data is in the platform's database. If your data sovereignty requirements or investor terms require you to own all infrastructure, custom development is necessary.

You're building for scale. Bubble has limits at high traffic. Webflow can't handle complex server-side rendering requirements. When you're planning for millions of users, architect for that from the start.

The Hybrid Approach (What Most Teams Should Do)

Most successful products use both:

Marketing site: Webflow or Framer (non-technical team can manage content)
MVP/product: Bubble or custom depending on complexity
Internal tools: Retool, Appsmith, or custom depending on data sensitivity
Automations: Make/n8n (no reason to custom-code routine integrations)
Core product logic: Custom code where unique or performance-critical

Common Mistakes

Building custom too early. Most founders should be on Bubble longer than they are. The flexibility anxiety isn't worth the cost if you haven't validated PMF.

Staying on no-code too long. Migrating from Bubble to custom at Series A is painful. Have a clear threshold: "When we hit X users or need Y feature, we'll migrate."

Thinking no-code means no developer. Complex Bubble apps need good Bubble developers. Webflow needs a Webflow developer for anything beyond templates. "No-code" just means no custom programming language, not no technical expertise.

Need expert help? Innovatrix Infotech builds custom web development solutions for businesses across India — from MVPs to production systems. Get a free consultation.

Originally published at Innovatrix Infotech

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