The Re-Rise of Remix Culture
Personal software is an audience-of-one story. What happens after that is more interesting.
Earlier this year I was on a call with Rob, a software engineer I work with at Amdocs. We'd gotten sidetracked from the actual agenda, as we usually do, and he said something that reframed a lot of what I'd been thinking about.
"It's like taking SaaS as a principle, but applying it to one-to-one instead of one-to-many."
He was reacting to Margin, a desktop reading and annotation app I've been building for myself using Tauri and React. The app doesn't have to scale. There's no pricing page. It just needs to work for me and how I take notes when I read.
Rob has been doing a smaller version of this since college, self-contained scripts for his own workflow, and saw in Margin a more visible form of the pattern. Software built to solve one specific person's problem, with no ambition to generalize.
We kept going. I mentioned I planned to open-source Margin once it was stable, not for traction, but because someone might want the interesting parts and adapt them to their use. Rob was immediately on it. "The best beer I ever had was one someone bought for me through software." He meant it literally. An automated gift purchase, software acting as a proxy for a thoughtful act. But the image works as a metaphor for what a well-remixed tool feels like. Someone else built it for their needs. You forked it and made it yours. It fits the way something made for you fits.
That chain — build for yourself, open-source, remix — is worth thinking through.
SaaS averaging
Commercial software is optimized for the middle. A product team builds for what most users need most of the time, ships it to everyone, and iterates based on the loudest signals from the most common use case. It's rational. Building software used to be expensive, expensive tools need large addressable markets, and large markets mean averaging across wildly different users.
Most knowledge workers spend their days adapting to software designed for a version of them that doesn't quite exist. The CRM has the fields someone else needed. The project management tool runs the workflow someone else designed. You bend your practice to fit the tool because changing the tool isn't on the table.
Personal software rejects that constraint. When the cost of building drops far enough, you stop needing ten thousand users to justify the investment. You need one. Your specific needs stop being a problem to work around. They become the specification.
Permissionless building
The thing that unlocked personal software isn't just lower cost. A colleague of mine, Anne, who runs an AI center of excellence, put a sharper frame on it recently: "permissionless technology." You don't need an engineer to code your idea or a designer to design it. You can build something for yourself without asking anyone for permission.
Cost reduction means less friction. Permissionless means a different population of people can build. Those aren't the same shift.
Anne pointed out the early web had the same energy. Geocities pages, calendar widgets, hit counters, "under construction" GIFs. Anyone with a browser and an afternoon could make something that was distinctly theirs. Kate on the Rosenberg Review called it "an exciting time for makers." Same sentiment, 25 years apart.
Her most useful parallel was research democratization. User testing used to require a research coordinator, a lab, a recruiter, scheduling across three stakeholders. Then tools lowered the bar. Lightweight testing platforms, automated transcription, synthesis tools. A PM who would have needed to request a research project can now run synthesis herself in an afternoon. The gating function didn't improve. It disappeared.
AI-assisted development does the same thing for software. The gating function was "can you write code?" That gate still exists, but it's lower. Low enough that Alex, a designer at a session I run for people building with AI tools, shipped a working full-stack app with a database, API integration, and conversational interface in eight hours. For herself. For her specific taste in book recommendations.
Anne's concern was worth naming too. As tools get easier, the risk is people build without understanding what they're building. The low barrier enables volume, not quality. The critical thinking that used to be forced by friction has to be chosen deliberately. That tension doesn't invalidate permissionless building. It just means the bar for what you build shifts from "can I?" to "should I, and why?"
One to one
Building for yourself changes the decisions you make. You skip onboarding flows. You skip preference panels. You can make the tool work the way your brain works, then stop.
Rob's framing stuck because it captures both the opportunity and the constraint. Personal software delivers higher fidelity to the person who built it. Lower fidelity to everyone else. That trade-off is only worth making when your own needs are unusual enough that no existing tool fits well.
Margin exists because I worked through Readwise Reader, Obsidian, Bear, and a half-dozen annotation tools and none of them captured what I wanted to do in the margins of a text. Reader is the closest. But I wanted something different enough that building started making more sense than adapting.
Personal software gets built mostly out of frustration with the available options. The commercial alternatives got close and didn't close.
After you build for yourself
Personal software rarely ships with extension hooks or contributor documentation. There's no plugin architecture, no stable API for others to build on. But unlike a SaaS product, the source code can live on GitHub. Someone else can read it, fork it, and build something new.
That's remix culture. And it's older than software.
Music has had this pattern for decades. Producers sample. DJs remix. Bootleg mashups circulate on forums and eventually influence the mainstream. Creative Commons licenses formalized what people were already doing, taking something someone made and building something new from it. Open-source software has always worked similarly. Libraries get forked. Personal tools get adapted. The original sometimes goes quiet while the forks persist.
What's changing is who can participate. When personal software was limited to dotfiles and shell scripts that only engineers could create, the remix surface was small. Only developers could meaningfully fork a developer's personal tool. AI-assisted development changes who can build, which changes who can remix.
If I open-source Margin and someone who reads constantly but doesn't write code wants the core of it adapted to their workflow, they have real options. They can describe what they want to an AI assistant and get most of the way there. The fork doesn't require deep fluency in Rust or React. It requires judgment about what they want the tool to do.
In practice
My own experience with this runs in both directions.
On the building side, Margin is assembled partly from patterns I found in open-source tools. The sidenote layout on this site borrows from Tufte-style implementations I found and modified. Claude Code skills (modular slash commands that extend Claude Code's behavior to fit a specific workflow) circulate in a shared directory where people fork and customize them. I've taken someone else's skill scaffold and reshaped it for how I work. The original author gets a fork they didn't ask for. Sometimes it feeds back improvements. Usually it just diverges quietly.
On the remixing side, my reading setup uses Readwise Reader and Granola in ways their builders probably didn't anticipate. I pipe Granola meeting transcripts into Claude Code to draft articles. I've built automations around Readwise's API for morning briefings and review queues. I didn't build those tools. I remixed them into a workflow that fits how I operate.
Best case, the original and the forks push each other. Someone builds a tool that solves their problem. Others fork it, solve their problems, and open-source those. Patterns emerge across forks that inform the next version of the original. It compounds slowly, but it compounds.
Legible code
A public license is a start. What makes a personal tool remixable is whether its code is legible enough for a stranger to read and modify with confidence.
Personal tools are often written quickly, for one maintainer, with no assumption that anyone else will ever touch them. That works fine until someone tries to fork. Then the implicit decisions become walls.
Writing legible personal code is a different discipline than writing production code. Closer to writing prose meant to be quoted. Functional enough that a stranger can understand it well enough to change it.
This is something I'm trying to get right with Margin before I release it. Not every function needs a comment. But the architecture should be readable enough that someone with a different use case can find the parts they want and understand what they're doing before they change anything. Named things clearly. Modules with obvious responsibilities. No sprawl that would force a reader to reverse-engineer intent from behavior.
The legibility work is mostly invisible to the person who wrote the code. It only shows up when someone else arrives.
Where it goes from here
Remix culture will grow as the base of personal software builders expands. The more interesting question is what forms it takes.
One version is the commons model, a shared directory where people contribute and fork composable pieces. Claude Code's skills system is an early example. Less a commercial product than a shared toolkit, maintained by whoever needs it maintained.
Another is the dispersed model that open source has always had. Small repos accumulate a handful of forks, mostly quiet, occasionally producing something unexpected. Less coordinated, but more durable.
Both work. The commons model is faster for distribution. The dispersed model is better for longevity. Personal software probably needs both running in parallel.
What I keep coming back to from the Rob conversation, reinforced by Anne's "permissionless" framing, is the chain. SaaS made software accessible. Install nothing, just use it. Personal software made it personal. Remix culture closes the loop. Start from what someone else made for themselves, then make it yours.
This pattern runs through every era of the open web, from Geocities templates to GitHub forks. Each time, the tools get easier and a new wave of people gets to participate. We're in one of those waves now.