Something odd has been happening inside the companies that build software for India’s legal world. Case-management vendors, e-filing contractors, the IT cells of large law firms: several have quietly regrouped part of their engineering staff and started saying “PlatformOps” in meetings. The word sounds like branding, and occasionally it is. Behind it, though, sits a genuine change in how internal tools are run, and it deserves a careful explanation for anyone who buys, reviews or reports on the systems that courts and chambers now depend on. What follows is a rollout told step by step, built around a composite legal-tech team — call it Kanoon Systems, a mid-sized firm in Noida that maintains a case-filing and cause-list product used by district practitioners.

Kanoon’s engineering head had read the Ops Atlas PlatformOps entry on a flight to Delhi and came back with a simple observation: her company was already doing some of this, badly and by accident. Three product squads maintained three different ways to send SMS hearing alerts, three document-storage wrappers, three login flows. Nothing was forbidden; everything was duplicated. The textbook name for fixing that — running shared tooling as an internal product with service levels, upgrades and real support — is what the term actually describes. She gave herself ninety days. Here is the sequence she followed, which generalises well beyond legal software.

Step 1: Confirm the Problem Before Building Anything

The first move was interviews, not code. She sat with five delivery teams and asked what they rebuilt most often and what slowed them down. The answers overlapped enough to be embarrassing: identity, notifications, document handling, deployment pipelines. Alongside the interviews went an inventory of every shared capability already in service, each with a named owner or, more often, nobody.

That exercise also produced a verdict she almost skipped: the company might not need a dedicated platform at all. Small organisations can run perfectly well on a wiki page and a folder of shared scripts. The usual threshold suggested in platform engineering circles is around three teams with repeated, overlapping needs and funding committed for at least two years. Kanoon had five squads and a three-year product roadmap, so the case held — but the check came first, and it should always come first.

Step 2: Write a Charter That Promises Less

The second step produced a one-page charter, and the discipline was in what it refused to promise. PlatformOps, done honestly, borrows the Team Topologies idea of the thinnest viable platform: provide just enough shared capability, and no more, because every extra layer becomes something somebody must maintain forever. The charter listed what the platform group would run (identity, alerts, document storage, the delivery pipeline), what it explicitly would not touch (application code, tenant data, court integrations), and how teams could disagree with its choices.

One line in the charter mattered more than the rest: the platform would be optional. Adopting it had to be a pull decision by product teams, not an instruction from above. Internal platforms that are compelled tend to receive compliance rather than users, and compliance shows up as ticket queues and quiet workarounds. There is a quieter benefit to voluntariness, too. A team that joins because a colleague cleared an evening for it will forgive the early rough edges; a team that joins because it was told to will document every one of them and forward the list to a director.

Step 3: Build One PlatformOps Golden Path With a Partner

Rather than a grand portal, the next ninety days produced a single paved route: one supported way to take a new microservice from repository to production, with alerts, logging and document storage attached by default. The golden-path idea is old — Spotify was writing about it around 2014, and Netflix calls its version the paved road — and the rule is that the route is opinionated and supported, while leaving it remains possible, just unsupported.

Crucially, one squad — the cause-list team, because its deadlines were brutal and its patience thin — was recruited as the design partner. The platform group built against that squad’s actual work, not an imagined specification. Every friction the partner team hit became a backlog item the same week. PlatformOps lives or dies on this habit: the people running the platform sit close to the people it serves, the way a chambers’ junior sits close to instructing counsel.

Step 4: Beta With Two Teams, and Count What Happens

The golden path went to a second team, then a third, under an explicit beta label. Expectations were set honestly, including the shape of the curve: delivery metrics usually dip before they improve, the J-curve that DORA’s researchers describe. Kanoon tracked four numbers during the beta — time to first deploy for a new service, the share of services on the path, how often teams left it, and how many support requests arrived each week.

The beta also surfaced political work that nobody budgets for. One squad lead objected that the path locked him into somebody else’s choices. His phrasing was blunter than the meeting minutes recorded:

“I’m not against it. I just want to know who I shout at when it falls over at midnight, and who pays if I walk away from it.”

Both questions had answers — the platform roster, and the documented exit route — and writing them down settled the argument. That objection was answered with evidence and an escape hatch, not a memo. Platform groups that win arguments with authority lose them six months later.

Step 5: Publish PlatformOps Service Levels Before GA

General availability came with paperwork, and the paperwork was the point. Four facts had to be attached to every capability before it could be called generally available: a lifecycle stage, an owner willing to be named, a service level anyone could read, and a support tier recording who answers at 2 a.m. and who answers never. Kanoon’s alerting service, for instance, promised 99.5 per cent monthly availability during court hours with a stated best-effort tier outside them — a promise legal readers will recognise as a service-level agreement in miniature.

Something similar is becoming normal across the software industry, including the tools that handle filings and cause lists. When a vendor talks about reliability, the useful question is whether any named team is on the hook for specific numbers. PlatformOps makes that question impossible to dodge, because publishing the numbers is part of the job. Readers following the courts will notice the parallel with the argument over virtual versus physical hearings: the technology exists, and the hard part is who stands behind it — much as the Supreme Court declined to force the issue and let the Delhi High Court decide on physical hearings for itself.

Step 6: Retire Something, On Purpose, Early

The last step looked like self-sabotage. Alongside the launch, Kanoon scheduled its first deprecation: an old alerting library, superseded by the platform service, with a published end date and a named person whose job was migrating the teams still using it. Deprecation done this way is staffed work — warnings posted to a wiki rarely move anyone, as Google’s own engineers have written; migration happens when somebody walks a team through it.

The alternative is what most legal software users know too well: ten versions of everything, all permanently half-supported, because nobody was ever assigned to switch anything off. Unmanaged backlogs are their own argument. An RTI reply showing more than a thousand bail and sentence-suspension petitions pending in the Supreme Court makes the point in a different domain entirely: accumulation without an owner compounds until it becomes the system’s defining feature.

What This Looks Like From the Outside

For readers of legal news, the practical outcome is a sharper set of questions for any vendor or court IT project:

• Is the shared plumbing run as a product with owners and service levels, or does every request move through a ticket queue?
• Do teams choose the platform, or were they ordered into it by an executive memo?
• Is anything being deprecated right now, with staff assigned to help users move across?
• Who carries the pager for the platform itself, as distinct from the application built on top of it?

Vendors with honest answers tend to ship faster and break less, because their engineers spend their weeks on the product instead of rebuilding login flows. Vendors without answers are usually the ones whose portals fail on filing day. The vocabulary will keep shifting, but the discipline underneath — internal platforms run as products, measured and supported like them — is settling into place across industries, legal tech included. Watching for it is becoming part of due diligence, right beside reading the day’s top 20 Indian legal developments.