There May Be a Software Product Hiding Inside What You Already Know

For most of the software era, there was a fairly clean division of labor: some people knew things, and other people built software.

A consultant might develop a particularly effective way to diagnose a struggling organization. A marketer might know why a brand keeps drifting. An accountant might know exactly where to look when a healthy-looking business starts quietly bleeding cash. But unless those people also happened to be software developers—or had the budget to hire them—their knowledge usually ended up in familiar forms: a spreadsheet, a slide deck, a PDF, a checklist, a workshop, perhaps a book.

The expertise could be taught, sold or handed off. It could explain what the expert knew. It could not easily do anything on its own.

While building BrandLockBox, I watched a distinction I had been carrying around for years become product behavior. The system did not simply store brand guidance. It separated what a source said from what an authorized person had approved, surfaced contradictions instead of smoothing them over, and kept unresolved decisions out of approved context. A theory of brand authority had started to behave like software.

That is when the larger change became clear to me, and I suspect we are still misunderstanding what it actually is.

The Obvious Story Is That Everyone Can Code Now

There has been plenty written about “vibe coding,” the slightly ridiculous but increasingly useful term for building software by describing what you want to an AI system and letting it do much of the technical work.

In WIRED, Chris Colin documented what happened when a self-described coding “normie” used Claude to build an application around a very particular frustration. His observation gets at something important. For most of the internet era, ordinary people have essentially been passive shoppers for software. We searched an app store and hoped someone, somewhere, had already cared enough about our particular problem to build something for it. Now we can increasingly build it ourselves.

TechCrunch has described the same phenomenon as the rise of “micro apps”: small, highly specific applications created by people who might never have considered themselves software developers. Some exist for a family, a group of friends, a particular workflow or even a temporary problem. They occupy an emerging space between the spreadsheet and the full-fledged software product.

That is fascinating. But I don't think “everyone can code now” is the most important part of the story. In fact, coding may be the least interesting part.

When Production Becomes Abundant, Value Moves

AI keeps collapsing the distance between an idea and a functioning artifact. We have already seen it in writing, design and analysis. Now it is happening in software.

This does not mean software engineering has become irrelevant. Deploying a secure, resilient, scalable application remains very different from getting a prototype to work on a Saturday afternoon. Yet something important has changed: a working application no longer has to originate inside a traditional software company. It can increasingly be the output of someone who understands a problem unusually well.

I have been thinking about this pattern across marketing for some time. AI makes competent production easier. It can produce another article, campaign, image, research summary, presentation and, increasingly, another piece of software. The useful question is no longer whether we can produce more. Clearly, we can. The question is what remains scarce when production no longer is.

My answer continues to be some combination of clarity, judgment, context, trust and the ability to decide what ought to exist in the first place. Software is beginning to demonstrate the same principle.

I Learned This While Building BrandLockBox

Recently, I built a web application called BrandLockBox around a problem I had encountered repeatedly in marketing. Companies spend enormous amounts of time defining their brands and surprisingly little time preserving the resulting decisions. The logo ends up in one folder, the messaging framework in a deck, and the latest positioning in somebody's head. An old PDF contradicts the website. Sales describes the company one way; marketing describes it another. Then AI enters the organization and begins generating material from whatever context someone happens to give it.

The problem is no longer simply brand consistency. It is brand authority. What is true? What is approved? What language should an AI system treat as canonical? What happens when two pieces of brand information conflict?

Large brand-management platforms address parts of this problem. I wasn't interested in recreating one. I wanted something smaller and more opinionated: a system built around discovering brand evidence, clarifying contradictions, governing decisions, applying approved guidance and watching for drift. BrandLockBox does not merely retrieve a sentence from a brand document. It distinguishes source evidence from an approved decision, shows who has authority, identifies conflicts and routes unresolved questions back to a human rather than allowing AI to quietly invent an answer.

Building it changed how I think about this generation of software. The interesting part was not that AI helped me write code. The interesting part was that I had spent years accumulating opinions about what the application should do. AI did not invent the methodology; it gave the methodology a new form.

Expertise Can Become Executable

Consider how much intellectual property is hiding inside ordinary professional work. A strong consultant knows which questions reveal the real problem. An experienced salesperson distinguishes curiosity from buying intent before a CRM score does. A recruiter learns which résumé inconsistencies matter. A professor develops a sequence of questions that reliably strengthens an argument. A CFO knows which numbers must be examined together. A marketer recognizes that the customer's stated problem is often not the real positioning problem.

Much of this knowledge has never been called intellectual property. People simply say, “That's how I work.”

But “how I work” is often a system. It has inputs, rules, exceptions, sequences, thresholds and decisions. It may contain a sophisticated human intervention model: when to act, when to ask another question, when to escalate and when to stop. Historically, converting that tacit system into software required enough money and technical expertise that most people never considered it.

That creates a possibility much larger than vibe coding: expertise can become executable.

The Next Software Creator May Not Think of Themselves as One

The sleeper audience for this technology is not necessarily aspiring programmers or startup founders. It is experienced knowledge workers: consultants, operators, strategists, researchers, educators and other specialists who have spent ten or twenty years getting unusually good at seeing a particular kind of problem.

They may already be sitting on the architecture of a software product without recognizing it. A framework can become a diagnostic. A checklist can become a workflow. A methodology can become an application. A scoring system can become a decision engine. A consulting process can become a client-facing product. Institutional knowledge can become an internal operating tool.

The opportunity may not begin with, “What app should I build?” It may begin with a much better question: What do I know how to do repeatedly that other people find difficult?

The Executable Expertise Test

Not every area of expertise should become software. Some work depends on presence, persuasion, taste or judgment too contextual to encode usefully. But a method may have product shape when it contains several of the following signals:

1. 01
   Repetition: A similar class of problem arrives again and again.
2. 02
   Diagnosis: You notice signals, patterns or failure modes that others routinely miss.
3. 03
   Conditional judgment: Your recommendation changes according to recognizable variables.
4. 04
   Sequence: The work follows a recurring set of questions, decisions or transformations.
5. 05
   Transfer: Someone can receive meaningful value without requiring your full attention every time.

If several of those conditions are present, try mapping the method. What information must enter the system? What decisions or transformations occur? What output or action should result? Where must human judgment, authority or verification remain?

That last question matters. The goal is not to automate the expert out of the picture. It is to make the expert's method explicit enough that software can carry part of it.

Making a method explicit is not the same as proving that it deserves a product. Expertise can define the system, but users still determine whether the system is useful. The advantage of cheaper software production is not that it eliminates this uncertainty. It makes the idea inexpensive enough to test. Knowing how to encode a method does not prove that anyone wants the product; it makes the hypothesis testable.

Easier to Build Does Not Mean Safe to Ship

There is an obvious danger in taking this idea too far. If software becomes cheap to produce, we will produce an extraordinary amount of bad software, just as cheaper content production has produced an extraordinary amount of bad content. Lowering the cost of production does not automatically improve the quality of the result. Sometimes it does the opposite.

A person who does not understand authentication can now build an application that requires it. Someone unfamiliar with data governance can create a product that collects sensitive information. A person who has never designed a decision system can automate decisions. The barrier to making something has fallen faster than the barrier to understanding the consequences of making it.

Even a narrow application creates continuing obligations. Someone must own it, maintain its dependencies, protect its data, evaluate whether it still works and decide when the expertise embedded inside it is no longer true. AI can help express a system. It cannot absolve you from understanding—or governing—the system you are expressing.

The future I find interesting is not one in which expertise becomes unnecessary because AI can build everything. It is almost the reverse. AI can build more things, which makes deciding what should be built, how it should behave, what rules it should follow and where human judgment must remain considerably more important.

Somewhere Between a Spreadsheet and Salesforce

For twenty years, SaaS pushed software toward standardization: build one product, find a sufficiently large market, create a configurable workflow and sell the same underlying system thousands of times. That model is not disappearing. But another layer of software is emerging beneath it—smaller, narrower, more situational and sometimes useful to only one organization or a few hundred people.

This is software that would not have made economic sense to build five years ago because the potential audience was too small. “Micro app” is a useful description, but there may be another category inside it: boutique software, expert software, bespoke AI. The terminology will sort itself out.

The important distinction is that this software does not begin with a market large enough to justify development. It begins with a problem specific enough to justify solving and a person who understands that problem unusually well.

That is why this is not principally a story about the democratization of coding. It is a story about a new form for intellectual capital.

The Better Question

I don't know whether BrandLockBox ultimately becomes a large product, a small product or simply one useful artifact inside a larger body of work. That is almost beside the point. Building it revealed something I had not fully appreciated: I had assumed software products began with software ideas. Increasingly, I think they may begin with accumulated judgment.

The framework you have used for years. The unusual sequence of questions you always ask. The spreadsheet only you know how to interpret. The diagnostic you run in your head during the first ten minutes of every client meeting. The process your team follows because someone learned the hard way that the obvious sequence doesn't work.

Those things have always had value. What has changed is the number of forms that value can take.

For years, experts turned what they knew into books, presentations, consulting engagements, templates, courses and spreadsheets. Now there is another medium available: software.

There may already be a software product hiding inside what you know. You just haven't thought to call it one yet.

Further reading: WIRED on normie vibe coding and TechCrunch on the rise of micro apps.

Back to all articles