The Era of Personalized Software
It started over Saturday breakfast.
My husband Rahul and I had been frustrated with book management apps—too social, too gamified, ads everywhere. None of them fit how we actually live with books. So we sketched out what we wanted instead. By Sunday evening, he'd shipped the app to the App Store. Barcode scanning, iCloud sync, lending tracking. A real app, not a prototype.
That same weekend, I built a reading system MCP server in three hours. Something that understands why I'm reading, not just what.
A year ago, we couldn't have collaborated like this. He spoke TypeScript; I spoke research buried under math and experimentation. The translation cost was too high. Now we both speak in terms of problems, architecture, success criteria, feature selection, scope creep. The implementation layer became something you describe, not something you wrestle with.
Everyone's a builder now
I see this everywhere. Product designers shipping tools their engineering teams deprioritized. Researchers prototyping systems instead of writing specs. Lutke built an MRI viewer to navigate his own medical scans. Jane Wong built a DNA analysis tool that cross-referenced her genome against NIH databases.
These aren't side projects waiting to scale. They solve exactly one person's problem, and that's enough.
Three eras
We've moved through phases.
Paid software gave us general-purpose tools for the average user. You adapted to the software.
Open source promised customization, but every modification was a maintenance burden. Fork it, and you own it forever.
Now: personalized software. Building for one.
Someone said what YouTube did to video, Claude Code is doing to software. The barrier isn't skill anymore—it's whether you have something worth building.
We're entering the long tail of software. Millions of small tools, each solving one person's problem. Lutke's MRI viewer doesn't need to scale. My reading system fits my reading life. Rahul's book app solves our specific frustration. None of these need to grow. They're already complete.
The thinking moved
When implementation isn't the bottleneck, you spend more time on the problem itself. What exactly am I solving? What's the right shape? What should I cut?
If your vision is clear—problem statement, architecture, success criteria—execution follows. You write it down systematically, and the system builds it.
This is what markdown-driven development actually means. Not a shortcut. A shift in where the work happens.
Compressed loops
The old cycle: have an idea, spend weeks implementing it, discover it doesn't work.
Now: build it in hours, see if it resonates. Try a different approach. Decide where to invest based on what you've made, not what you've imagined.
You don't commit before testing.
The freedom to discard
This changes your relationship to ideas.
When building is expensive, you over-invest. You refine before you start. Sunk cost kicks in.
When building is cheap, you can scrap and rebuild without grief. Craft dissociates from effort. If something isn't working, you move on.
The reading system I shipped isn't what I imagined at the start. It shaped itself through building.
What matters now
The question used to be: do you have the skills?
Now: do you have the clarity to know what you want?
Problem-solving. Taste. Judgment. Understanding your own needs well enough to solve them.
Anyone with a clear problem and the willingness to start is a builder now.