Building an Integration Platform in India: Lessons from the Trenches

So we invested heavily in Tally integration. Real integration, not an afterthought. Our Tally connector is one of our best connectors because we built it as if Tally was our primary system (which, for Indian businesses, it is).

Lesson Learned: If you’re building for India, Tally isn’t optional. Build it right.

Lesson 2: “Cloud First” Doesn’t Work in India (Yet)**

Many global SaaS companies are “cloud first.” Your data lives in the cloud. You access it through a browser. Offline mode, if it exists, is a secondary feature.

In India, this is a mistake.

The reasons are practical:

• Internet connectivity is variable. A team might have fast internet in Delhi but slow connectivity in a branch office in Jharkhand.
• Some critical business processes can’t wait for cloud sync. If the cloud is down, your team can’t close invoices.
• Data sovereignty concerns are real. Some businesses don’t want all their financial data in a cloud provider’s system.
• VPN and network complexity means cloud systems sometimes can’t reach Tally or other legacy systems reliably.

We initially built AxonBOS as a cloud platform. We hit a wall when customers asked: “What happens when my internet is down? I need to continue working.”

We redesigned to be “offline-first.” The primary application runs locally on your desktop (built with Tauri). Data syncs to the cloud when connectivity is available, but your team doesn’t need the cloud to work.

This single design decision changed everything. Adoption rates increased. Customer satisfaction increased. Support tickets about connectivity decreased dramatically.

Lesson Learned:** For India, build offline-first. Sync to cloud when possible. Local-first is a feature, not a fallback.

Lesson 3: GST Rules Change Faster Than You Can Update Software**

GST compliance in India is a moving target.

The GST rate on a product might change. Reverse charge rules might shift. The definition of a B2B transaction might be updated. Compliance requirements might get stricter.

By the time you’ve built compliance logic and shipped it, the rules have changed again.

We learned this when GST rate changes happened in Q2 and our customers needed them in 48 hours, not in the next release cycle. Or when the government changed the definition of “supply” and our classification rules became wrong.

Our response: Build GST logic to be configurable, not hard-coded.

Rules are stored in a database that can be updated independently of software releases. When GST rates change, we update the database. Customers update their local version and they’re compliant again. No software update required.

This approach requires more engineering upfront. But it’s essential for India where regulatory changes are frequent and urgent.

Lesson Learned: Don’t hard-code compliance rules. Make them configurable and updateable independently of software releases.

Lesson 4: “Simple” Integrations Are Deceptively Complex**

We assumed our first connector (Tally to Zoho) would take 2 months to build properly.

It took 5 months.

Why? Because “simple” customer-to-party mapping turned out to have 47 edge cases:

• What happens if a customer exists in both systems with the same name but different GSTIN?
• What if payment terms differ between the systems?
• What if a customer has multiple billing addresses in Zoho but Tally only supports one?
• What if the GL account for a customer category changes in Tally—should all existing customers be re-mapped?
• What if a customer is deleted in Zoho—should the Tally party be deleted or inactivated?
• What about custom fields that exist in one system but not the other?
• What’s the performance impact of syncing 10,000 customers?
• What happens if the sync fails halfway through?

Each edge case required thought. Some required customer configuration options. Some required hardcoded business logic.

We now budget 4-6 months for a “simple” connector. If it takes 2 months, we’re delighted. The reality is that integration is complex, and pretending otherwise leads to brittle connectors that fail in production.

Lesson Learned: Real integrations are complicated. Build with time for edge cases, testing, and customer feedback.

Lesson 5: Document Extraction Accuracy Matters More Than You’d Think**

When we started on AI-powered document extraction, we focused on accuracy: What’s the error rate?

But the more important question turned out to be: What are the types of errors?

A system that’s 98% accurate might extract customer name perfectly, but consistently gets GST amount wrong. For invoicing, that’s a critical error. A system that’s 95% accurate but always catches GST errors might be more valuable than a 98% accurate system that sometimes misses them.

We implemented confidence scoring so users could see where the AI is uncertain. An invoice amount extracted with 99% confidence is trustworthy. An HSN code extracted with 60% confidence should be reviewed.

This human-in-the-loop approach (AI handles 80%, humans review 20%) turned out to be better than either full automation (too many errors) or full manual processing (too slow).

We settled on an 85% confidence threshold for auto-approve, which means roughly 20% of invoices get flagged for human review. Users report this ratio feels right: enough automation to save time, enough review to ensure quality.

Lesson Learned: Document extraction is a human-in-the-loop problem, not a pure automation problem.

Lesson 6: Your Customer’s Customer Matters**

When we pitched AxonBOS to SMBs, we focused on “automate your invoice entry” and “simplify GST compliance.”

Useful, but not compelling enough.

What mattered more: how this enabled their CA firm to serve more clients. Or how it let them provide better data to their lenders. Or how it reduced the time they needed from their accountant.

For CA firms, the case was even clearer: managing 50 clients manually is one workflow. Managing 100 clients with integration automation is a completely different business model. It’s not a 2x feature; it’s a business transformation.

We learned to sell the second-order benefit, not the first-order feature. “Automate invoice entry” is fine. “Enable your CA to serve 2x more clients” is compelling.

Lesson Learned: Understand your customer’s customer. The end-user benefit drives adoption more than the technical feature.

Lesson 7: Implementation Time is Shorter Than Expected When You Plan Right**

We were worried implementation would take months. It doesn’t, if you approach it right.

The pattern we’ve seen:

• Week 1: Connect systems and verify data flow (usually 2-3 days)
• Week 2: Configure mappings and test with historical data (usually 2-3 days)
• Week 3-4: Live with monitoring and handle edge cases (usually 1 week)
• Week 5 onwards: Autopilot

Total implementation: 3-4 weeks for a complex setup with multiple systems.

Why is it fast? Because we’ve solved the hard problems (schema mapping, error handling, compliance logic) in the platform. Implementation isn’t “figure out how to build this”—it’s “configure what we’ve already built for your specific systems.”

Lesson Learned: Good platform design makes implementation fast. A platform that requires custom coding for every customer isn’t a platform; it’s a services business.

Lesson 8: CAs Are Different From SMBs (And Build Accordingly)**

We initially thought AxonBOS would appeal equally to SMBs and CA firms.

We were wrong. They’re different customers with different needs.

SMBs want:**

• Fewer manual tasks for their internal team
• Better accuracy and compliance
• Time to focus on business growth

CAs want:

• To manage more clients without hiring
• A unified view across 50+ different client systems
• Compliance work to be automatic
• To shift from tactical to strategic work

These require different product features:

• For SMBs: Good single-system integration, document extraction, error alerts
• For CAs: Multi-client dashboard, centralized compliance checking, client segmentation and filtering

We’ve learned to build features for both, but market them differently.

Lesson Learned: Your customer segments need different products, even if the core platform is the same. Build with both in mind.

Lesson 9: Regional Matters More Than You’d Expect**

We say we support “5 regions” (India is the first). But even within India, regional differences matter.

GST rules are federal, but implementation varies by state. Bank reconciliation works differently in different states. Compliance timelines might differ. Even vendor naming conventions and invoice formats vary by region.

A platform that’s “India-first” but actually “Delhi-first” will fail in Tamil Nadu or Gujarat.

We’ve learned to build regional awareness into the platform. Configurable rules per state. Support for regional languages in documents. Awareness of local compliance requirements.

Lesson Learned: “India-first” doesn’t mean Delhi-first. Regional awareness is essential.

Lesson 10: Founder Involvement in Difficult Problems Matters**

When we hit a particularly thorny technical problem—bidirectional sync for schema-unaware systems, or confidence scoring for document extraction—the instinct was to assign it to a junior engineer.

We learned that was a mistake. Founder involvement in hard problems led to better solutions. Because founders understand the customer problem, not just the technical problem.

Some of our best product insights came from Rajkumar spending 3 hours on a call with a CA firm trying to understand what “unified compliance dashboard” actually meant to them operationally.

Lesson Learned: Founders should solve hard problems, not just oversee them.

The Bigger Picture: Building for India is Different**

Building a technology platform in India isn’t the same as building in the US and adapting for India. The software landscape is different. The regulatory environment is different. The business practices are different.

When we made the commitment to “India-first,” it changed everything:

• We hired for Tally expertise, not accounting software expertise (Tally is Indian)
• We built offline-first, not cloud-first
• We made GST rules configurable, understanding they’d change
• We designed for CA firms managing multiple clients, not just enterprise IT teams
• We built support for regional complexity, not just national compliance

These decisions meant slower initial progress but better product-market fit.

What’s Next**

We’re still in the early days. We have Tally and Zoho connectors live. FormEzy and Safal DataNote connectors are active. We’re building toward the full 222 connectors we’ve promised. We’re expanding to serve companies beyond India.

But the founding principles stay the same: Build for the customer’s real problem. Make compliance automatic. Make offline work. Understand the schema, don’t just copy data.

If you’re building for India, the market reward is massive. The businesses here are competing with global companies, and they need tools as good as anything available globally. Better, because they understand India’s specific complexity.

That’s what we’re building toward.

If you’re managing integration chaos across your systems, or if you’re a CA firm feeling like you’ve hit a ceiling on clients you can manage, AxonBOS was built for exactly your problem. We’ve learned what works in Indian business. We’ve built it into a platform that scales without custom engineering.

Let’s talk about what your integration could look like when it actually works.