AI has read everything about your field. It still can't do your job.
The software you've always known should exist is now buildable. What it needs is the part only you know.
Patterns aren't context
A model has read more about your field than you ever will. The textbooks, the manuals, the papers, the standards, the forum threads, ten thousand documented versions of the thing you do. On raw coverage it has you beaten, and it isn't close.
It still can't do your job. The gap has nothing to do with how clever it is. A model works from patterns, and you work from context.
A model knows what's typical. It doesn't know that this client's numbers always run two weeks behind. It doesn't know the regulator who signs off on this changed last spring. It doesn't know that the textbook answer is the one that quietly loses you the account, or that the form everyone fills in is the form nobody reads.
So it gives you something plausible. Confident, well-formed, correctly structured, and wrong in a way that only shows up if you've been doing this for fifteen years.
The gap isn't closing on its own, because the information that would close it was never written down anywhere a model could read it.
What domain experts know
Domain experts know something else. They know which problems are worth solving. They've spent years inside workflows, spotting where judgment matters, and tracing the edges of intractable problems.
Three things, none of which show up in a document.
Tacit knowledge
The part you can't write down, largely because you've never had to say it out loud. You glance at a file and know it's going to be trouble. You know which client “yes” is a real yes. You know that step four of the official process is the one everyone skips, and why skipping it is usually right. Ask how you knew and you'll say something unsatisfying, like “you get a feel for it.” The vagueness is accurate. The knowledge lives in recognition rather than in words.
Earned insight
The part that cost you something. Every rule you follow that isn't in the rulebook is there because of a specific bad afternoon you can still remember. You know the three exceptions that break every clean rule in your field, and you know them precisely because you got caught by all three. There's no shortcut to it. You learn it by getting it wrong, and that still takes as long as it always did.
Trusted relationships
This one isn't knowledge. People take your call. When you say a thing is worth doing, a particular set of people believe you, and they got there over years of watching you be right. A funded startup entering your field has to buy that attention one impression at a time, from people who have no reason to trust it yet. You already have it, and you didn't set out to build it.
The pattern knowledge is the part that got cheap. What you know without being able to say it, what it cost you to learn, and who believes you when you say it all stayed expensive.
Convergence
Neither kind of knowledge does much on its own.
Building capability without domain judgment produces software that is technically sound and practically useless. The generic tool everyone tries once and abandons, because it doesn't know how the work actually goes.
Domain judgment without building capability produces what it always has, which is a very good consultant with a full calendar and a waiting list.
The same technology that can't replace your judgment is unusually good at carrying it.
Point it at being you and it produces confident nonsense. Point it at executing what you already know and the economics of your field change, because the cost of turning an idea into working software has collapsed.
The economics of renting time
Most experts rent this knowledge out by the hour.
It works. It's also a poor way to sell what you know.
Time doesn't scale. Roughly 1,500 billable hours in a year, and that number doesn't move no matter how good you get.
It doesn't compound. Solving the same problem for the eleventh client is worth what it was worth for the first, minus your enthusiasm.
It's sold once. The insight that took fifteen years and three bad afternoons to develop gets delivered to one client, in one meeting, and then it's gone.
Expertise was always the thing being sold. Time was how it got delivered, because until recently there was no other way to deliver it.
Productize your expertise
Now there's another way to deliver it.
Productizing expertise means taking the part of your judgment that repeats and putting it into something that runs without you. A tool, an assessment, a system, software that carries your reasoning. Build once, deliver many times. What you know stops being something you perform on request and starts being something that works while you're elsewhere.
The opinion is the product. A wrapper with no opinion is worth what every other wrapper is worth. What makes yours defensible is the years of pattern-matching that decide which questions it asks, which answers it refuses, and what it tells the user to do next. The technology itself takes a weekend to copy. Anyone can reach the patterns now; almost nobody can reach your context.
You keep consulting. In practice the split runs closer to this. The repeatable majority of your work becomes the product. The judgment-dense minority stays with you, and you charge more for it, because your hours have stopped going to the parts a system can handle. The product absorbs volume, you take the exceptions, and it tends to surface those exceptions for you.
It ships into a market that already knows you. Most software fails at distribution, not at engineering. A generic competitor entering your niche starts from zero trust and buys attention by the click. You start with a list, a reputation, and a set of people who already ask your opinion before they decide anything. Most of that you built without meaning to.
There's also what's left at the end of it. Consulting revenue stops when you stop; a working product carries on.
How we work
We don't sell you a build and leave.
What makes your product worth anything is tacit, which means it can't be handed over in a kickoff meeting. It surfaces slowly, in arguments about edge cases, in the moment you look at what we shipped and say no, not like that, because. That “because” is the product, and it only comes out over months of working together.
So we work as the other half of the convergence. You bring the judgment and the relationships. We bring the building. We stay for the years it takes to turn a first version into an asset.
It does mean we take on few partners at a time, and we're careful about which. This only works at a depth that a long client list makes impossible.
This is for you if
You run a boutique consultancy.
Ten to a hundred people. Revenue tracks headcount and calendar, so growth means hiring, and hiring means thinner margins and a diluted version of the thing clients came to you for. You've noticed how many engagements follow the same shape. You've thought more than once that you're being paid well to do something you have already done.
You work in a niche domain.
Your field is too specific for a venture-backed software company to bother with. Four thousand potential customers is a bad market for a company that needs a hundred thousand, and an excellent one for you. The generic tools don't know your vocabulary, your regulations, or the three exceptions that make the standard answer wrong. And you already know most of the four thousand, or know the people they listen to. Nobody else is especially likely to build it, and you're better placed than most to try.
You're not technical.
You've been told the idea in your head needs a technical cofounder, a six-figure build, or an eighteen-month roadmap. That was true until recently. The gate you couldn't get through has moved. What the work needs now is knowing precisely what should be built, and recognizing “right” the moment you see it.
You've spent years learning things that were never written down, and earning the trust of people who now take your call. None of that goes anywhere. It's worth more now than it used to be.
The new questions are what package it comes in, and at what scale you deliver.