A general counsel of a growing Indian company gets approached constantly. There is a contract lifecycle platform, a research product, an e-signature vendor, a matter management system, a compliance calendar, a board portal, a document automation tool, and now a great many things with the word AI attached. Each demo is competent. Each product solves a real problem. And the aggregate is a proposal to spend a meaningful share of a legal budget on software for a team of four people who are currently drowning in work that none of these tools directly does.
The standard advice does not help, because almost all of it is written for legal departments of eighty lawyers with a dedicated legal operations function, a technology budget approved separately from headcount, and a procurement team to run the evaluations. That is not the Indian in-house reality. The median Indian legal team is small, reports into a finance or corporate function, competes for budget against things that visibly generate revenue, and has nobody whose job is to implement software.
So this is a different kind of map. It starts from capabilities rather than categories, matches them to team size, and is direct about what to skip. The single most useful thing a lean team can hear is not which product to buy. It is which three problems are worth solving with software this year and which seven are not.
The thesis
Below roughly twenty lawyers, consolidation beats best-of-breed, and it is not close. A slightly worse tool that lives alongside the others, shares a login, shares an access model and shares a bill is worth more than a better tool that becomes an island. The trade flips when you have someone whose actual job is to make tools work together, and not before, because integration effort is the scarcest resource in a small team and it is invisible in every vendor comparison.
Start With Capabilities, Not Categories
Vendor categories are marketing artefacts. They describe how the software industry organises itself, not how legal work is organised. A more useful frame asks what a legal function actually has to be able to do, and there are only five things.
Know the law
Find the statute, the rule and the precedent that governs a question, verify it is current, and see how a specific court or tribunal has treated it. In India this includes the hard part: locating decisions across the Supreme Court, the High Courts, the district judiciary and a wide set of tribunals, where publication is fragmented and uneven.
Know your obligations
What the organisation has promised in its contracts and what statute requires of it, when each falls due, and who owns it. This is the capability whose absence shows up as a missed renewal, a lapsed filing, or an obligation nobody operationalised.
Know your disputes
What proceedings the group is party to, across which forums, at what stage, with what exposure, handled by whom, at what cost. Most Indian in-house teams have this in a spreadsheet assembled from external counsel updates, and most of those spreadsheets are wrong in ways nobody can see.
Move work through the function
Intake, triage, assignment, approval and closure. Not glamorous, and the capability whose absence is felt most acutely by the business, which experiences the legal team as a queue with no visible position.
Show what happened
Produce, on demand, the record of what was decided, by whom, when, and on what basis. This underpins audit, board reporting and regulatory response, and it is a byproduct of the other four capabilities being done in systems rather than in inboxes.
Every product being sold to you claims a position in one or more of these. The useful question in a demo is not what the product does. It is which of these five capabilities it improves, and whether that capability is currently your binding constraint.
The Stack by Team Size
Team size is a crude proxy, but it correlates well with the things that actually determine what is worth buying: transaction volume, the number of people who need to coordinate, and whether anyone has time to administer a system.
| Team size | Worth buying | Worth skipping | The binding constraint |
|---|---|---|---|
| One to three lawyers | Legal research with real Indian court coverage. E-signature. A shared document store with a genuine folder discipline. That is close to the whole list. | Matter management, document automation, workflow tooling, analytics, anything requiring configuration. A dedicated CLM is usually premature unless contract volume is unusually high. | The lawyers' own time. Anything that requires setup and maintenance costs more than it returns. |
| Four to ten lawyers | Add contract lifecycle management, because the portfolio has passed the point where a spreadsheet can hold renewal dates. Add a structured intake route. Add litigation tracking if there is a real docket. | Best-of-breed point solutions, legal spend analytics, knowledge management platforms. Also skip anything whose value depends on data you are not yet capturing. | Coordination. Work is now lost between people rather than within one person's head, which is a different failure and needs a different fix. |
| Eleven to twenty five lawyers | Matter management proper, contract analytics on the executed portfolio, structured approval workflows with thresholds, and reporting that a board pack can be built from. | Bespoke development, and any platform requiring a full time administrator you do not have budget for. | Visibility. The GC can no longer personally know the state of everything, and the function needs to be legible to itself. |
| Twenty five and above | Now the best-of-breed trade genuinely flips, if and only if there is a legal operations function to own integration. Spend management, entity management, specialised compliance tooling. | Consolidation for its own sake. At this size a single suite starts constraining specialised teams more than it helps them. | Specialisation. Sub-teams have genuinely divergent needs and a single tool starts to be the compromise nobody likes. |
Two things that are not on the list at any size
First, a tool bought to solve a problem the team does not have yet, on the reasoning that it will grow into it. Unused software is not an investment, it is a subscription and a maintenance obligation. Second, a tool bought because a peer company uses it. Their contract volume, docket shape and reporting obligations are not yours, and the fact that a comparable company is happy tells you nothing about whether the capability is your binding constraint.
The Two That Earn Their Keep Earliest
If a lean Indian team can justify only two pieces of software beyond the obvious infrastructure, the case for these two is stronger than for anything else, and for reasons specific to India rather than borrowed from elsewhere.
Research with genuine Indian coverage
In-house lawyers are told they do not do research. They do, constantly, in short bursts: has this clause been tested, how does this bench treat this issue, what happened to the last three companies that took this position, is the authority we relied on in 2019 still good. The alternative to doing it internally is sending it to external counsel, which costs more and takes longer than the question usually deserves.
The Indian specific point is coverage. A research product that covers the Supreme Court and reported High Court judgments is answering the questions of an appellate practice. An in-house team's problems live in the district courts, the commercial courts and a wide range of tribunals, which is where the company's own disputes actually sit and where the great majority of Indian litigation is decided. Coverage of that layer is the thing to test in a demo, using your own live questions rather than the vendor's.
Contract lifecycle management
The case for CLM in a small team is often argued on drafting efficiency, and that is the weakest part of the case. The strong part is the post-signature phase. A signed contract generates renewal dates, notice windows, payment triggers and continuing obligations, all of which are silent. A spreadsheet holds those dates and does nothing with them, which is a categorically different thing from surfacing the right date to the right person before the window closes. One missed auto-renewal on a material vendor agreement typically costs more than several years of the software, which is the only business case a finance director actually needs to see.
A spreadsheet stores a date. A system raises it. That difference is the entire value proposition, and it is why the drafting argument for CLM undersells it.
Evaluating in a Market Full of AI Claims
Every legal product now claims artificial intelligence, and the claims range from substantive to decorative. A lean team cannot afford a long evaluation, so it needs a short set of questions that separate the two quickly.
Bring your own questions, and make them hard
Never evaluate on the vendor's demo dataset. Arrive with five real questions from your own last quarter, including at least two you already know the answer to. The two you know are the calibration: if the product is confidently wrong on those, its confidence tells you nothing on the other three.
Test whether every assertion is traceable
For a research or analysis product, the single most important property is that every proposition links back to a source you can open and read. A summary that cannot be traced to a judgment is a claim you would have to verify from scratch, which means it saved you nothing. Fabricated or misattributed citations are a real and documented failure mode, so treat traceability as a threshold requirement rather than a feature.
Ask what happens when it does not know
A system that returns a plausible answer to a question outside its coverage is worse than one that returns nothing, because the failure is silent. Ask the vendor directly what the product does when the corpus does not contain the answer, and then test it with a question you are confident is outside scope.
Ask where your data lives and who can see it
Your matter list, your contracts and your search history are among the most sensitive datasets your organisation holds. Establish where data is stored, whether it is used to train shared models, who inside the vendor can access it, and how access is scoped inside your own organisation. Given the direction of Indian data protection regulation, treat this as a diligence item rather than a checkbox.
Cost the implementation, not the licence
The licence fee is the visible number and frequently the smaller one. Ask how long implementation actually took at a comparable customer, who did the data migration, and what internal time it consumed. For a five person team, a tool needing forty hours of setup from the only person who can do it is expensive at any licence price.
Agree what success looks like before you sign
Write down the one metric that will determine renewal: contract cycle time, matters with an accurate current status, questions answered internally rather than sent out. Without it, renewal becomes a conversation about whether people like the tool, which is not the same question and is much harder to answer honestly.
Build Versus Buy in a Small Team
Indian companies have an unusual temptation here, because many of them have strong internal engineering and a culture of building. A GC who mentions a contract tracking problem in the right meeting may be offered an internal build, and it will look attractive: no licence cost, tailored exactly, and delivered by people who already understand the business.
It is almost always the wrong call for legal tooling, for one reason. Internal tools are maintained at the priority of the team that owns them, and legal will never be the highest priority customer of an internal platform team. The first version ships and is genuinely good. Then the engineers move to a revenue project, the tool ages, an integration breaks, and eighteen months later there is a system that nobody owns, that holds data the team depends on, and that cannot be migrated because nobody documented it.
The exception is narrow and worth stating precisely: build when the requirement is genuinely specific to your business, when it is small enough to be finished rather than maintained, and when a permanent owner is named. A compliance calendar keyed to your own licence renewals is a good internal build. A contract management system is not.
Where CourtMesh Fits, and Where It Does Not
CourtMesh is built around the consolidation argument made at the top of this article, so it is worth being specific about which capabilities it covers and which it does not.
It covers the know the law capability through unified search across the Supreme Court, all 25 High Courts, the District Courts and the tribunals, over a corpus of roughly 310 million cases drawn only from official government portals, with AI case analysis to help with reading volume. It covers part of know your disputes through a private organisation-scoped watchlist that surfaces new filings against your entities as they appear in the source registries, and through counterparty litigation and insolvency screening for the parties on the other side of your contracts and matters. And it covers know your obligations through My Agreements, the contract lifecycle app, which handles intake and a pipeline view, multi-stage approvals, obligation and renewal tracking, and counterparty management. These sit behind one login with a single access control model, which is the practical form the consolidation argument takes.
What it does not do should be equally clear. It is not an e-signature product. It is not a spend management or e-billing system. It does not draft your contracts, and it does not give legal advice. Court publication in India is uneven and often late, so no coverage claim should be read as exhaustive and a nil result never proves that nothing exists. For a lean Indian team, the case is that three of the five capabilities in one place, with honest limits, beats five point solutions that nobody has time to connect.
Buy for the constraint you actually have
The right stack for a lean Indian legal team is short: research that genuinely covers the courts where your matters sit, something that surfaces contract obligations before they fall due, and a reliable view of your own disputes. Everything else can wait until the team is large enough to have someone whose job is making tools work together. CourtMesh puts research, litigation monitoring, counterparty screening and contract lifecycle management behind one login, with coverage across the Supreme Court, all 25 High Courts, the District Courts and the tribunals. Test it with your own questions, including the ones you already know the answers to.
Explore CourtMesh
