Custom Software is Back
Before factories, furniture was made by skilled artisans. Each piece reflected the maker’s skill, the client’s needs, and the constraints of the material. A chair wasn’t just functional. It was considered. The joinery mattered. The proportions mattered. The way it would age mattered.
Then came industrialization. Factories could produce furniture at a scale no workshop could match. The tradeoff was clear: we got accessibility and affordability. We lost individuality and, often, quality. A factory chair works. But nobody passes it down to their grandchildren.
Software followed the same arc.
The Craft Era
In the early days of software, every system was custom. Teams of engineers built solutions tailored to the problem at hand, the organization using it, the context it lived in. The work was slow and expensive. But when it was done well, it fit like a bespoke suit.
I once talked with a retired engineer who had worked on industrial control systems in the 1960s and 70s. I asked what operating system these systems ran on. He looked at me like the question didn’t quite make sense. The computers didn’t arrive with an operating system. “We wrote the operating system,” he said.
That’s how custom it was. When computers first started being deployed for industrial applications, engineers wrote code in assembly language that executed directly on the hardware — bare-metal programming with no intervening OS layer. The program wasn’t just the application. It was the entire software stack, built from scratch for that specific machine, that specific problem.
I came up in a later version of this world. Not bare-metal, but still custom. Systems built to match exactly what a business needed. The code was written to last.
It was craft.
The Factory Era
Then came commoditization. Enterprise software. SaaS platforms. Off-the-shelf solutions that could be deployed in weeks instead of years.
The tradeoff was the same as furniture: we got speed and accessibility. We lost fit.
Organizations bent themselves around their software instead of the other way around. “Best practices” meant adopting someone else’s process. Customization became a dirty word. Too expensive, too slow, too much technical debt.
The factory won. And for good reason. Most organizations couldn’t afford bespoke software. The factory model democratized capability. A small business could access tools that previously required a custom development team.
But something was lost. Software became generic. Adequate. Good enough, I guess.
Nobody passes down their Salesforce instance to their grandchildren.
The Craft-at-Scale Moment
Something is changing. AI is disrupting the economics of custom software.
The reason craft was slow was time. A skilled developer could only produce so much code, make so many decisions, review so many options. The bottleneck was human throughput.
AI removes that bottleneck. Not by replacing skilled practitioners, but by amplifying them.
A developer who deeply understands a problem, who knows what good looks like, who can evaluate quality and make judgment calls? That developer can now produce at a scale that was previously impossible. The vision stays human. The values stay human. But the execution gets multiplied.
Generating more code faster misses the point. What matters is this: a skilled practitioner can now deliver bespoke solutions at commodity timelines.
Custom can compete with commodity. And custom is still better in many instances.
What Craft Means in Software
What do I mean by craft? It’s not just aesthetics. It’s:
- Fit: the system matches how you actually work, not how a vendor imagined you might
- Longevity: architecture that makes future changes easier, not harder
- Clarity: code a new team member can understand without a guide
- Appropriate complexity: simple where it can be, sophisticated where it needs to be
These qualities were always possible. They were just expensive. Too expensive for most organizations and most problems.
AI changes the denominator.
The Mesh Problem
I see this in many organizations today: a mesh of off-the-shelf systems held together by workarounds, integrations, and compromises. It’s a Rube Goldberg machine — absurdly complex, surprisingly fragile, and nobody quite remembers why the bowling ball has to hit the toaster.
Salesforce talks to HubSpot through Zapier. Someone built a shadow system in Airtable because the “official” tool doesn’t match how the team actually works. There are three sources of truth, and none of them agree.
And then there’s Excel — what I call the duct tape of the business world. Not always the best solution, but used everywhere to tie things together. Data gets exported to spreadsheets for the reports the platform can’t generate. Critical business logic lives in formulas that one person understands. The spreadsheet becomes the integration layer because nothing else fits.
But the most fragile part of this mesh isn’t the software. It’s the institutional knowledge holding it all together. The person who knows which fields to ignore. The veteran who remembers why that workaround exists. The undocumented steps that make the Rube Goldberg machine actually run. When that knowledge walks out the door, the whole thing starts to wobble.
This isn’t a failure of implementation. It’s the inevitable result of bending your organization around software designed for someone else’s process. For years, the mesh was the pragmatic choice. Custom cost too much and took too long.
But that calculus has changed. The same AI that’s disrupting development timelines is making it genuinely achievable for organizations to have software tailored to their specific business needs. Not adapted or configured to sort-of-fit. Actually built for them.
You could own your process instead of renting someone else’s. Control your future instead of waiting for a vendor’s roadmap. Stop paying the integration tax on systems that were never designed to work together.
Custom software used to be a luxury for enterprises with deep pockets. Now it’s becoming an option for any organization willing to invest in understanding what they actually need.
The Practitioner’s Advantage
For anyone building software today, this is the part that matters.
The practitioners who developed judgment and discernment, who learned to recognize quality, to make good tradeoffs, to design systems that last? Those practitioners now have leverage they never had before.
The AI doesn’t have that discernment. It doesn’t know what good looks like for your specific context. It doesn’t understand your organization’s constraints, your users’ real needs, your system’s history.
But it can execute at scale once someone with judgment points it in the right direction.
This is why the “AI replaces developers” narrative misses the point. AI replaces typing. It doesn’t replace judgment. And judgment is what separates craft from commodity.
The developers who spent years learning what good looks like? They’re not obsolete. They’re finally able to deliver what they always knew was possible.
The Window
I don’t know how long this window stays open. The economics of software are shifting fast. Organizations that recognize this moment, that pair experienced practitioners with AI tooling and point them at problems worth solving, will build things their competitors can’t match.
Not because the AI is better. The AI is available to everyone.
Because custom software is back. And now it’s fast.
The best software I’ve ever seen wasn’t the most sophisticated. It was the most considered. Every decision reflected understanding of the problem, the people, and the long game. That kind of work used to be rare because it was slow. It doesn’t have to be anymore.