Context
Indian law firms run on a workflow that no generic case-management or CRM product models well: cause lists published daily by each court, hearings that adjourn and re-list unpredictably, a court hierarchy that determines which documents matter, and a client relationship that is measured in years. Most firms below a certain size manage all of it in spreadsheets, WhatsApp, and diaries.
DuCase is a multi-tenant SaaS built for that workflow specifically. I own it end to end — the strategy, the pricing, the architecture direction, the go-to-market, and a meaningful share of the build.
The problem
The obvious version of this product is "Salesforce for lawyers," and it fails for a reason worth stating: the value in a small law firm isn't in relationship management, it's in never missing a listing. A tool that models cases as deals is asking a practice to translate its work into someone else's vocabulary every single day, and it loses to the diary that doesn't.
The harder problem was commercial rather than functional. Small Indian law firms are a genuinely price-sensitive market with low tolerance for onboarding friction. Anything that needed a sales-assisted implementation was dead on arrival.
Constraints
- A market that will not sit through an implementation. Self-serve or nothing.
- Real price sensitivity, which forced the packaging question early rather than after product-market fit.
- Building it while running a 30+ person product organisation — so every hour had to go to the thing that most reduced uncertainty.
- No design or engineering team. React, Supabase, and Vercel chosen specifically because they let one person operate a multi-tenant production system.
What I did
Modelled the domain the way practitioners describe it. Matters, hearings, adjournments, cause lists, and court hierarchy are first-class objects — not custom fields bolted onto a deal record. This is the single decision the product lives or dies on, and it's why demos land in the first two minutes.
Started narrower than the ambition. The first version did one thing well for one firm shape. Multi-tenancy was in the architecture from day one because retrofitting it is a rewrite, but tiering, reporting, and self-serve billing all came after someone was in the product daily. Building the general case first is the most expensive way to find out you were wrong about the specific one.
Priced by the constraint the customer actually feels. Tiers track practice size and matter volume — the things a firm can predict and self-assess — rather than seat count, which punishes exactly the collaborative usage the product needs to become sticky.
Owned the unglamorous half. Support conversations, onboarding drop-off, churn emails. I'd argue nothing sharpens product judgment faster than being the person who has to read why someone left, and it's the part of the job that's structurally invisible when you only ever work inside a large org.
Kept the stack boring and the surface area small. React, Supabase, Vercel. One person cannot operate a bespoke infrastructure and also do product work, and the discipline of choosing a stack you can hold in your head is itself a product decision.
Outcome
DuCase is live with paying customers on tiered subscriptions — a small business, but a real one, and the whole loop: acquisition, activation, conversion, retention, and support, all owned by the same person who wrote the strategy.
The transferable part is what it proved. It's straightforward to describe good product judgment; it's harder to demonstrate it when someone has to hand over money. This is the artefact I point to for that.
What I'd do differently
I priced too low at launch, and I did it for the wrong reason — I was solving my own anxiety about the market's price sensitivity rather than testing it. The firms that converted would have paid more, and the ones that didn't convert weren't blocked on price. Raising a price after launch is a much worse conversation than starting higher and discounting.