25 Ways AI-Built Apps Break — By App Type

2 hours ago

6 min read

Patterns from Codersarts delivery across 500+ builds. Find your app type, read the failure it produces most, check for it today.

general advice about AI-built apps is broadly correct and not very actionable. Yes, database rules get left open. Yes, monitoring is missing. Fine — but a marketplace and a clinic portal fail in different ways, because what they hold and who touches it is different.

This is the specific version. Twenty-five app types, and for each, the failure that shows up most often in that category, why it's characteristic of that category, and what to check.

Find yours, then read three or four neighbours — the patterns cross over more than you'd expect.

Marketplaces and multi-sided apps

1. Two-sided marketplace — The seller dashboard queries orders filtered by seller ID in the request rather than enforced at the database. Any seller can view any other seller's order volume, customers and revenue. Competitive intelligence handed over for free, and the people most motivated to look are already on your platform.Check: log in as seller A, change the seller ID in a dashboard request.

2. Service booking (trades, cleaning, tutoring) — No locking on slot booking. Two customers who click at the same moment both get the 2pm slot, because the availability check and the write aren't atomic. Rare at low volume, weekly at scale, and every occurrence is a phone call.Check: two browsers, same slot, click simultaneously.

3. Rental / peer-to-peer lending — Uploaded ID documents and proof-of-address land in public storage with predictable filenames. Every verification document any user ever submitted is enumerable by a stranger.Check: copy an uploaded file's URL, open it in a private window.

4. Freelancer / job board — Application and message endpoints have no rate limiting, so the board fills with automated spam applications within weeks of getting any visibility. Kills the product for the employer side first.Check: submit the same form fifteen times in a row.

5. Event ticketing — Ticket quantity decremented after payment succeeds rather than reserved before. Under load you oversell, and the refund conversation is the customer's first real experience of your brand.Check: what happens between payment initiation and the stock write.

Subscription and SaaS products

6. B2B SaaS with teams — Roles enforced in the browser. The app reads role: "member" into frontend state and decides permissions from it. Editable by anyone who knows how to open devtools, which in a B2B product is a meaningful share of users.Check: does any endpoint verify the role server-side, or only the UI?

7. Usage-metered SaaS — Usage counted client-side, or counted after the work completes. Both let a user consume the resource without being billed for it, and neither shows up until someone notices margins are wrong.Check: is the meter incremented before the expensive operation, server-side?

8. Freemium tool — The paywall is a rendering condition. Premium features are in the bundle and the API serves them regardless of plan; the app just doesn't draw the button. Free users on the higher tier, invisible in your metrics.Check: does the endpoint behind a premium feature check the subscription?

9. Anything with annual plans — Failed renewals don't revoke access. A card expires eleven months in, the charge fails, nobody's watching the webhook, and the customer keeps full access indefinitely.Check: force a failed renewal in your provider's test mode.

10. Multi-tenant anything — The tenant ID comes from the request body instead of the authenticated session. Send a different tenant ID, get a different company's data. The most serious single failure on this list, and structurally common because tenant scoping is a concept nobody prompts for.Check: is tenant ID ever read from user-supplied input?

Regulated and sensitive domains

11. Clinic / patient portal — Verbose error responses echo back patient identifiers, table names and query fragments. Every failed request leaks a little. Under most health privacy regimes that's a reportable exposure regardless of whether anyone exploited it.Check: trigger an error, read what comes back in the network tab.

12. Mental health / therapy app — Session notes, journals and intake forms kept in a table with row-level security off. The highest-sensitivity data on this entire list, protected by the app asking politely.Check: RLS status on every table holding written content.

13. Legal / case management — Document storage public, or shared across matters. One client's disclosure bundle reachable from another client's URL pattern.Check: file URLs in a private window, and whether filenames are sequential.

14. Fintech dashboard / personal finance — Bank or aggregator API credentials in the frontend bundle. Found by automated scrapers within days of deploy; the consequence is not a bill, it's account access.Check: view source, search for provider key prefixes.

15. Insurance / claims — Claim status transitions with no server-side validation, so a claim can be moved to "approved" by sending the right request. The workflow exists in the interface, not in the data model.Check: can a status field be set directly through the API?

Content, community and education

16. LMS / course platform — Course content served regardless of enrolment; the app only checks before rendering the player. Video URLs and PDFs fetchable by anyone with the link, which students share.Check: request a lesson asset while logged in as a non-enrolled user.

17. Community / forum — No rate limiting on posting or signup, plus no moderation queue. The product's viability depends on content quality and there's no mechanism protecting it.Check: how many accounts can be created from one IP in a minute.

18. Newsletter / publishing — Subscriber list readable through an unprotected endpoint, or the unsubscribe link keyed by a sequential ID that lets anyone unsubscribe anyone. Small failures, brand-level consequences.Check: increment the ID in an unsubscribe link.

19. Membership site — Content gated by route, not by API. Members-only material sits in the bundle or behind an endpoint with no check.Check: fetch a gated resource directly while logged out.

20. Portfolio / client portal (agency) — Predictable client URLs like /client/12. Client work, invoices and feedback visible by incrementing the number. The single most common finding in this category because the app was built for trusted users.Check: change the number.

Operations and internal tools

21. Inventory management — Stock counts updated without transactions. Concurrent updates overwrite each other, counts drift from reality, and nobody can explain the discrepancy because the failure leaves no trace.Check: are stock writes atomic, or read-then-write?

22. CRM / sales pipeline — Export function with no permission check. Any user can pull the entire contact database to CSV, which is exactly what a departing salesperson does.Check: who can hit the export endpoint?

23. Admin dashboard / back office — Admin routes protected by hiding the link. Typed directly, the page loads and the data loads with it. /admin is not a secret.Check: log in as a normal user, type the admin URL.

24. Reporting / analytics tool — Queries that load every row and aggregate in the browser. Instant at launch, unusable by month six, and the fix at that point is a restructure rather than an optimisation.Check: what happens at ten times your current row count.

25. Internal automation / workflow tool — Scheduled jobs configured in a platform interface, documented nowhere. Something breaks six months on and there is no file to read to find out what it was meant to do. The failure is institutional memory, not code.Check: can you list every scheduled job and what it does?

What repeats across all twenty-five

Read them together and three shapes recur.

The boundary is drawn in the interface. Numbers 1, 6, 8, 10, 16, 19, 20 and 23 are the same failure wearing different clothes: the app decides what you can see when it draws the screen, and the data layer underneath agrees to anything. This is the most common finding in AI-built software, full stop.

The feature exists; the states around it don't. Numbers 5, 9, 15, 21. The happy path was built because the happy path was what got described. Retries, failures, concurrency and reversals are states nobody prompted for, so nothing generated them.

Nothing assumes bad faith. Numbers 3, 4, 14, 17, 18, 22. Uploads, forms, exports and keys built for the user who behaves as intended. Adversarial thinking isn't a thing you can ask for without already knowing to ask.

None of this is a case against building with AI. The first 80% of every app on this list was produced in weeks by someone who couldn't have built it at all five years ago, and that's a real change. The failures are concentrated in the parts the prompting loop can't see — and those parts are, inconveniently, exactly where your business is exposed.

The failures are concentrated in the parts the prompting loop can't see — and those parts are, inconveniently, exactly where your business is exposed. Finding them in your own app is the first step of AI app rescue: someone reads the whole codebase and checks it against your app type's specific failure pattern.