Deploying a Complex Cursor App with Prisma, Postgres, Inngest & Supabase

I built a complex full-stack application with Cursor to see how different deployment platforms handle realistic AI-generated code.

Not a todo app. Not a landing page. Not a clean demo with one framework and one environment variable. I wanted something closer to what people actually end up building when they spend a few evenings with Cursor, Claude, ChatGPT, or any of the newer agentic coding tools: a product-shaped app with auth, a database, background work, third-party APIs, and enough moving parts that deployment stops being a simple npm run build.

The result was VibeSplit, a group expense splitter with AI receipt scanning.

The Test App

VibeSplit lets a group upload receipts, parse them with AI, split expenses, track balances, invite other people, and settle up. It is intentionally the kind of app that feels easy to create with an AI coding assistant and then suddenly becomes much harder when it has to run somewhere real.

The stack looked like this:

• Next.js 15 with the App Router and TypeScript
• Prisma with PostgreSQL
• Supabase Auth for magic links and Google login
• Inngest for background jobs
• OpenAI Vision for receipt parsing
• Stripe for settlement payments
• Resend for application emails

This is exactly the shape of many vibe-coded apps I see: the code works locally, but production needs a real database, real secrets, OAuth redirect URLs, webhook URLs, background jobs, migrations, and build-time public environment variables.

That last phrase matters more than it sounds. Some variables are runtime-only. Others, like NEXT_PUBLIC_SUPABASE_URL, are baked into the browser bundle during the Next.js build. If a platform passes environment variables only when the container starts, the backend may be fine while the frontend quietly ships with placeholder values.

Why This Was A Useful Test

Simple apps hide deployment problems. A static frontend can make almost any platform look good. A basic Next.js app with no database and no integrations usually deploys without much drama.

VibeSplit surfaced the messier parts:

• Prisma needs a valid DATABASE_URL and production migrations.
• Supabase Auth needs public client values at build time and redirect URLs after deploy.
• Stripe needs callback URLs that point to the live app.
• Inngest needs a reachable endpoint for background jobs.
• OpenAI and Resend need server-side secrets.
• The app needs to bind to the correct port inside a container.

The goal was not to prove that any platform is bad. The goal was to see which platform understood the shape of the app without making me manually reconstruct the architecture in a dashboard.

Railway

Railway handled the Next.js part reasonably well at first. It detected that the app was a Node/Next project and tried to run it in the expected way.

The first problem was the port. The initial deployment came up with a 502 error because the app and the platform did not agree on the port. This was resolved fairly quickly, but it is exactly the kind of issue that breaks the illusion of one-click deploy. The app was alive somewhere, but traffic was not reaching it correctly.

After the port issue, the bigger problem was the database. Railway did not provision a PostgreSQL database automatically for this repo. The app used Prisma, had a Prisma schema, and clearly needed a database, but I still had to add Postgres manually.

That meant I had to wire DATABASE_URL, think about Prisma migrations, and check whether the runtime environment matched what the app expected. Even after adding Postgres, I still ran into internal server errors. At that point the deployment had moved from "deploy my repo" to "debug platform configuration, application assumptions, and service wiring at the same time."

Railway is powerful once you know what you are doing, but for this kind of AI-generated full-stack app, it still expected too much manual reconstruction.

Vercel

Vercel deployed the frontend successfully. That is not surprising; Vercel is very good at Next.js.

But the live site returned a 500 Internal Server Error. The frontend build existing was not enough. This app was not just a frontend. It needed a database, Prisma, migrations, Supabase values, API routes, server actions, and several third-party secrets.

The tricky part with Vercel is that a successful deployment can look deceptively complete. The build passes, a URL exists, and the app is technically online. But the first real user flow reveals what was missing.

In this case, the platform did not infer the full backend shape of the application. I still had to think through the database and environment setup myself. For a clean Next.js app, that is fine. For a multi-service vibe-coded app, the gap is noticeable.

Jetpacked

Jetpacked detected the app as a full-stack deployment instead of treating it as just a Next.js frontend.

It picked up the Postgres requirement, the Prisma setup, and the required environment variables. That made the deployment feel closer to the way I want this category of platform to work: read the repo, understand the stack, then ask me for the values that cannot be inferred.

The deployment completed with the least friction of the three. I did not have to manually create a database first and then wire the app around it. The platform understood that the database was part of the application shape.

That said, it was not magic. A few things still required manual attention.

Supabase Auth redirect URLs had to be configured in the Supabase dashboard after deployment. This is easy to forget. The app can deploy perfectly and still fail login if Supabase only allows localhost:3000 as a redirect target.

I also ran into the difference between runtime and build-time environment variables. For Next.js, public variables like NEXT_PUBLIC_SUPABASE_URL must be available during the build or the frontend bundle can contain placeholder values from .env.example. That is a subtle production issue because the container can have the correct runtime env while the browser is already running code built with the wrong value.

This is the kind of issue that deployment tooling needs to understand. It is not enough to inject env vars into the running container. For frameworks like Next.js, some of them must also be passed into the build.

Supabase Was Its Own Step

Supabase Auth introduced a separate class of deployment work.

The app used Supabase for magic links and Google login. The environment variables pointed the app to the correct Supabase project, but Supabase itself still needed production URL configuration.

The Google provider had to be enabled in Supabase. The deployed callback URL had to be added. The site URL had to stop pointing at localhost. None of that lives in the application repo, and no hosting platform can fully infer it from code.

This is an important lesson for vibe coders: when your app uses external auth, deployment is not only about your server. It is also about configuring the provider to trust the new production URL.

Live Result

The app is now running here:

https://receipt-splitter.s1-local.jetpacked.ai/

It is not meant to be a polished product launch. It is a deployment test that became realistic enough to expose the problems I care about.

What I Learned

Complex vibe-coded apps need platforms that understand more than framework names.

Detecting "Next.js" is useful, but it is not enough. The real deployment shape is Next.js plus Prisma plus Postgres plus migrations plus Supabase plus background jobs plus public build-time env vars plus server-only secrets.

Railway got me part of the way there but required manual service setup and port debugging. Vercel handled the frontend but did not solve the full-stack requirements by itself. Jetpacked handled the complete setup noticeably smoother for getting the app live quickly.

The rough edges were instructive. Supabase still needs manual provider and redirect configuration. OAuth still depends on external dashboards. Build-time environment variables still matter. But the core deployment path was much closer to what I want: connect the repo, detect the real stack, provision what the app needs, and surface the remaining configuration clearly.

That is the bar deployment platforms need to clear for AI-generated applications. Not "can it build a Next.js app?" but "can it understand the messy, service-heavy thing someone actually built?"