Aparsoft LegalOS
One system that runsan Indian law firm.
How Aparsoft built LegalOS: the firm's website, enquiries, bookings, engagement letters, matters, documents and client portal in one product, with the Bar Council's rules built into the data rather than pasted on as a disclaimer.
Watch it work
Website, enquiries, bookings, engagement letters, matters, a private vault, a client portal and an assistant that names its source, in one system.
The challenge
Law firms run on WhatsApp, attachments and a stale website
A website nobody updates
Every change means emailing a developer and waiting a week.
Enquiries in five places
Phone, WhatsApp, a form, a referral, a walk-in. Nobody can count them.
Documents on personal phones
Aadhaar scans on an associate's number, and no record of who opened them.
Compliance by doing less
Firms under-market out of fear of Rule 36, which is its own cost.
The idea
The needs are shared. The identity is not.
How it is built
Seven decisions that make it work
Real screens from a demo firm with sample data.
A gate that actually gates
A firm may not solicit, so the website shows nothing until the visitor agrees.
- The server sends the notice, not the page
- There is nothing behind it to uncover
- The exact version agreed to is recorded
Compliance built into the data
What must never appear has nowhere to be typed.
- No field for a win rate or cases won
- No price on a service; fees live only in an engagement letter
- DPDP consent stored with its exact wording, per record
An assistant that names its source
It answers from the firm's own library, and never guesses.
- No source, no answer
- Won't guess an outcome, a fee, a time limit or “should I sue”
- Public and internal material kept apart at the source
A vault built for privilege
Documents belong to a matter, never to a global list.
- Confidentiality enforced in two independent places
- Private storage, served through links that expire in five minutes
- Every view and download logged
Acceptance recorded, not signed
Scope and fee written down before work begins.
- Generated from the firm's own templates
- The client accepts online, and the time is recorded
- The exact text they accepted is kept
One database per firm
Not a shared table with a filter on it.
- One firm's app cannot even connect to another's database
- No forgotten filter can leak privileged files
- Shown live on a screen share in thirty seconds
Firm A
own database · own credentials
Firm B
own database · own credentials
Refused by PostgreSQL before any query exists. No missing filter can leak one firm's files to another.
A new firm is configured, not coded
Colours, modules, menus and pages are settings.
- Nine palettes to start from, in light and dark
- Switch a module off and its pages go with it
- The build fails if a client's name appears in the code
How we engineered it
Six ideas behind a firm that is configured, not coded
The engineering choices underneath the seven decisions, and why a cautious partner can say yes to them.
Build the needs once
Most of what a law firm needs is the same from firm to firm; what differs is identity. So the needs are one product, and identity is settings the firm edits itself. A new firm needs no new code.
Rules in the data, not in the copy
The Bar Council's rules and the DPDP Act are enforced where data is stored. A field that must never be filled does not exist, and consent is kept with the exact words that were agreed to.
Isolation below the application
Each firm's data is kept apart by the database itself, not by code that remembers to filter. A mistake in the application still cannot reach another firm's files.
Sources first, and some answers never
The assistant answers only from material it can cite, and shows the source. Some questions, such as an outcome or a fee, are routed to a person by design, not by luck.
Every sensitive step leaves a record
Who viewed or downloaded a document, which disclaimer a visitor accepted, what text a client agreed to and when. The firm can show what happened, not only say it.
Shown, not claimed
The disclaimer gate, the isolation between firms and a full backup-and-restore were each tested on a running system. The build also fails if a client's name appears in the code.
What the build proves
The first firm was a build. The next is configuration.
- Compliance-aware from the first design decision, not retrofitted
- A new firm is configured, not coded
- Isolation and a full backup-and-restore drill shown on a live environment
- Ready for other regulated professions: CAs, company secretaries, tax practices
More screens
Every screen, from the demo firm
Every enquiry from the website lands in one queue — new, contacted, qualified, converted — and spam is marked, not lost. Seeded demo data, not an actual client.
How it's built
The stack, and how we use it
Proven open-source tools, used the way they are meant to be used.
Django 6 + DRF
Around 90 data models behind one documented API; CI fails if its OpenAPI schema has a warning.
Next.js 16 · React 19
The firm's public website and the staff console from one app, its pages settings rather than code.
PostgreSQL + pgvector
One database per firm, with the firm's library searched by meaning inside it.
LangGraph + LangChain
A citation-only assistant: no source found, no answer; public and internal material kept apart.
Django Channels
The assistant streams its answer, with its sources, live over WebSockets.
Celery + Redis
Emails, appointment reminders, data retention and the assistant's library run in background queues.
Private object storage
No public route to any file; each view is a signed link that expires in five minutes.
GitHub Actions CI
Every change linted, tested and built; the build fails on a client's name in the code.
