How We Built CAPilot — Engineering a Practice Management OS for CA Firms

The Problem

An Indian CA firm running 200+ clients typically operates across five disconnected tools: Tally for accounting, Excel for client tracking, WhatsApp for compliance reminders, Google Drive for documents, and a homemade Word template for invoices. Information lives in five places, gets out of sync within hours, and partners spend their first hour every day reconciling what their team did yesterday.

The existing software market mostly offers two extremes: Tally-class accounting software that doesn't manage compliance workflows, or generic project-management tools that don't speak the language of GST, ITR, audits, and statutory deadlines. There was no purpose-built operating system for how CA firms actually work.

So we built one.

"The goal wasn't to build another piece of software. It was to replace five tools with one — and have the firm forget which tool they used to use."

What We Set Out to Solve

• One source of truth. Client, task, document, invoice, payment — all in one model, all queryable, all auditable.
• Compliance-aware tasks. Tasks understand GST due dates, ITR seasons, audit cycles. Deadlines aren't strings — they're first-class data.
• Multi-tenancy from day one. Every CA firm is a fully isolated tenant. No data-mixing, no cross-firm leakage, regulatory-grade separation.
• Tally-aware, not Tally-replacement. CAPilot integrates with Tally — it doesn't try to replace the GL. CA firms keep using Tally for ledgers and statutory reporting; CAPilot handles everything Tally was never designed for.
• Production-grade from day one. Daily backups, SSL, RBAC, audit logs, DPDP & IT-Act compliant by default — not features we'd "add later."

The Architecture

CAPilot is a multi-tenant SaaS platform deployed on Azure. The high-level shape:

• Frontend: React SPA hosted on Azure Static Web Apps. SPA routing via hash routes to keep CDN-served static assets simple. State managed locally per page; no global Redux store — most data is fetched fresh per route to keep behavior predictable.
• Backend: .NET 8 Web API hosted on Azure App Service. Domain-driven service layer separating tenancy, identity, billing, compliance, and document contexts. Each context owns its own tables and service interfaces; cross-context calls go through explicit application services, not direct table access.
• Database: SQL Server on Azure SQL. Single shared database, tenant ID on every row, row-level filtering enforced in the data access layer (not just at the API). This keeps operational cost low for early tenants while preserving the path to per-tenant DBs as customers grow.
• Auth: JWT-based session model with role-based access control. Roles are scoped per tenant — a "Partner" at Firm A is a stranger at Firm B.
• Storage: Azure Blob Storage for client documents, with per-tenant container prefixes and SAS-token-gated download URLs. Documents never leave the tenant boundary.
• CI/CD: GitHub Actions for build, test, and deploy. Two environments: staging (auto-deploy on merge to main) and production (manual promotion from staging). Zero hand-edits in production.
• Observability: Azure Application Insights for traces and exceptions. Daily uptime checks, error-rate alerts to the founder's phone.

The Decisions That Mattered

1. Single shared database vs. per-tenant database

Starting with a per-tenant database would have been "cleaner" — better isolation, easier compliance answers, simpler backup-per-customer story. But it would also mean operational overhead per signup (new DB, new connection string, new backup pipeline) before we even knew if customers wanted to pay.

We chose a single shared SQL DB with strict tenant-scoping. Every query passes through a tenant guard. Every CRUD path enforces it. The cost: discipline. The benefit: we onboard a new firm in seconds, not minutes — and there's a clear migration path to per-tenant DBs for Enterprise plans when the contract demands it.

2. React SPA over server-rendered framework

Server-rendered (Next.js, Razor Pages) would give us better SEO and initial-load performance. But CAPilot is a logged-in workflow tool — Google doesn't need to crawl the dashboard. SPA gives us a snappier post-login experience, simpler hosting (Azure Static Web Apps + a separate API), and easier offline-first capability later. We'd make the same call again.

3. .NET 8 over Node.js

The .NET ecosystem on Azure is unbeatable for production reliability — typed end-to-end, tooling that catches mistakes before they ship, mature ORM, deep Azure integration, and excellent perf characteristics out of the box. Most of the team's deepest experience is in this stack. The alternative — Node — would have moved us faster on weekends but slowed us down where it mattered: under load, in audits, and in regression-test confidence.

4. Inline styles in invoices, not PDF templates

GST invoices need to render exactly the same on screen, in print, and as a PDF for email. We initially tried a templating library; we shipped HTML+CSS rendering through a headless browser. Result: WYSIWYG between the on-screen invoice and the PDF, full control over Indian-rupee formatting, HSN/SAC layouts, and signatures.

The Numbers, So Far

These are early-traction numbers — we're transparent about that. The platform is in production, paying customers are using it daily, and the architecture has held up under real-world load. Our growth bottleneck right now is not engineering — it's customer acquisition, which is exactly the position we wanted to be in.

What We'd Do Differently

• Test infra earlier. We have integration tests now, but for the first six weeks we relied too heavily on manual smoke tests. The cost of a regression caught two days late was always higher than writing the test would have been.
• Background-job framework from day one. Recurring billing, deadline reminders, batch document processing — we initially handled these via in-process timers, then moved to Hangfire. Should have started with Hangfire.
• Feature flags. Rolling out a new module to one tenant first — instead of all of them — would have made early UX iterations far less risky.

What's Next

Roadmap items we're working on or about to start:

• WhatsApp business integration for compliance reminders directly to clients, not just to the firm's team.
• Government portal automation — auto-fetch ITR statuses, GST return filings, and TDS challans into the firm's dashboard.
• AI-assisted document classification — upload a stack of client docs, get them auto-tagged and routed to the right client folder.
• White-labelled client portal — large firms can give their clients a branded login to view tasks, documents, and invoices.
• International billing for global rollout — USD/EUR pricing, Stripe integration, multi-currency invoicing.

If You're Building Something Similar

Three things we'd tell anyone building a vertical SaaS for an Indian (or any developing-market) industry:

1. Don't try to replace the legacy tool — integrate with it. Tally has been running CA firms for 30 years. Telling firms to abandon it is both wrong and unwinnable. Sit alongside the legacy tool, do what it can't, and let migration happen organically when the customer chooses.
2. Build for the partner, not the partner's IT person. Most decision-makers at small firms are practitioners, not technologists. Default settings have to be sensible. Onboarding has to be 60-second. The product has to assume zero IT support.
3. Compliance is a feature, not a checkbox. "GST aware" doesn't mean "has a GST field." It means the system understands invoice cycles, return-filing seasons, late-fee penalties, and reverse-charge mechanism — and surfaces the right action at the right time.

Want to see CAPilot in action? Read the full feature breakdown and pricing, or try the live app with a free trial. If you're a CA firm partner — talk to us about a guided onboarding session.