Why Indian businesses need their own automation stack

If you've ever run ops for an Indian business, you've probably lived this exact moment. You sign up for some shiny automation tool. You start building the workflow that's finally going to save your team ten hours a week. And then you hit the wall. The payment gateway you actually use isn't in the list. The messaging channel your customers actually read isn't there either. The courier that actually delivers your orders wants a custom integration that costs more than the tool itself.

I used to think this was just bad luck on my part. It isn't. It's structural. Most of the big automation platforms were built for a market that looks nothing like ours, and that shows up in a hundred tiny frictions that add up to a real tax on every ops team in India.

The defaults were never built for us

Every product quietly encodes assumptions about who's using it. For most global automation tools, those assumptions were set years ago by a team in North America solving North American problems. You can feel it the moment you start building:

• Payments means Stripe and PayPal. Not Razorpay, not Cashfree, not PayU, and definitely not UPI as a first-class thing.
• Messaging means email and maybe SMS. Not WhatsApp, which is where almost all of our customer conversations actually happen.
• Commerce means Shopify and WooCommerce. They exist here too, sure, but so do Dukaan, the marketplaces, and a long tail of homegrown stores.
• Logistics means FedEx and UPS. Not Shiprocket, not Delhivery, not the aggregator layer that every D2C brand here lives inside.

On its own, each gap looks like one missing integration. Put them together and you're looking at a tool that simply wasn't built for the way we work. You can force it to do the job, but you're always swimming against the current, and you can feel it.

The real cost hides in the workarounds

Here's the thing. When a tool doesn't natively support what you need, you don't just give up. You improvise. And the improvising is exactly where the cost hides, because every workaround is a little piece of fragile plumbing that somebody now owns forever.

Take a goal that sounds trivial: when a customer pays, send them a WhatsApp confirmation and create a record in your CRM. On a platform that natively speaks these tools that's three nodes and about five minutes. On one that doesn't, it turns into a small project:

1. 01Stand up a relay server just to receive the payment webhook, because the tool can't talk to your gateway directly.
2. 02Write code to verify the webhook signature, so you're not acting on a spoofed event.
3. 03Route the WhatsApp message through some third-party provider that has its own template approvals, rate limits, and ways of failing.
4. 04Manually fix the CRM record when one of those three hops silently breaks, which it eventually will.

Every workaround is a thing that breaks at 2am. And trust me, it never breaks on the day you actually have time to fix it.

The workflow you wanted was the automation. What you ended up with is a small distributed system to babysit. That babysitting is invisible to everyone above you, it's nobody's favourite job, and it's the first thing that falls over the week the person who built it goes on leave.

Why "just use Zapier" stops working

Don't get me wrong, generic tools can take you surprisingly far on generic problems. The trouble is that the problems that matter most to an Indian business are almost never generic. They sit right where the global defaults are weakest: reconciling UPI payments, dealing with WhatsApp's template and session rules, syncing to a CRM like Zoho or LeadSquared, pushing orders into Shiprocket.

And then there's the pricing, which nobody warns you about. A lot of these tools bill per task, where every single step in a workflow counts as its own billable unit. A five-step automation that runs ten thousand times a month isn't ten thousand units in your head. On a per-task meter it's fifty thousand. So the pricing model ends up punishing the exact kind of multi-step workflow you most need to build. It's almost backwards.

What a native stack actually changes

A platform built around these tools just starts from a different place. The systems you use every day aren't add-ons bolted on through middleware. They're first-class, connected in a couple of clicks, with credentials encrypted at rest and triggers that fire in real time.

That sounds like a small thing. In practice it changes the whole economics of automation inside a company:

• The workflow you picture is the workflow you build. No relay servers, no glue code, no extra hops.
• Reliability stops being your problem to engineer. Retries, token refresh, signature checks, all handled by the platform instead of by you at midnight.
• The cost of trying an idea drops to basically zero, so people actually experiment instead of rationing automation for only the biggest wins.
• Knowledge stops walking out the door, because the automation lives in a system anyone can open and read, not in one engineer's head.

The opportunity sitting in front of us

India has more small and medium businesses going digital, faster, than almost anywhere on earth. UPI, WhatsApp commerce, D2C stores, modern CRMs, all of it is being adopted at a pace the last generation of software never planned for. The tooling has lagged behind what's actually happening on the ground.

And that lag is genuinely the opportunity here. When a team automates on a stack that fits how they actually work, the savings start to compound. The first workflow frees up enough time to build the second one, and so on. A year in, you've got a business that's doing a lot more without having hired a lot more people, and the competitor down the road who's still doing all of it manually just can't keep up. I've watched this happen and it doesn't feel dramatic in the moment, but the gap gets big fast.

This is basically why we built Adoment around these tools from the start instead of bolting them on later. Razorpay, WhatsApp, Zoho, Shiprocket, all the stuff you already run on, they're treated as the normal case, because for the businesses we're building for, they are. The idea is that the boring plumbing disappears and you're left with the work you actually wanted to do.