# Vibe coding and the return of personal software

Since vibe coding became good enough to use casually, I have found myself opening a category of projects I used to leave untouched. Not research code, not serious infrastructure, not anything that needs to survive other people depending on it. I mean small front-end and client-side things: a tiny tool for a repetitive workflow, a web page that visualizes something I care about, a small game idea that would have stayed in a notebook.

These were never impossible projects. They were just too annoying to start.

The work around the actual idea was always the tax. Set up the page. Wire the buttons. Decide where state lives. Make the layout usable on a phone. Remember the exact API for drag events, local storage, canvas, CSS grid, routing, or packaging. None of this is intellectually hard, but each piece is friction, and friction is enough to kill a weekend idea before it becomes real.

Vibe coding changes the activation energy. I can describe the thing, get a working first version, inspect it, push it toward the behavior I actually want, and keep iterating. The result is not that everyone suddenly becomes a professional software engineer. The result is more interesting than that: a lot of personal software becomes worth making.

# The App Store Tax

For a long time, the default answer to "I need a simple app" was to search an app store. A timer with one unusual rule. A habit tracker that does not need social features. A vocabulary game for a specific child. A lightweight image annotator. A small puzzle to play with friends. A dashboard for some personal data.

The store is full of versions of these things. Many of them are polished enough. But the transaction often feels wrong for the scale of the need. You download something simple and get ads, tracking, notifications, subscriptions, dark patterns, account creation, cloud sync you did not ask for, or a UI optimized for monetization rather than for the tiny job you had in mind.

That bargain made sense when making the thing yourself was too expensive. It makes less sense when the thing is a few prompts and an afternoon of adjustment away.

For small software, the alternative to the App Store is no longer "become a full-stack developer and maintain a product." It can be "make the exact private object you need, run it locally, and stop there."

# Personal Software Is Not Product Software

This distinction matters. A personal tool does not need onboarding, growth loops, analytics, multi-user permissions, enterprise reliability, or a pricing page. It does not need to generalize to every possible workflow. It only needs to fit one person, one family, one lab, one habit, or one moment.

That narrower target is what makes vibe coding feel powerful. The model does not have to produce the universal best version of a todo app. It only has to produce my version: the one with the weird sorting rule, the ugly-but-useful control, the local JSON export, the keyboard shortcut I like, and no account system.

Front-end and client-side projects are especially well suited to this. They have immediate feedback. You can see what is wrong. You can click through the mistake, change the wording, move the control, simplify the state, and try again. The artifact is visible enough that iteration feels natural even when the underlying code is not something you would have written from memory.

This is also why small games are suddenly more approachable. A game does not have to compete with commercial games to be worth making. It can be a private toy: a ruleset you wanted to try, a little puzzle for a friend, a classroom demo, a party game, a tiny simulation. The value is not in distribution. The value is that it exists in the exact shape you wanted.

# The New Default

I do not think this means "everyone should vibe code everything." That would be a bad lesson. If software handles money, health, security, other people's data, or shared infrastructure, the standards are different. At that point, correctness, maintainability, review, threat modeling, and boring engineering discipline are not optional. Vibe coding is not an excuse to ship unexamined code into high-stakes settings.

But a lot of software is not high-stakes. A lot of software is a private interface over a private need. For that category, the old default was strangely passive: search, download, tolerate the ads, work around the missing feature, uninstall later. The new default can be active: sketch, generate, edit, use.

That shift feels bigger than the usual productivity framing around AI coding tools. The point is not only that programmers can move faster. The point is that the boundary of what is worth making has moved.

Small software used to be something you bought, downloaded, or gave up on. Now it can be something closer to a note, a spreadsheet, or a sketch: disposable when it should be disposable, personal when it should be personal, and free of the pressure to become a product.

That is the part of vibe coding I find most interesting. It brings back the idea that software can simply be yours.