Section 01
Overview & Scope
Clerkify is a greenfield rebuild of MyMunshi: a case-tracking service for Indian advocates. This section defines what the product is, what carries over from the old system, and what explicitly does not.
What the product does
An advocate registers the cases they are handling. Clerkify then watches those cases across Indian court and tribunal websites — Supreme Court, High Courts, district eCourts, DRT/DRAT, NCLT/NCLAT, state RERA boards, consumer forums, and assorted tribunals — and tells the advocate when something changes: a new hearing date, a listing on tomorrow's cause list, a fresh order or judgment.
The value proposition is not missing a hearing. For an advocate, a missed listing is not an inconvenience; it can be an adverse order passed in their absence. That framing drives nearly every engineering decision in these documents — most of all, that a silently broken connector is the worst failure mode in the system.
The next hearing date is the single highest-priority field in the system
Three sources can produce a next-hearing date: the court's own structured data, an advocate's manual override, and an AI extraction from an order. They are never merged into one column. An advocate's own override always wins when present — see Domain Model for the storage rule and Core Flows for the precedence flow. Every other feature in this catalogue is secondary to getting this one field right.
The economic constraint
Pricing is ₹999/1yr, ₹2499/3yr, ₹3999/5yr — roughly ₹800 per user per year, about ₹2.20 a day. Each user brings N cases and each case is polled daily, forever. Marginal cost per user is therefore linear, not near-zero. At ~10 cases per user, a poll that costs more than ₹0.22 means the business loses money faster as it grows.
Optimise for cost per successful poll and connector uptime. Not requests per second.
What carries over from MyMunshi
The old system is 78 repositories. Almost none of the code should survive, but a great deal of hard-won knowledge should.
Court connector logic
How to search each of ~70 court sites: form fields, case-type codes, result markup, captcha handling. This is the moat and it was expensive to learn.
The court registry
The high_courts collection — court metadata, URLs, case-type lists. Referenced 498 times across the old tree. Migrate the data, not the schema.
The matter identity rule
{court}-{case_type}/{number}/{year}, already used fleet-wide as unique_id. It works. Keep it, but enforce it in the database this time.
Notification channel mix
WhatsApp via Interakt, FCM/OneSignal push, email, PDF cause-list reports. The channel choices reflect real user behaviour in this market.
What does not carry over
- The 78-repo layout. One monorepo, one worker image, connectors as plugins. See System Architecture.
- Flask + pm2 +
git pulldeploys. Containers and CI from commit one. - The shared MongoDB. See Domain Model for why this becomes Postgres.
- Duplicated helpers. The old tree has 50 copies of
core/helpers, already drifted into at least three generations. One shared package. - Python 3.9 and Flask 2.2. Standardise on Python 3.12.
Carried-over risk, unresolved
Fresh repositories do not rotate the credentials committed to the old ones. Those keys — AWS, Firebase, Interakt, mail, and the Mongo admin password — remain live and still control the production system serving today's customers. Rotation is independent of this rebuild and should happen on its own track.
Where the old system stands today
Measured directly from the working tree, for reference when scoping migration work.
| Measure | Count | Note |
|---|---|---|
| Project repositories | 78 | ~70 are court connectors |
| Python files | 2,154 | |
Connectors exposing /api/find | 49 | the de facto interface |
| Repos using Selenium | 15 | the cost hotspot |
| Repos using plain HTTP | 73 | migration largely done |
Copies of core/helpers | 50 | at least 3 divergent generations |
| Dockerfiles | 1 | |
| CI pipelines | 0 |
Who the customers are
Two segments, served by one product:
- Individual advocates — one person, their own cases. The volume segment.
- Agencies and law firms — a practice with employees, where cases are assigned to staff, and seats and matters are capped by plan. The revenue segment.
These are not two products. As Tenancy, Roles & Plans argues, an individual is modelled as an organisation with exactly one member — which keeps a single code path and a single authorisation model rather than two that drift.
Explicitly out of scope for v1
Naming these now prevents them being smuggled into the MVP: e-filing integration and document drafting. Several exist in fragments in the old tree. They are not what makes users pay for v1.
Client management, invoicing, and the live display board are specified but deferred to v2.0 — see Tenancy, Roles & Plans for client and invoice entities, Live Display Board for the board module, and Roadmap for sequencing. They are documented now so the v1 schema does not have to be reshaped to fit them later, but v1 ships without them — the MVP stays "track cases, tell me when something changes."
The four hard problems
Everything else in this system is ordinary software. These are not, and each has its own document.
Connector fragility
~70 court sites that change without notice. Connector Framework
Captcha
Most court sites gate search behind one. Outsourcing solves is economically impossible here. Captcha Pipeline
Unstructured PDFs
Cause lists in ~70 layouts, many scanned. The hardest problem in the product. Document Parsing
Cost per poll
₹0.22 of headroom, spent daily, forever. Constrains all three above.
How to read these documents
- Domain Model and System Architecture establish the shape of the system.
- Connector Framework, Captcha Pipeline and Document Parsing cover the hard problems. These three matter most.
- Court Coverage applies them to the actual priority courts, and records the migration hazards found in the old repositories.
- Core Flows traces the sequences that constitute user-facing behaviour.
- Tenancy, Roles & Plans and Security Architecture cover the platform. Security includes a documented disagreement — read it.
- Feature Catalogue is what users actually see, written in their language. Live Display Board covers the office-screen module in the same terms.
- Technology Decisions, Environments and Roadmap cover delivery.