← All insights

Building

Why We Hold the Patents

By Raman Kapil · June 25, 2026 · 2 min read

Consulting firms do not usually file patents. They sell judgment by the hour, and judgment is hard to protect and harder to scale. MarkR Management started the same way, as advisory work done by hand. But somewhere in the middle of solving the same expensive problem for the third or fourth client, it became obvious that a few of these problems were worth solving once, properly, for everyone. That is where the software, and the patents, came from.

Protect the method, not the obvious

A patent is only worth filing when there is a genuine method underneath, something novel and non obvious, not just a screen over a calculation anyone could rebuild. Mapping many suppliers' invoices into a true loaded cost and margin for every procedure is that kind of method. So is running a board's governance through a consistent set of checks and producing a scoped brief for each director. These are not features bolted onto a portal or a spreadsheet. They are the invention, and they are worth protecting.

Why ownership matters

MarkR holds the patents and all rights to its products, and that is deliberate for three reasons. It protects the work from being copied the moment it proves valuable. It protects our partners: a vendor licensing one of our engines as a white-box solution is licensing something defensible, not something a competitor can clone next quarter. And it imposes a useful discipline on us, because the act of writing down what is genuinely novel forces a clarity about the invention that loose product thinking never does.

Built in-house, on purpose

The products are built by our own developers and systems engineers, not handed to an outside shop and forgotten. That keeps the method, the code, and the patent in the same place, and it means the people who understand the invention are the ones shipping it. DentistOpFlow and BGR are the two that are live and patent pending today. More applications are in active development, each one starting the same way the first did: a problem we kept solving by hand that turned out to be worth building once, for everyone.

There is a through-line here that ties the software back to the advisory work. In both, the job is to find where a business quietly loses value and build the system that stops it. Sometimes that system is an engagement. Sometimes it is a product. When it is a product worth owning, we own it.

Two ways to work with MarkR

An advisory engagement, or a platform that could embed one of our engines. Let us talk.

Start a conversation