A multi-role, WhatsApp-first web application that handles tasks, invoices, document storage, and client tickets for a chartered accountancy practice — and what it took to get there.
CA firms run on client trust, deadline precision, and document reliability. They also tend to run on WhatsApp threads, shared folders, and spreadsheets that nobody quite owns. When CA Nikhil Maddi & Associates asked us to build a practice management system — one that their staff and clients would actually use daily — we had a clear brief and a non-trivial set of constraints.
The firm handles compliance filings, GST returns, income tax, audits, and advisory work across a significant client base. Before SMART CA, the workflow was: tasks assigned by phone or WhatsApp, status updated informally, invoices raised in a third-party billing tool, documents shared via email or Google Drive, and client queries fielded directly by staff over call.
The ask was: replace the manual parts without replacing the human relationships that make them work. That meant building something that felt faster and clearer to use — not more formal or bureaucratic.
The application has three distinct user types, and the challenge is that their needs are quite different.
**Admin** is the principal CA or practice manager. They need to see everything: client portfolio, all outstanding and completed tasks, payment status, team workload, and the ability to create recurring task masters — templates that spawn individual task instances on monthly, quarterly, or annual cadences. Recurring tasks are the backbone of compliance work. Setting one up once and having the system create and assign it reliably is the difference between something a CA will trust and something they will work around.
**Employees** — the junior CAs and support staff — need a focused view. When you open the app as an employee, you see your tasks bucketed by urgency: what is overdue, what is due today, what is coming up. The task drawer shows everything you need to action a task: the client, the deadline, attached documents, and a comment thread. The idea is that you spend your day inside one screen, not jumping between a task list and a document folder and a client directory.
**Clients** get read-only access to their own file. They can see their documents (the firm uploads on their behalf), raise support tickets, and receive push notifications when something needs their attention. The client-facing experience was deliberately constrained — it is not a portal that clients manage themselves; it is a transparent window into the work being done on their behalf.
One decision we made early was to drop password-based authentication entirely. CA clients range from large businesses to individual filers, and password management is a friction point that generates support overhead without adding security in practice.
WhatsApp OTP login solves this cleanly in an Indian context where WhatsApp penetration is near-universal. The user enters their registered mobile number, receives a one-time code via WhatsApp, and is in. No forgotten passwords, no reset flows. The backend handles OTP generation and verification via the WhatsApp Business API; sessions are JWT-based and tied to device + number.
It also meant the admin could onboard a new client without the client setting up a password — they just receive their first notification on WhatsApp.
The single feature that took the most iteration was the task master system. A task master is a template: it defines what the task is, which client it belongs to, what documents are expected, who it is assigned to, and how often it recurs. At the configured cadence — monthly, quarterly, annually — the system spawns a new task instance pre-populated with that data and drops it into the assignee's queue.
The subtlety is in overrides. Not every instance of a recurring task is identical. A GST filing for a client might always go to the same employee, but a particular month might need a different deadline or a note. So each spawned instance is editable without touching the master. And if the master changes — say the client switches to quarterly — existing instances are unaffected.
Getting this right took several rounds of feedback from the firm's principal. The first version was too rigid; the second gave too much freedom and confused the expected defaults. The third version, which landed, uses sane defaults from the master and exposes overrides without making them prominent.
The invoicing module needed to produce invoices that could be shared with clients and were compliant with GST record-keeping requirements. That means: correct invoice numbering, GSTIN display, HSN/SAC codes, tax breakdown (CGST + SGST or IGST based on state), and a clean PDF output.
We built the invoice PDF generation server-side so the output is identical regardless of device or browser — no rendering variation from client to client. Payment status (pending, partial, paid) is tracked per invoice, and the admin view shows outstanding balances by client with the ability to record offline payments (bank transfer, cheque) against an invoice.
Each client has a dedicated document drive within the system. The firm uploads files — ITR acknowledgements, GST returns, incorporation documents — and they are stored associated with that client's record. The client sees a read-only view of their own drive when they log in.
The 50 MB file cap per upload was a practical constraint tied to the hosting setup, but it is sufficient for the document types involved. The naming convention and folder organisation are controlled by the firm, not the client, which keeps the drive navigable even across a large client base.
The permissions layer was essential from the start. Not every employee should see payment information; not every employee should see all clients. The admin can configure role-level defaults and then override per employee: can view clients, can view payments, can manage tasks, can access the knowledge base.
This came directly from how the firm actually operates — different staff members have different levels of access to client information for confidentiality reasons. A system that treated all employees identically would not have been adoptable.
The calendar view was added late in development, and it shows. It works, but the interaction model — switching between a task list and a calendar view — adds more cognitive overhead than it should. A merged view where the task list respects a selected date range would have been better. We know this and have flagged it as a future iteration.
The knowledge base (org fields) feature — which lets the firm store custom compliance data per client, like registration numbers, filing history, and key dates — is powerful but underused in early months. The data entry overhead was higher than expected. A future version might seed fields from document uploads using structured extraction.
The WhatsApp OTP login had zero support overhead after launch. Not a single "I forgot my password" ticket. That alone justified the decision.
The recurring task master system is now running live compliance cycles for the firm's full client base. The principal told us it removed a weekly manual process of creating and assigning tasks — something that used to take the better part of a morning.
The permissions system was never a source of confusion or errors in early use, which is usually a sign that the model matched the mental model of the people using it.
Building domain-specific software for professional services firms is demanding work — the margin for ambiguity is low, the data is sensitive, and the users have strong opinions about what correct looks like. We would do it again.
Drop us a message or call us directly. We reply to every enquiry — usually the same day.