Andrews DeanContext
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 the majority 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.
The first version started narrower than the ambition: one thing, done well, for one firm shape. Multi-tenancy went into the architecture on day one. Every table carries a workspace ID, and Postgres row-level security is the actual tenant boundary, enforced at the database, with app-level filtering as a second layer on top. Retrofitting that later is effectively a rewrite, so it had to be right before the first feature shipped. Tiering, storage limits, and self-serve billing all came after someone was in the product daily.
I directed the build more than I typed it, and the way I did that is worth describing on its own: a written product spec, information architecture, database schema, and API contracts, kept current as the single reference the build worked against for the whole project, the same discipline I'd use onboarding a new engineer. That discipline is a lot of why a working multi-tenant SaaS with real auth, billing, and an internal ops panel exists at all, built part time alongside a full-time role running a 30-person product org.
Billing didn't ship to the original plan. The spec named Stripe; the market runs on UPI and net banking, so when it came time to actually collect money, the build shipped Razorpay instead. It's a small, concrete example of a written plan meeting ground truth and losing, the kind of correction that's only available to someone close enough to the build to make it without a re-scoping meeting.
Pricing tracked the constraint the customer actually feels: practice size and matter volume, the things a firm can predict and self-assess, instead of seat count, which punishes exactly the collaborative usage the product needs to become sticky.
Support conversations, onboarding drop-off, churn emails: I owned the unglamorous half too. Nothing sharpens product judgment faster than being the person who reads why someone left, and it's the part of the job that stays invisible when you've only ever worked inside a large org.
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.