There is a 1975 Soviet film called "The Irony of Fate" in which a man gets drunk in Moscow, falls asleep on a plane, and wakes up in Leningrad. He takes a taxi to his address. The building has the same name as his building in Moscow. The apartment number is the same. His key fits the lock. He walks in, sits down, and cannot immediately tell that he is in the wrong city. The furniture is different but the furniture is not so different. The layout is identical. The address is a fact that the space itself cannot confirm.
The film is a comedy. It is also, viewed from 2026, a fairly precise description of where enterprise software is heading.
Open any dashboard built in the last eighteen months. Open another one. Open a third. Change the logo. Change the color of the primary button. The underlying experience is the same experience: the same card grid, the same chart library, the same left-nav, the same empty state, the same modal behavior, the same typeface that is not quite Inter but is spiritually Inter. You are in the right apartment. You are also in every apartment.
The problem is not that the dashboards are ugly. Most of them are not ugly. The problem is that nobody who uses them had any hand in building them, and it shows. They are spaces with no one living in them. Functional, inoffensive, and completely devoid of the accumulated fingerprint of the people who are supposed to inhabit them.
This is about to get worse before it gets better. But it is going to get better, and the category that fixes it already has a name, even if the industry has not started using it yet.
Artisanal software is going to be a thing.
How We Got Here
The homogenization of software did not start with AI. It started with design systems, which were a reasonable solution to a real problem: inconsistency at scale is expensive, so you standardize the components, align the patterns, ship faster and more coherently. The tradeoff was that the components carry no institutional knowledge of the people using them. They are built for the median user because they have to be, because the median is the only user a design system can address.
Then Figma templates. Then component libraries. Then the long wave of SaaS consolidation that pushed every product toward the same surface area because every product was selling to the same enterprise buyer with the same procurement checklist.
By the time LLMs arrived, the aggregate was already well established. The models trained on it. They learned that software looks like this, that onboarding flows like this, that a pricing page has these three tiers, that a dashboard has these six widgets. Then they started producing software that looks like the software they learned from. That software gets built and shipped and scraped and becomes the training data for the next model.
This is not a neutral process. It is a feedback loop, and feedback loops compound. The median of today becomes the floor of tomorrow. The attractor gets stronger with every iteration. Nobody is deciding that all software should feel like a hotel room. It is just what happens when you optimize for the aggregate, repeatedly, with no signal from the specific community the thing is supposed to serve.
The Soviet planners did not intend to build apartments that all felt the same. They were optimizing for speed and cost and replicability. The person who would live there was an abstraction. The result was a country full of spaces that nobody owned in any meaningful sense.
We are building a very similar country, one deployment at a time.
What Artisanal Software Is Not
Before defining the thing, it helps to clear the ground.
Artisanal software is not old software. Nostalgia is not the argument here. Nobody is making the case for command lines and .ini files on aesthetic grounds.
It is not buggy software. Roughness is not a feature. The artisanal category does not require or celebrate instability. A corner bakery is not a good bakery because it has inconsistent hours. It is a good bakery despite the inconsistent hours, because something else it offers is worth the inconvenience.
It is not anti-AI software. This is important and we will come back to it. AI is not the enemy of artisanal software. Centrally planned, community-free, aggregate-optimized AI deployment is the enemy of artisanal software. Those are different things.
And it is not beautiful software, necessarily. Beauty is a possible output, not a requirement. Some of the best examples of the category are genuinely hard to look at.
What Artisanal Software Actually Is
Artisanal software is software that has been lived in.
It is built by people who are also its users, or built in such close proximity to its users that the distinction collapses. It accumulates the preferences of a specific community over time. It gets weird in the ways that community's needs are weird. It has opinions that exclude people on purpose, because serving one group precisely requires ignoring another group entirely. The interface has scar tissue. Features exist because someone asked for them by name and the builder understood exactly why.
You cannot average your way to that. You cannot prompt your way to that. You can produce something that resembles it visually, the same way you can manufacture something that looks like a worn leather jacket. The people who own worn leather jackets know the difference in about four seconds.
Three signals that the category is real:
Communities create depth that cannot be designed. Discord should not work. Every competitor has cleaner information architecture, better onboarding, a more coherent visual language. Discord is larger than all of them combined and people live in it in a way they have never lived in Slack. The density is not a design flaw that survived QA. It is the accumulated weight of millions of community interactions compressed into interface over years. You cannot replicate that by hiring better designers. You can only grow it, which requires starting with a community that has real needs and staying close enough to let the product become a reflection of them over time. Linear did this. Figma in its early years did this. The products people evangelize rather than merely use have almost always done this.
Specificity is a moat, not a liability. The conventional product wisdom is to sand down the edges, reduce friction, broaden appeal. Artisanal software does the opposite. Every feature that makes the product more useful to its core community and more confusing to everyone else is a good trade. The confusion signals that something real is happening here, something with a learning curve, something that rewards the person it was built for. That signal is the moat. Generic software, by definition, cannot replicate it. The more frictionless the AI-generated alternative becomes, the higher the signal value of the thing that is clearly not a generic output.
Institutional knowledge is underrated and underbuilt. Most organizations have at least one tool with no official name. Rick's optimization. The allocation spreadsheet. Karen's thing. These tools are often unstable, sometimes ugly, and completely irreplaceable, because they encode years of knowledge about how this specific business actually works. They know that the Tuesday numbers are slightly off because of how the West Coast team submits. They have the workaround someone added in 2021 after the edge case that still has not been fixed. They are artisanal by accident, built by someone who understood the problem better than any vendor ever would. When organizations replace them with something cleaner and AI-generated, they get a product that is correct in the generic sense and wrong in all the specific ways that mattered. The new tool has no history. The organization loses something it cannot name and does not notice until it needs it.
The Hybrid Question
Here is where the category gets genuinely interesting and genuinely unresolved.
AI-assisted development has made it cheaper by an order of magnitude to build specific things for specific people. A team of two with strong domain knowledge and access to modern coding tools can now build the thing their community actually needs, rather than the median approximation of it. That is not a threat to artisanal software. That is potentially the production method for artisanal software.
The citizen code movement is the early version of this. People inside organizations building their own tools, AI-assisted, fit for their specific purpose. Not a generic dashboard but a program built around the exact workflow it supports, by the person who runs that workflow, shaped by the people around them who use it every day. The AI handles the scaffolding. The human provides the specificity.
This is the most plausible path to artisanal software at scale, and it has one significant failure mode: enterprise policy.
The guardrails that large organizations erect around internal AI development, approved tools lists, security reviews, mandatory component libraries, standardized design systems, are reasonable responses to real risks. They are also, when applied without judgment, a mechanism for producing the same hotel-room software inside the organization that the market produces outside it. The citizen coder who wants to build something specific for their team runs into the approved component library, which was chosen because it works for everyone, which means it works for no one in particular, which means the output loses the specificity before it ships.
Whether the hybrid model produces artisanal software or just faster generic software depends almost entirely on how much room the organization leaves for the people using it to actually shape it. That question is organizational and political, not technical. The technology is ready. The institutions are not.
Why the Market Is Real
The craft beer comparison is worth making seriously. When mass-produced beer achieved its final form, the market for alternatives did not disappear. It grew for thirty years. Not because people are nostalgic for something inferior. Because a segment of the market has always been willing to pay for something made for them specifically, by people with a genuine point of view about the thing they are making.
The artisanal software buyer is making the same rational calculation. The generic AI-generated tool does eighty percent of what they need, immediately, for almost nothing. The specific tool, built by and for people like them, accumulated over real time in response to real needs, does a hundred and ten percent. The price difference is justified by the fit difference. That is a market, and it is larger than the nostalgia market, because it is not about nostalgia at all.
The communities most likely to generate demand first are the ones already forming their own taste: developers, designers, researchers, operators in specific verticals with strong professional identities and a long history of being underserved by software built for the broadest possible buyer. These communities know the difference between a tool that was built for them and a tool that was built for everyone. They have always known. They are just about to have a name for the distinction.
The man in the film eventually figures out he is in the wrong apartment. The realization comes slowly, then all at once, when something is wrong in a way he cannot quite explain before he can. The space is correct. The space is not his.
That feeling is coming for enterprise software users everywhere, as the tools they use converge toward a common address that belongs to no one. The category that answers it is not a protest against efficiency. It is a market response to a real and growing need.
Artisanal software is software that has been lived in.
We are naming it now because the category is forming whether we name it or not. Better to name it clearly, define it precisely, and build it intentionally than to watch it emerge without a frame and get mistaken for nostalgia by people who missed the point.
You can tell as soon as you walk in.