Grok Build Can Now Ship to Vercel: What Solo Founders Should Check Before the First Preview Deploy

Grok Build just shipped a Vercel plugin. You describe your SaaS, Grok writes the Next.js app, and one click pushes it to a Vercel preview. URL live in under two minutes. You drop it in a Discord, your cofounder pokes around, you ship. Here is what nobody tells you. That preview URL is not gated. Anyone who guesses it, or anyone you accidentally paste it to, can hit every API route Grok wrote. And Grok writes routes that trust the caller. Last week I opened a founder's Grok-built dashboard, changed user_id=42 to user_id=1 in the URL bar, and pulled the admin's email and Stripe customer ID out of /api/me. The app had been live for six hours. The founder thought the preview was private because the subdomain was long and random. It was not. This is what to check before you click that first deploy button, and what Grok will not check for you.

02The preview URL is not private

Vercel preview deploys get a URL like your-app-git-feature-yourteam.vercel.app. By default that URL is public. No password, no SSO, no IP allowlist. The 'obscure subdomain equals secure' assumption is wrong. Preview URLs end up in Grok's chat history, in your Slack, in PR comments, in browser sync, and in any tool that scrapes pasted links to render previews. I have seen preview URLs land in Google within 48 hours because someone shared the link in a public Discord and a crawler followed it. Grok Build makes this worse. When Grok deploys to Vercel it surfaces the preview URL in the chat so you can click it. That URL now lives in your Grok history. If your preview is wired to a real Supabase project with real data, which it is if you handed Grok a SUPABASE_URL and SUPABASE_SERVICE_ROLE_KEY, the first preview is already a production-shaped attack surface. Check this today. Open your last Vercel preview URL in an incognito window. If the dashboard loads, your preview is public. Go to Project Settings, Deployment Protection, and turn Vercel Authentication on for preview deployments. One toggle, and your previews sit behind your Vercel team login. Do it before you wire the next Supabase key.

03Grok writes API routes that trust the caller

Here is the failure that ate the founder I mentioned. Grok generated a Next.js API route at /api/me that looked sane: export async function GET(req) { const userId = req.nextUrl.searchParams.get('user_id') const { data } = await supabase.from('users').select('*').eq('id', userId).single() return Response.json(data) } The route reads user_id from the query string, asks Supabase for that row, and returns it. There is no check that the caller is actually that user. Grok did not add auth middleware. The frontend always passes the logged-in user's ID, so in the UI it looks correct. In Postman, or a curl from another tab, you walk the entire users table by incrementing the number. This is the IDOR pattern, and Grok ships it constantly. It also ships /api/admin routes guarded only by a useEffect that hides the button when role is not admin, which is the UI pretending to be the bouncer. The API itself does not check. Run this check today. List every file under app/api or pages/api. For each route, ask: does this route call supabase.auth.getUser() or check a session cookie before it touches the database? If the answer is no on any route that returns user data, that route is a free dump. Add the auth check on the server, not in the component.

04Before you share the preview link

Before you click Deploy in Grok Build again, do four things. First, audit the Supabase keys Grok is using. If your .env has SUPABASE_SERVICE_ROLE_KEY in it and Grok pushed it to Vercel as an env var available to preview, every API route runs as god. Move the service role key to a server-only env (no NEXT_PUBLIC_ prefix, scoped to production only) and use the anon key plus Row Level Security for normal queries. Second, turn on Supabase RLS for every table Grok touched. Grok will generate select * from users without RLS, because RLS is off by default on new tables and Grok does not enable it. If RLS is off, your anon key is also a god key the moment it ships to the browser. Third, gate the Vercel preview behind Deployment Protection, as covered above. Fourth, scan the routes. Point Guardian at your Grok-built Vercel preview URL and it walks every API route Grok shipped, tries the IDOR pattern on each one (changing user_id, organization_id, and invite_token), and tells you which routes return data they should not. It also flags the service role key leaking to the browser and RLS being off on tables your API queries. If you are about to share that preview link with anyone outside your laptop, scan it first. The preview is a production attack surface the moment it exists.