Your software vendor wants you to hire more people
Seat-based pricing and one-off builds create the same problem: misaligned incentives.
Pricing is an incentive system
Most conversations about legal AI focus on capability. Can it draft, summarise, extract information, or search effectively?
Those questions matter. But firms should also ask a more commercial question: what behaviour does the vendor’s pricing model encourage?
AI accentuates these tensions. If software can take over more tasks, law firm owners should be thinking harder about how to run leaner, more productive teams.
Thus, software pricing becomes a question of incentive design.
The problem with seats
Seat-based pricing is familiar. Practice management systems, case management systems, document tools, and even many recent AI products like Harvey and Legora have a significant seat-based component.
The problem is that seat-based pricing sits awkwardly with AI.
If the vendor makes more money mainly when the firm adds users, the vendor benefits when headcount grows. But better software should often do the opposite: help the same team do more, or help a smaller team handle work that previously required more people.
It also discourages proper usage. The best software system is one where everyone who needs it can log in: lawyers, paralegals, and secretaries. That is how the whole firm becomes more productive.
If every login costs more, firms may start rationing access. Some may reuse accounts across multiple people. The vendor then has to police usage, creating a pointless cat-and-mouse game.
That is bad for productivity, auditability, and security.
The one-off build trap
There is another common model: a large upfront project.
Sometimes this is encouraged by subsidies or grants. Subsidies can be helpful. They lower the barrier to adoption and make it easier for firms to try new technology. If a subsidy only applies for one or two years, both buyer and vendor may be tempted to front-load as much cost as possible into a large bill. The firm pays less out of pocket. The vendor gets paid early.
Sometimes this is how many business owners think about cost. A one-off project fee can feel easier to accept than an ongoing subscription.
But upfront projects can distort incentives. The problem is that software does not stop needing work after the invoice is paid.
Legal practice changes. Staff change. Templates change. Court processes change. Firm preferences change. Once software is used on real matters, people discover edge cases and requirements that nobody could have fully specified upfront.
AI makes this more acute. It is cheaper than before to generate software features, but it is not simple to operate software responsibly. Models launch, improve, and deprecate quickly. Providers change pricing. Capabilities shift. What was the best setup six months ago may not be the best setup today.
Someone still has to manage security, uptime, data handling, provider changes, model behaviour, user feedback, workflow adjustments, and support. That work does not fit a one-off project model very well.
I have spoken to many law firms that had built a one-off software project. Later, when they wanted changes, the problems began.
The original developer may have moved on. The person who understood the system may no longer be available. The vendor may not be interested because the profitable part of the project is already over. Or the firm may be quoted a very high amount for a very small change because it has no easy alternative.
This is not always bad faith. Often the commercial model was wrong from the start. A one-time payment rewards delivery of the first version. It does not necessarily reward responsiveness, maintenance, careful operations, or continued improvement.
Subscription pricing, done carefully
The better alternative is usually some form of usage-based subscription pricing. It avoids the worst problem of one-off builds because the vendor has to keep earning the customer’s business over time.
But care is still required.
A larger firm may have more matters, more documents, and more AI usage. It may extract more value and impose higher operating costs. So it is not obvious that a five-person firm and a fifty-person firm should always pay the same amount.
The principle is simple: pricing should track value.
This is especially true for AI software because usage has real marginal cost. The current AI build-out dominating the news relies on expensive chips, dedicated data centres, and huge amounts of electricity. These are passed on to operators of AI software as token costs.
That points toward usage-based pricing. But usage is hard to define well. The software operator needs enough predictability to cover costs. The buyer needs something understandable, budgetable, and not full of hidden surprises.
In practice, this becomes an ongoing conversation with customers. Different firms need different things. Some need a narrower workflow at a lower price point. Others need heavier AI processing, more document volume, or more firm-specific configuration.
That is the direction we are taking: modular pricing based on what the firm actually needs, with sensible volume caps. It is less tidy than a per-seat table, but it is more honest. The aim is to customise enough to make the software work without pricing in a way that makes the firm use it badly.
What buyers should ask
When evaluating legal software, law firms should ask what the pricing model rewards.
For example:
Does pricing reward the vendor for helping us become more efficient?
Does pricing track value and cost, or mainly tax headcount?
Can the whole team use the system properly?
What happens after the first version is delivered?
What happens when our requirements, AI providers, or model capabilities change?
These are pricing questions, but they also tell you what kind of relationship you are buying.
Our incentives
At Northbridge Lab, we have absorbed a substantial amount of upfront development cost, which is now well into mid six-figure territory.
This is the bet we are making: that the verticals we’ve picked are large enough and the problems common enough for us to absorb the upfront development cost and recover it through subscription revenue over time. But that is exactly why the incentives are aligned: we only win if the software keeps being useful.
We charge a monthly subscription because we want to keep improving the software as firms use it. We do not want every useful improvement to become a separate mini-procurement exercise. If the product is not useful, customers will not keep paying. If workflows are awkward, we have a reason to fix them. If the AI landscape changes, we have a reason to keep evaluating the setup.
Clients sometimes ask why our products cost more than, say, something from Microsoft. The answer is partly scale. Microsoft can spread development cost across a global customer base. We cannot.
But the tradeoff is fit. Generic software is cheaper because it is not built around your practice area, your jurisdiction, your documents, or your workflow.
Clients who work with us will tell you that we are responsive to changes, including firm-specific workflow changes. Good luck getting Microsoft to adjust Copilot for your firm.
That fit is why I am confident specialised software can make a real difference to staffing pressure. The point is not to add another tool to the pile. It is to remove enough manual work that the same team can handle more, or that the firm can grow without headcount growing at the same rate.
That is what aligned incentives mean to me: not a one-off build, not a tax on logins, but software that has to keep earning its place.
AI should help law firms become leaner and more productive.
The software vendor’s incentives should point in the same direction.

