{
  "id": 9847608,
  "title": "What breaks when AI apps go live",
  "url": "https://urgent.news/2026/09/25/what-breaks-when-ai-apps-go-live",
  "topic": "ai",
  "section": "AI",
  "published": "2026-09-25T22:03:13.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/gemmein/what-breaks-when-ai-apps-go-live-5db3"
  },
  "original_language": "en",
  "account": "When developers launch artificial intelligence applications, several common issues can cause the software to malfunction and break. According to research gathered from 59 verified reports, the majority of failures occur in four primary areas: sign-in and session management, access rules that grant unintended access to data, access rules that prevent legitimate users from accessing their own information, and payment webhooks that fail to trigger the correct access permissions.\n\nThe first issue, sign-in and session problems, occurs when users cannot complete the sign-up or login process. This can manifest as failed or delayed reset or email links, users being logged out when they think they are still signed in, paying customers losing access to their accounts, or tokens being refreshed mid-session. The root cause is often that the various components involved in the sign-in flow, such as email delivery, redirect origins, cookie attributes, and token rotation, are not tested properly in a production environment. To fix these issues, developers should thoroughly test the entire sign-in flow on the production domain using a fresh inbox and a second browser, verify cookie settings and redirect allow-lists, enable SPF and DKIM on the sending domain, and ensure token refresh is handled in a single-flight manner with proper logging of all authentication failures.\n\nThe second common problem involves access rules that allow one user to access another user's data. This can manifest as users accidentally reading, modifying, or deleting someone else's records through the public API, anonymous visitors being able to write to paying customers' records, or new accounts elevating themselves to admin privileges. The issue typically arises because database keys are handed to the browser without proper row-level security measures in place. Developers can prevent this by turning on row-level security for all exposed tables in the database, writing separate policies for select, insert, update, and delete operations that check ownership, and ensuring roles are stored in tables that cannot be edited by the client or users. Comprehensive testing with two different accounts and an anonymous client is also recommended.\n\nThe third issue relates to access rules that unintentionally block legitimate users from accessing their own data. This can result in sign-up failures, empty results when users attempt to view their own data, or shared screens displaying the wrong records. The root cause is often that row-level security policies are missing, incorrectly configured, or allow unauthorized access. Developers should ensure that per-user rows are created through server-side triggers rather than client-side operations, write policies for each specific operation (select, insert, update, delete), and test the real error messages rather than assuming an empty array indicates a problem. Adding a two-account test to the continuous integration pipeline can also help catch these issues early.\n\nThe final common problem is when the entire authentication and data backend simultaneously goes down. This can cause all sign-in, data reads, and file loads to fail at the same time, leaving customers locked out of the application. This issue often stems from the fact that authentication, database, and storage components are tightly coupled within a single project and dependency path. Problems can arise from exhausted quotas, paused projects, expired or missing environment variables, upstream incidents, or inadequate monitoring and alerting. To mitigate this issue, developers should implement an external uptime check that monitors sign-in and a critical data read, store all keys and environment configuration in a single location and verify them after every deployment, familiarize themselves with their provider's plan limits and pause procedures, and display clear error messages to users when the outage occurs.",
  "summary": "This is a living report. The current numbers and method are at research.gemmein.com , updated daily. We grouped 59 recent, verified reports from builders whose apps broke near or after launch. Most failures fall in a few places: sign-in, hand-written access rules, file storage and payment webhooks. We read 4,469 public builder posts, judged 916 of them against a fixed definition of \"stuck going…",
  "key_points": [
    "Sign-in and session management issues cause failures in AI apps",
    "Access rules allow unintended data access for users",
    "Payment webhooks fail to trigger proper access permissions"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}