I recently heard the word selfware from Alex, a great colleague of mine, and I was instantly triggered. It’s one of those rare words that arrives and immediately snaps a bunch of loose observations into place. Because it named something I’d been watching happen in my day-to-day work without quite having a label for it.

Once the term fell into place, I started digging into it. And that turned into a real rabbit hole, this blog is the result.

So I wanted to write about it. Not because I invented the idea, I didn’t, but because that single word connected the dots between things I keep seeing: the software that never quite fits, the AI tools quietly changing who gets to build, and a slow shift in who’s really in control of the tools we work with every day. This blog is my attempt to pull those threads together.

Think about the software you use every day. Your expense tool. Your CRM. Your project tracker. Your note app.

Now count how much of it you actually use. Ten percent? Twenty? The rest is features built for someone else, workflows designed around someone else’s business model, buttons you’ll never press.

We’ve accepted this for decades. Software is something that happens to you. A large company somewhere decides what you need, ships it to millions of people at once, and you bend your workflow to fit their product. You’re not a maker. You’re a user, a consumer of other people’s visions of how your work should go.

That deal is starting to look strange. And a new word is forming around the alternative: selfware, software built by you, for you. Not a generic product stretched to almost cover your case, but a tool shaped to the exact contour of your problem.

I think this is a real trend, not a gimmick. And like most real trends, it’s arriving faster than the industry is ready to admit.

The clearest manifesto for the term lives at selfware.md, where it’s defined as: "Software built by you, for you." The pitch is that for the first time in history you can build exactly what you need, in hours instead of months, in conversation instead of a coding bootcamp.

The core promise is worth quoting: "The software fits your brain like a glove. No unnecessary features. No dark patterns. Every button exists because you put it there."

That’s the whole idea in three sentences. Selfware isn’t about scale. It isn’t a startup. It doesn’t need a market. It just has to solve your problem better than the general-purpose product that was never really built for you in the first place.

If this sounds new, it isn’t, not entirely. It’s the latest name for an idea that’s been circling for twenty years, waiting for the tools to catch up.

In 2004, Clay Shirky wrote about situated software, applications "designed in and for a particular social situation or context." Software for dozens of people, not millions. It was a lovely idea and completely impractical at the time. Building anything real was simply too expensive to justify for a handful of users.

Sixteen years later, Robin Sloan wrote a piece that hit a nerve across the whole industry: An app can be a home-cooked meal. He’d built a tiny app just for his family, to send each other short videos. No commercial value. No plan to scale. Made out of care, the way you’d cook a meal for people you love.

Maggie Appleton picked up the thread in her talk Home-Cooked Software and Barefoot Developers, and put her finger on why industrial software feels so ill-fitting. Big software can only afford to solve "the most common needs of the most number of users." Everything else, the real problems that only a few people have, never gets built. Google Maps will never show you the flattest cycling route that avoids every hill, or which streets flood when it rains. A few hundred people might need it, but a few hundred people is not a business case. As she puts it, industrial software is "made for us by people who don’t know much about us."

That’s the gap selfware lives in. Not the common case that SaaS already serves well, but the specific, the peculiar, the exactly-what-you-need corners of your own working life.

For twenty years that gap stayed empty for one boring reason: the people who could build home-cooked software and the people who were professional developers were essentially the same small circle. Everyone else hit what Appleton calls the command line wall and turned back.

The AI movement is the missing ingredient.

Here’s where selfware stops being a nice essay and starts being a trend.

Every version of this idea, from Shirky to Sloan to Appleton, ran into the same problem: building software is hard, and experts are expensive. That was the whole constraint. Remove it, and the economics of small, specific software flip completely.

AI coding assistants remove it.

Andrej Karpathy’s quote stopped being a provocation and became a description. You describe what you need, the code materializes, you refine it in a conversation. The skill floor that kept regular people out for forty years has dropped through the floor.

Appleton’s term for the people who walk through that door is barefoot developers, a nod to China’s barefoot doctors of the 1960s: not fully trained physicians, but locals given just enough capability to serve their own communities. The developer version is the teacher who builds an elaborate class tracker, the ops lead who wires up a dashboard, the analyst pushing a spreadsheet past its limits. People who understand a problem intimately because they live inside it, now able to build the tool that fixes it.

This is the part I find genuinely exciting. The advantage isn’t that AI writes code faster. It’s that it hands the tool to the person with the most context, the one who actually feels the friction, instead of routing the problem through a product owner at some faraway tech company trying to understand your job over a Zoom call.

Now the part most people miss. Selfware doesn’t just change who builds software. It breaks the traditional software lifecycle, and that matters, because the lifecycle is how our whole industry is organized.

Think about how traditional software lives and dies. You gather requirements. You design. You build. You test. You deploy. Then comes the long, quiet stretch afterward, maintenance, patching, migrations, and eventually end-of-life, when the vendor sunsets the product or the contract lapses and you have to migrate. Every stage assumes software is expensive to make, so it must be made to last, maintained carefully, and amortized over years.

Selfware quietly demolishes that assumption. When creating and changing software approaches zero marginal cost, several stages of the lifecycle collapse.

Requirements stop being a document handed to someone else and become a running conversation with the thing you’re building. Maintenance stops meaning "keep the old code alive" and starts meaning "regenerate it when your needs change." Software becomes less like a building you maintain and more like a meal you cook again when you’re hungry. Disposable in the best sense, cheap enough to throw away and remake rather than defend forever.

And the vendor lifecycle, the part where someone else’s roadmap decides your fate, largely disappears. This is the piece that connects directly to the sovereignty argument. Appleton warns of a future where barefoot developers build wonderful local tools but rent them from the cloud, until "the terms of service change…​ the subscription fee doubles. And it turns out what they’ve built was never actually theirs all along." Selfware, done right, is software you own outright. Full source, running on hardware you control, no roadmap but yours, no end-of-life but the one you choose. It’s digital sovereignty scaled all the way down to the individual.

Let’s be honest about the flip side. A lifecycle exists for reasons. Testing, documentation, security review, and maintenance aren’t bureaucracy for its own sake, they’re what stops software from quietly failing in ways that matter. Home-cooked code handling your family photos is one thing. Home-cooked code handling patient records or payroll is another. The lifecycle didn’t vanish because you stopped doing it. It just moved onto your plate.

None of this is lost on the industry, which is why the trade press has spent 2026 arguing about it.

The headlines tell the story. Forbes calls it the end of one-size-fits-all software, while others ask whether AI is the end of SaaS as we know it or point to a coming era of malleable software, where products bend to the user instead of the other way around.

The case for the end of SaaS is strong: when changing software becomes cheaper than distributing standardized products, the SaaS model destabilizes its own foundation. Why rent a bloated general tool when a custom one costs an afternoon?

The other side deserves equal airtime, because I don’t think SaaS simply dies. Most vendors will pivot to selling AI agents rather than seats. Plenty of software is genuinely hard: security, scale, compliance, integrations. And you do not want to home-cook your bank’s core ledger. What’s more likely than the death of SaaS is a split: commodity and personal workflows move to selfware, while the genuinely hard, high-stakes, shared infrastructure stays professional. What’s actually at risk is the middle: the many average tools that only exist because building your own used to be too expensive.

If you’re tempted, and you should be, here’s how I’d approach selfware without getting burned.

Start where the stakes are low and the fit is bad. Your personal dashboards, your repetitive glue work, the internal tool nobody in the market will ever build for you. This is the land of opportunity, and it’s also where a rough first version costs you nothing.

Match the ambition to your capability, honestly. Here’s where I want to be careful, because as a software engineer I see both sides of this. The opportunity is real: anyone can now start building. But starting and succeeding are two different things. AI hands you the Lego bricks, but as Appleton notes, "language model legos need glue." Getting to a first version is easy. Keeping it running, deploying it, securing it, backing it up, storing data safely, and not quietly leaking that data, is still real engineering. That gap between "it works on my machine" and "it holds up in the real world" is exactly where our craft lives, and AI hasn’t closed it. So the door is open to everyone, but walking through it still takes skill. If you don’t have those skills yet, keep your selfware small and local, and leave the load-bearing systems to professionals for now.

Build for ownership from day one. If your home-cooked tool ends up trapped in someone else’s cloud on a subscription that can double overnight, you’ve just rebuilt the trap you were escaping. Keep the source. Keep it portable. Keep an exit.

And be clear-eyed about the lifecycle you’re taking on. When you build it yourself, you own the maintenance, the security, and the end-of-life too. Sometimes that trade is obviously worth it. Sometimes buying the one-size-fits-all product is the smart, sovereign choice. The point isn’t to build everything yourself. It’s to make it a decision instead of a default.

The question is no longer "which product should I adopt and adapt to?" It’s becoming "which of my problems can I afford to solve myself?"

For the specific, the peculiar, the exactly-what-you-need, the answer is increasingly: build it. It’ll fit like a glove, because you’re the one putting every button where it belongs.

Michael Jordan said it better than any technologist could:

Selfware is simply the moment when making it happen stopped being reserved for the few. The tools are here.