Every vibe-coded project sits on one side of a simple boundary: either the software holds only its builder's data, or it holds someone else's. On the personal side, the worst case of a bug is lost time. Across the line, the same bug becomes a breach that lands on people who never agreed to take the risk.

The boundary matters because it demands zero technical judgment. Nobody can eyeball generated code for vulnerabilities without training, but anyone can answer one question: whose data is in the box? That single question separates projects worth building freely from ones that call for caution, review, and a different level of accountability.

This lesson traces the line from its home-cooked-software roots through the breach reports that show what crossing it costs, and ends with the honest debate over whether the line empowers new builders or holds them back.

What is the personal-tool line?

What is the personal-tool line?

The personal-tool line is the boundary between software that holds only the builder's own data and software that holds other people's. On the near side, a bug costs the builder wasted time and nothing more. On the far side, the same bug can expose strangers' names, messages, or money, so the stakes change even when the code doesn't.

Simon Willison drew the boundary for beginners in plain terms: "Think about how much harm the code you are writing could cause if it has bugs or security vulnerabilities." [1] His guidance singles out one factor above everything else, whether the software will be used by, and collect data from, other people.

The line earns its place because it asks nothing technical. Complexity is invisible to a non-coder, but whose data sits inside an app is always knowable. A question that needs zero code literacy can be applied on day one, on any tool, which makes it the most load-bearing safety heuristic in vibe coding.

Home-cooked software stays home

Long before vibe coding, writers described software built for a household rather than a market. Clay Shirky called it "situated software" in 2004, apps designed for dozens of users, not thousands [2]. Robin Sloan named its modern form in 2020 with BoopSnoop, a messaging app built for exactly 4 people: "I made a messaging app for, and with, my family. It is ruthlessly simple; we love it; no one else will ever use it." [3]

Maggie Appleton carried the idea into the AI era: "Home-cooked apps, like meals, are apps you make for the people you know and love." [4] Her collected examples include a newborn diaper tracker, a personal-finance reconciler, and a custom glucose-monitor interface built for a diabetic partner, all handling intensely private data.

These apps stay safe not because they're simple but because the data never belongs to strangers. A family's messages and a partner's glucose readings remain inside the circle of people who already share them, so a bug is an inconvenience, not a breach.

Willison's low-stakes rule

Willison's rule for beginners is blunt: projects should be low stakes. Before building, the question to weigh is how much harm the code could cause if it has bugs or security vulnerabilities, and whether anyone could lose money, reputation, or something worse [5].

The rule covers data privacy even on the personal side of the line. Willison cautions that pasting private information into a vibe-coded tool demands real care: "you need to be very sure you understand if there are ways that data might leave your machine." A tool can hold only its builder's data and still leak it outward through an unnoticed network call.

For anything headed beyond a single builder, he adds a concrete gate: "I recommend checking in with someone more experienced for a vibe check (hah) before you share it with the world." The rule isn't a ban on sharing; it's a checkpoint that puts one experienced pair of eyes wherever the stakes rise.

When apps cross the line

An app crosses the personal-tool line the moment it starts holding data that belongs to someone else. Sign-up forms, login accounts, and stored messages are the usual markers; each one means a stranger's information now lives inside code its builder can't fully inspect.

The crossing used to announce itself. Wiring up accounts, databases, and payments once demanded skills that naturally stopped beginners at the boundary. On modern platforms, adding user accounts takes a single prompt, so the friction that once enforced the line is gone and judgment has to replace it.

Nothing about the app has to look different on the far side. The interface stays the same, the features seem to work, and the builder's own experience of the tool is unchanged. What changes is invisible: someone else now bears the cost of the builder's bugs.

Pro Tip! Sharing read-only output, like a chart or a static page, stays on the near side of the line; collecting anything from viewers crosses it.

MenuGen, Andrej Karpathy's menu-photo app, is the best-documented crossing of the line, because the person crossing it coined the term vibe coding. As a demo on his own machine, the build felt "exhilarating and fun." Once the app gained real users, sign-ups, and payments, it became "a bit of a painful slog" [6].

The slog didn't come from the app's core feature, which worked early. It came from everything the far side demands: authentication, payment matching bugs, and security configuration. The hard parts began at exactly the moment other people's accounts and money entered the system.

Karpathy's verdict carries weight because of who reached it: "Ultimately, vibe coding full web apps today is kind of messy and not a good idea for anything of actual importance." The field's most enthusiastic voice drew its boundary from direct experience.

The user-count fallacy

A small audience feels like a small risk, but stakes scale with data sensitivity, not headcount. The instinct comes from risk intuitions calibrated on audiences, where the harm of a mistake grows with reach. Stored data doesn't work that way; a single leaked ID photo is enough for identity theft, no matter how few people ever used the app.

The Tea app breach of 2025 made the point at scale. As reported, the women's-safety app exposed roughly 72,000 images through an unsecured storage bucket, including about 13,000 selfies and government IDs, while a second flaw exposed 1.1 million private messages on topics as sensitive as abortion. The worst harm was per person; each exposed ID belonged to one individual whose risk didn't depend on how many others were affected.

Later reporting established that the vulnerable code predated the vibe-coding era, so the breach isn't evidence of what AI-generated code did. It's evidence of what crossing the line risks: unreviewed code holding strangers' data fails the same way whether a rushed human or an unreviewed AI wrote it.

The wallet as a line

Other people's data marks the main boundary, but a second one runs alongside it: the builder's own money. Connecting a vibe-coded project to a usage-billed service, such as an image API or a model endpoint, puts real spending under the control of code nobody reviewed.

Willison reports the failure mode directly: "I've seen horror stories about people who vibe coded a feature against some API without a billing limit and racked up thousands of dollars in charges" [7]. A bug that would cost only time in a free tool becomes a four-figure invoice when it loops against a metered service.

This is why sandboxed platforms earn their place for shareable toys. Environments like Claude Artifacts run in a locked-down frame with no external network calls, which Willison praises for making it "very difficult for people to mess up and cause any harm." The safest first shared project is one where neither strangers' data nor anyone's wallet is reachable.

Pro Tip! A hard billing limit on every connected API turns a runaway bug into a capped experiment instead of an open-ended bill.

Does the platform protect builders?

The most tempting belief on the far side of the line is that the platform handles security. Audits say otherwise. Security researchers Matt Palmer and Kody Low analyzed 1,645 apps built on Lovable and reported that 170 of them, about one in ten, leaked user data such as names, emails, and API keys [8]. As reported, the root cause was missing or misconfigured database security rules that novice builders couldn't see, and the platform's first security scanner checked only whether rules existed, not whether they worked.

There's a serious counter-position. Vercel's Guillermo Rauch argues that "the antidote for mistakes AIs make is... more AI," pointing to secure-by-default generation that prevented more than 16,000 token leaks [9]. He's partly right; platform defaults are the highest-leverage fix at scale, and the trajectory is real.

The catch is coverage. Fixes arrive unevenly across platforms, and none of them yet removes the builder's accountability for other people's data. A heuristic anyone can apply today, on any tool, beats a promise about a platform roadmap.

Line or gatekeeping?

If vibe coding's promise is that anyone can build, a rule that tells beginners to keep to their own side of a boundary can sound like gatekeeping. The sources behind the line reject that reading. Willison frames the whole project as empowerment: "I believe everyone deserves the ability to automate tedious tasks in their lives with computers" [10]. The line exists to protect the golden age of personal software, not to gate it, and security headlines shouldn't scare anyone out of building for themselves.

The line is also a today heuristic, not a ceiling. Maggie Appleton's barefoot developers are expected to serve whole communities eventually, as local-first infrastructure and safer defaults mature [11]. Willison expects some vibe coders "will get bitten by the programming bug and go on to become proficient software developers." Crossing the line is a graduation with a path, not a trespass.

One stretch of the boundary stays genuinely fuzzy: family and friends. Sloan's 4-person app holds other people's data, his family's messages, and is plainly fine; a 200-person community tool is plainly not. No authority has drawn that middle line precisely, which calls for judgment rather than paralysis.

Pro Tip! People who can yell at the builder across the dinner table can consent to being beta testers; strangers can't.