Prompts to plan and fix what AI misses when vibe coding

Before generating any code, help me pick the right stack for what I'm actually building. Ask me about each of the following in order, and do not recommend a stack until we have worked through them all. 1. SEO and discoverability. Does this app need to rank in search, be crawled, or produce rich link previews? If yes, static generation or server rendering matters, so lean towards Next.js, Remix, Astro, or SvelteKit. If no, a SPA is simpler and cheaper. 2. Audience and access. Is this public-facing content, a logged-in product, or both? Internal tools and dashboards behind auth rarely need SSR and often ship faster as Vite plus React. 3. Mobile. Is this web-only, mobile-first, or both? If native features matter, consider Expo or React Native. If mobile web is enough, a responsive web app is cheaper to maintain. 4. Data shape and permissions. Heavy relational data with per-user access control leans towards Postgres with RLS on Supabase, or a typed ORM like Drizzle or Prisma on your own Postgres. Simpler document shapes can use Firestore. 5. Real-time. Does the product need collaborative editing, presence, or live updates? That changes the stack choice. Once you have my answers, recommend a stack, explain the trade-offs against the closest alternative, and flag anything you are uncertain about. Do not start building until we agree.

Audit the entire codebase. Store all dates and timestamps in UTC. Convert to the user's local timezone only at the display layer. Never store local times. Show me every file you change.

Audit the auth and permissions model. Admin flags and role columns must never be writable by end users through any API route, form submission, server action, or direct database query. The exact fix depends on your stack, so apply whichever matches this project. On Supabase, add RLS policies that only allow service_role to update role or is_admin columns, and confirm no client-side code uses the service key. On Drizzle, Prisma, Kysely, or node-postgres with a direct database connection, move role changes into an admin-only server action or endpoint that first checks the caller is already an admin, and never trust role values sent in the request body. List every endpoint, server action, and query that touches role or admin columns, and show me the protection on each one.

Audit every API route, server action, and database query that looks up a record by id, slug, or foreign key. For each one, confirm the query scopes to the current user or their organisation, not just to the id alone. The fix depends on your stack, so apply whichever matches this project. On Supabase, every user-owned table needs an RLS policy that filters on auth.uid() or the tenant id, for select, insert, update, and delete. On Drizzle, Prisma, Kysely, or node-postgres with a direct database connection, every query needs an explicit where clause that includes the current user id or organisation id, enforced server-side from the session, never from the request body or URL. Never trust ids from the client as proof of ownership. List every query you change and show me the ownership check on each one.

Audit every list view and data query. Add server-side pagination with a sensible default page size, and ensure common queries used across the app are cached but allow for mutations. Never fetch all rows. Add database indexes on any column used for filtering, sorting, or lookups. Show me every query you change and confirm no frontend is loading unbounded data.

Audit every data fetch in the app. Default to server-side fetching wherever possible and only use client-side fetching where interactivity genuinely requires it, so hosting and database costs stay low. For React client components and mobile apps, use TanStack Query (or the platform equivalent) with sensible stale times, cache invalidation on mutations, and optimistic updates where appropriate. Never refetch on every render. List every fetch you change and confirm each one is on the correct side of the client and server boundary.