The pattern isn't difficulty — it's who bears the risk
Most of what this register marks JUST PAY isn't there because the code is hard — the real moats are usually something else entirely. But a smaller, more specific group of apps gets a different kind of warning, one that shows up in the reasoning again and again regardless of how buildable the underlying features actually are: not 'this is difficult,' but 'you shouldn't be the one bearing this risk.' Five categories account for nearly all of it.
1. Payment and financial infrastructure
Stripe's own review is blunt about this: PCI compliance, banking partnerships, and fraud detection at real scale are regulated financial infrastructure individual developers cannot legally or practically replicate. The same reasoning covers Wealthfront and Robinhood — being a registered investment advisor or executing real trades requires licensing no amount of good code substitutes for. What's genuinely worth building instead: the checkout flow, the orders table, the webhook handling around an established processor. That's a real, achievable weekend project, and it's what this register's own build prompts recommend constantly. The processor itself was never on the table.
2. Applied cryptography
1Password's review puts it as plainly as anything on this register: this is the one category where 'buildable in a weekend' is a warning label, not a recommendation. A password manager is a security product first and a CRUD app a distant second. Get the cryptography wrong and you don't have a bug — you have every password you own exposed at once. A toy vault using an established encryption library, clearly labeled and never used for a real credential, is a genuinely good way to learn the mechanics. Anything you'd actually rely on needs an established, audited product, not a personal build.
3. Identity and authentication infrastructure
There's a real, useful distinction buried in how this register treats Auth0 and Okta. Adding login to your own single app, using an established library, is genuinely achievable — this register's own build prompts do exactly that throughout. Becoming the identity layer other applications trust, the way a real auth provider does, is a different, security-critical role entirely. It's the difference between locking your own front door and being hired to design the locks for an entire apartment building. One is a weekend project. The other is infrastructure most companies rightly rent.
4. Multi-tenant code execution
Replit's review draws the line precisely: a code editor in the browser is genuinely buildable. Safely running arbitrary, untrusted code from thousands of strangers, isolated from each other and from the host system, at real scale, is a different order of problem — genuine security-critical infrastructure. For a personal coding environment running your own trusted exercises, a single sandboxed container using an existing isolation tool is a real, achievable build. The moment other people's untrusted code enters the picture, the honest answer is to use a service built for exactly that problem.
5. Automated decisions with real bias or legal stakes
HireVue's review is the one entry on this register that declines a feature not because it's hard, but because it's the wrong thing to build even if it were easy. Collecting a candidate's recorded video answers is a genuinely achievable build — this register's own video-hosting spec covers it directly. Automated AI scoring of those answers to rank candidates is a different matter: it carries real, well-documented bias and fairness risks, several jurisdictions now specifically regulate it, and getting it wrong has real consequences for real people's careers. 'Technically buildable' and 'responsible to build' are different questions, and this is the clearest case on the whole register where they point in different directions.
What actually connects all five
None of these are on this list because an AI coding agent can't write the code. In most cases it genuinely can. They're here because the failure mode isn't a bug you patch and move on from — it's a compromised password vault, an unlicensed financial product, a security hole other companies' users fall through, or a biased decision about someone's livelihood. Most ideas don't carry this kind of stakes, and most of what's worth building is a real, achievable weekend project. These five categories are the specific, recurring exception, not evidence that vibe coding itself is risky.