Personal software with AI: from one person to a company

Personal software is a tool built for one person's exact need, with none of the features a mass-market product adds to serve everyone else. One reference for the idea is Lee Robinson's essay Personal Software (January 2025). Wanting to track how his baby slept and ate, he saw no need for user profiles, badges or subscription tiers, and asked why not build that software himself. He compared writing software with AI to cooking at home, where the result fits your taste even when a restaurant would plate it better. The usual examples stay at that scale, such as a migraine tracker or a script that replaces one subscription. Volanea's guide (August 2026) stretches the definition to “one person, household, team, or workflow”, so the software can fit a team's data and habits as well as one person's. The term also names consumer suites sold to individuals, such as Microsoft 365 Personal, a different sense from software someone builds for their own need.

AI coding tools made personal software practical when they started producing working code for people who never learned to program. David Pierce's feature for The Verge, as Roger Wong relays it (rogerwong.me, May 2026), dates that threshold to late 2025, when an update to Claude Code made a failure the surprise rather than a success. Before it, building a tool meant learning to program and finding a host, and the cost only paid off for software sold to thousands of buyers. Claude Code, Cursor and Replit cut that cost to what Wong calls something a normal person can do over a weekend: describing what you want and correcting what comes back. At that price a tool for one user is worth making, and the people making such tools are founders replacing a spreadsheet or teams tired of waiting for their SaaS vendor to ship a missing field.

Personal software does not have to be built from scratch: David Pierce came to that conclusion, and Roger Wong reads it as bending the tools people already use an inch closer to how they work. Volanea's guide counts the extension of an app that already exists among the jobs a coding agent does well.

Personal software breaks when it needs fixing months later, when a second person relies on it, or when the data inside it starts to matter. The Hacker News discussion of Lee Robinson's essay (February 2025) keeps returning to upkeep. Commenters doubt that people who did not write the code can debug it. One commenter, who built a project manager with Cursor, says their team is starting to roll their other AI-built tools into the team's standard workflows: that is the point where a personal tool acquires users it was never built for. David Pierce of The Verge, as Roger Wong relays it, abandoned one of his apps, forgot what another one did, and got stuck on Twilio bills. Volanea's guide spends a whole section on security for small apps, because generated access rules can look correct and still leave data exposed.

One person can live with a tool that fails without warning. A team that relies on it needs roles, an admin screen, validation on every write, and a way to change the data model without losing records.

Company-shaped software is personal software whose “person” is a firm: it fits one company's objects, vocabulary and rules, and the people who work there use it every day. For a twenty-person firm, that means its own deal stages and its own support queue, held in records the whole team shares. The essays and guides that define personal software stop at one person, a household or a small team sharing one app. None says what changes when a firm's roles and agents share those records. A coding agent writes the visible part well: a cron job, a pricing rule, a public page. It writes the layer behind them badly, from the tables and migrations to the admin screen, its authentication and the permissions. Each prompt you send rebuilds a slice of that layer, and the Standards vibecoding guide names it as the place where vibecoded apps rot. Standards takes that layer out of the prompts: your company declares it once, and the agent writes only the code around it.

Standards gives a company the layer coding agents write badly (tables, validation, permissions, admin screens) from one TypeScript file: you declare your objects (deals, orders, incidents) and their attributes, call bundles.sync, and your workspace serves each object five ways. Nothing is generated into your repository, and the workspace is the backend, as the Why Standards page of the docs puts it. One declaration gives you the following, as the docs describe it in October 2026.

Standards runs its own tools this way. The model catalogue every Standards deployment reads at boot has 42 attributes, 10 view tabs and two work queues, and its repository has no admin component (Vibecoding on Standards, October 2026). The developer page shows how your own apps read and write the same objects with @standards/client.

In Standards, your code owns what it declares, the people you allow to change the workspace own what they add in the app, and your agents work inside the permissions of the person they act for. With that split, the software still fits the company months after launch, because the people who use it keep changing it. The docs call the objects and attributes your code declares system: your sync writes them, and in the app nobody can rename, retype or delete them. The ones people create in the app are runtime, and every sync keeps them. When an operations lead with that right adds a “resolved at” date to your incidents object and saves a filtered tab on it, both survive the next sync. When the same question comes up every week, that lead builds a tab for it, and the vibecoding guide shows a kanban tab added from the tab menu without anyone opening the repository. The rules, from How it works:

Agents follow the same rule as people. The SDK, the CLI and the MCP server call one API, and an agent acts with its own role intersected with the roles of the person it works for, according to the security and hosting page of the docs.

Standards does not remove the need for someone who writes code: the schema is TypeScript, and a developer, or a coding agent that a developer reviews, writes and syncs it. People allowed to change the workspace can create objects and views in the app without code, but the company-shaped part described here starts in a repository. Standards also hosts the backend for you by default, on api.standards.new: your code calls it from a server, and the client refuses an API key placed in browser code. A firm that needs isolation can ask for a dedicated instance, which Standards runs on servers reserved for it under its own hostname; one that needs its data on its own machines takes a licence to run Standards there. Standards publishes no price list and gives prices in the first conversation with the team.

If you leave, the schema stays in your repository, every record can be read 1000 at a time with all(), and export() downloads any query as CSV. The same move from one person to a company, applied to notes and memory, is in the Standards article on the company second brain.