Build versus Buy for IP Workflows: The Eight Conditions

A patent attorney built a custom GPT over a weekend. He loaded it with prosecution templates, prior office action responses, and the active portfolio as context. First-draft office action responses came back in twenty minutes rather than four hours.

His manager did not celebrate. She asked three questions. Where is the data going. Who validated the output. What happens when he leaves.

Both reactions are correct. The capability is real and the risks are real. What is missing is the framework that converts a weekend experiment into an institutional decision.

Why the Question Is Usually Framed Wrong

Build versus buy is normally discussed as an organisational preference. Some practices describe themselves as builders. Others state that they will never develop software. Both positions answer a question that was never asked correctly, because build versus buy is not a property of an organisation. It is a property of a workflow step.

A step-level assessment makes this explicit. The method begins with workflows rather than platforms, decomposes each workflow to the level at which a distinct platform, manual process, or workaround serves each step, and only then produces a recommendation. A prosecution workflow decomposes into invention disclosure intake, prior art search, patentability assessment, claims drafting, specification drafting, filing, office action receipt and routing, office action response drafting and review, filing of the response, and grant and maintenance. Each step has its own answer. A department that buys everything and a department that builds everything are wrong at roughly the same number of steps.

The recommendation is also not binary. Every step resolves to buy, build, or keep, and composable architecture adds a fourth option, orchestrate, in which existing components are connected through a protocol layer to produce a composite workflow. The weekend GPT is frequently an orchestration problem presented as a build problem.

Whichever recommendation is issued, it is only usable if it carries four elements: the rationale, the estimated cost of change, the estimated benefit, and the implementation complexity. It must also identify dependencies, meaning the steps where the recommendation cannot proceed until a prior step has been completed. A recommendation without those elements is a preference with a justification attached.

The Admission Test

The manager's three questions are not build questions. They apply with equal force to a purchased platform, and they determine whether either route is open at all.

Where the data goes is a confidentiality question. Systems that process invention disclosures, prosecution histories, and client communications handle privileged material, and consumer AI services may not comply with client confidentiality requirements. A system that trains on user inputs represents a breach irrespective of who assembled it.

Who validated the output is a quality and liability question. Different systems produce different quality, and without measurement the practice cannot establish which of them meets the standard of care. AI-assisted work product released without a validation protocol creates professional liability exposure. Hallucinated prior art is a real failure mode.

What happens when he leaves is a continuity question, and it separates a capability from an experiment more reliably than the other two. A system maintained by a single practitioner, undocumented and untested beyond that practitioner's own docket, is an asset with a resignation date attached.

A fourth risk sits behind all three, which is the efficiency illusion. Some experiments accelerate the work and others generate rework, and nobody knows which applies because nobody measures. Several of the conditions below depend on a measured benefit, and a practice that has not instrumented the step cannot apply them. Practices that have not conducted an inventory should assume such experimentation is already widespread, since managing partners typically discover several times more AI activity than they were aware of.

Four Conditions That Favour Buying

The first condition is that the step is common to the market and carries no part of the practice's differentiation. Buying is the correct decision for commodity workflow steps where the firm holds no differentiation advantage. Prior art search, trademark screening, and portfolio analytics are performed in broadly similar ways across the profession, and a practice that builds its own version of a commodity step assumes a maintenance obligation in exchange for parity.

The second condition is that the category is technologically mature and multiple production implementations exist. Readiness varies enormously across IP workflows. Patent drafting and patent search are served by established production platforms. Office action response automation works today for a minority of routine rejections and struggles with complex rejections, restrictions, and eligibility issues. Where readiness is high, purchasing converts market maturity into capacity immediately, and an internal build replicates work already done by teams with more specialised training data than the practice will ever assemble.

The third condition is that the failure mode requires an accountable counterparty. Docketing is the clearest case: a missed deadline is malpractice, which justifies extreme conservatism. Steps of this nature require a contractual counterparty, a support obligation, and an auditable failure path. A system maintained internally by one or two people does not provide these.

The fourth condition is that the benefit is recurring and distributed across many practitioners while the cost of change is concentrated in a single implementation. When one implementation raises the output of an entire prosecution team on a step exercised continuously, the economics favour purchase. The test is cost per unit of output at realistic utilisation rather than headline price, since a licence used at a fraction of its capacity can cost more per output than a usage-based alternative.

Four Conditions That Favour Building

The first condition is that the step encodes a method that is proprietary to the practice and central to how it competes. Building is the correct decision for highly differentiated workflows that are core to competitive advantage. A firm whose reputation rests on a particular approach to claims strategy in a specific technology domain is describing an asset. Purchasing a platform that applies the market's average method to that step converts the asset into a commodity.

The second condition is that the binding constraint is the practice's own data rather than the availability of a platform. Office action response is the instructive example: the bottleneck is data infrastructure rather than AI capability, because most firms lack structured prosecution history in a form that any system can consume. No purchase removes that constraint. Where a workflow scores low on technology readiness and high on practice impact, the correct action is to build internal readiness now and deploy when the technology matures. The build in question is the data layer beneath the workflow step.

The third condition is that the requirement is connective and no vendor owns both ends of it. The build option, properly defined, is an internal solution, typically an AI agent or a custom integration. A composite prosecution workflow can use a purchased search engine, route the results through an internally built analysis agent, feed that analysis into a purchased drafting assistant, and push the output into a purchased docketing system, with no requirement that those components share a vendor. The built element is the connective tissue between systems the practice already owns.

The fourth condition is that the practice can carry the maintenance obligation institutionally. Building is cheaper at the outset and carries an ongoing engineering requirement that never appears in the initial estimate. That obligation holds only if the organisation owns it rather than an individual: documented, tested against cases beyond its author's docket, and covered by the quarterly review cadence that governs the rest of the stack. Where such ownership cannot be established, the honest recommendation is keep or buy, and the prototype becomes evidence for a procurement decision rather than the decision itself.

The Symmetry Is Not Accidental

Each build condition is the inverse of a buy condition, and reading them as pairs is the fastest way to apply them. Differentiation against commodity. Market immaturity against market maturity. Connective requirements against self-contained ones. Institutional capacity against its absence. A step that satisfies conditions on both sides has been defined too broadly and should be decomposed further.

The trade-off that remains is architectural. Buying is faster and creates dependency on someone else's roadmap, and the switching cost for a monolithic platform runs to three to five times the annual licence once configuration, training, data migration, and workflow rebuild are counted. Building preserves control and creates dependency on internal capability that must be funded every year the system remains in service. Neither dependency is avoidable. The decision determines which one the practice carries for a given step.

Why the Buy Side Is Harder Than It Looks

The buy conditions assume that the practice can see the market, and this assumption is where most of these exercises fail. A market census published in April 2026 recorded 1,973 platforms and services across 24 categories in the combined IP and LegalTech market, with AI-native entrants tripling in the drafting and search categories over fourteen months. No internal team can maintain current knowledge of that landscape through conference attendance and vendor conversations alone.

The consequence is a systematic bias toward building, because the internal option is visible and the commercial alternatives are not. A practitioner who does not know that a mature category exists for a step will conclude, reasonably, that the step must be solved internally. The market scan is therefore a distinct stage of the assessment rather than an assumption inside it.

The same gap operates on the spend side. Where technology spend is mapped at platform level, with implementation and support costs included, the actual figure typically exceeds the estimate by 20% to 40%, largely because individuals and sub-teams purchase platforms against departmental budgets rather than the central technology budget. A build decision taken without that number ignores what the practice already pays for the capability.

How to Run the Decision

The eight conditions are applied per step rather than per department, and they follow three prerequisites.

The first is the workflow map: every IP workflow decomposed to the step level, with the platform, manual process, or unsanctioned software serving each step identified. This includes the custom systems that individual practitioners have built independently, which are frequently absent from the official inventory.

The second is the finding. A step requires a decision only if it exhibits a gap, an overlap, or underperformance. Underperformance is the most common finding and the hardest to detect, because it requires knowing what the market has produced since the incumbent platform was selected.

The third is prioritisation. Findings should be sequenced against financial impact, implementation complexity, and alignment with the department's priorities for the next twelve to eighteen months, with dependencies scheduled accordingly. A build that depends on structured prosecution data cannot begin before the data work is done.

The attorney was right that the capability exists. His manager was right that it was not yet admissible. The correct outcome is neither to shut the experiment down nor to adopt it by default. It is to place the step into a structured assessment, apply the conditions, and issue a recommendation with a rationale, a cost, a benefit, an implementation estimate, and an owner. That is a decision. Everything short of it is a preference.

One observation is worth carrying out of the exercise. Most of the eight conditions rest on quantities that a department either measures or guesses: what a step costs at realistic utilisation, how long a handoff waits between systems, whether an experiment reduced rework or created it, and what the market now offers for the same step. Where those quantities are instrumented as the work moves across the stack, build versus buy becomes an ordinary, repeatable decision at each step. Where they are not, it remains a preference, argued annually and settled by whoever argues most persistently.