If you’re a freelancer or agency using Lovable, Bolt.new, or Cursor to ship client projects — the building part is solved. It’s the handoff that kills you.
Signing clients up for Supabase. Creating orgs. Migrating billing.
Handing over credentials. Every. Single. Client.
run402 is the backend built for exactly this workflow. Your agent provisions the backend instantly.
Your client sees a live app. You transfer ownership in one step.
No Supabase accounts. No migrations. No drama.
Free prototype tier·AWS Aurora in production·No signup for you or your client
Every freelancer and agency building for clients hits the same wall. The building part works. The handoff doesn’t.
You build under your own Supabase account because asking a non-technical client to sign up before work begins kills deals. Now you have 5 client projects under your account, each with separate billing, separate credentials, and a growing list of things you need to remember to transfer when the project ships.
Supabase project transfers require both parties to have accounts. The client joins your org. Billing migrates separately. The Lovable frontend transfers on a different platform from the Supabase backend. One step breaks and you’re rebuilding from scratch.
“I’m working on a client app for 2 months. I created the project on my own org and now I want to hand over the project to my client and just realizing that you can’t do that!” — Supabase GitHub #6681
10 clients = 10 Supabase dashboards, 10 billing accounts, 10 sets of credentials to manage. No fleet view. No way to delegate infrastructure provisioning to the AI agent doing the actual build. You’re the bottleneck in your own workflow.
run402 is designed specifically for freelancers and agencies. Agent-provisioned backends, no client signups, clean handoff every time.
Your AI agent (Lovable, Bolt.new, Cursor, Replit) reads the run402 docs and fires one API call. Full backend provisioned in seconds: Postgres database, REST API, auth, file storage, static hosting. No human signup. No dashboard configuration. No environment variable copy-paste.
# Agent reads the docs, then: POST https://api.run402.com/v1/deploy/prototype { "name": "acme-client-portal", "migrations": "CREATE TABLE projects (...);", "site": [{ "file": "index.html", "data": "..." }], "subdomain": "acme-portal" } ✓ https://acme-portal.run402.com — live in ~3 seconds ✓ project_id, anon_key, service_key returned ✓ No Supabase. No dashboard. No credential copy-paste.
The project is live. Share the URL. Your client clicks through, tests features, leaves feedback. Everything runs on run402 under your account — the client doesn’t need to create anything, sign anything, or touch a dashboard. They just use the app.
# Share with client — that's it: ↗ https://acme-portal.run402.com Client tests the app. Approves the build. No Supabase account needed. No org invite. No waiting. You move on to the next project.
When the client is ready to own their project, you hand over the credentials and they’re done. Because run402 doesn’t require account creation, there’s nothing to migrate. No org transfer. No billing migration. No Supabase account for the client to create. The project just belongs to them.
# Grant client ownership — one step: POST https://api.run402.com/v1/projects/:id/transfer { "to": "client@acme.com" } ✓ Client receives access credentials ✓ No Supabase account required ✓ No org invite. No billing migration. Nothing to migrate.
Everything your agent needs to build and ship a real client app. Not a toy. AWS infrastructure behind it.
/rest/v1*.run402.com subdomainsSpin up a backend for each client project. Each is its own isolated lease. Free prototype for testing the workflow, then $5–$20/month per production project.
Pay via USDC on Base (your agent pays autonomously via x402) or Stripe credit card. Each client project can be its own backend with its own billing tier.
You’re putting your clients’ production apps on this. Here’s what’s under the hood so you can make that call with confidence.
Database AWS Aurora Serverless v2 (Postgres 16), multi-AZ Hosting CloudFront + S3 (wildcard *.run402.com) Encryption At rest (Aurora + S3) and in transit (TLS) Backups Automated, 7-day retention Isolation Each project gets its own Postgres schema Billing Hard-capped. No overages. No surprise invoices. Status api.run402.com/health-humans
Each backend is isolated. One client’s data is never accessible to another. Leases expire cleanly — day 0 read-only, day 7 archived, day 37 deleted. Renew anytime before deletion.
run402 slots into the vibe-coding workflow freelancers and agencies are already running. No new platforms. No new tools.
Lovable Paste /llms-cli.txt into context → agent provisions automatically Bolt.new Same — agent reads docs, calls API, deploys in one step Cursor HTTP calls or MCP server: npx run402-mcp Replit Plain HTTP — agent speaks to api.run402.com directly Any agent Read https://run402.com/llms-cli.txt and build
The Supabase-shaped API means projects built on run402 use the same patterns as Supabase —
/rest/v1,
JWT auth, RLS policies. Your agent doesn’t need to learn a new SDK.
Everything you need to know before putting a client project on run402.
run402 is a full-stack backend provisioned entirely over HTTP — no dashboards, no signups, no human setup steps. One API call from your AI agent gets you a Postgres database, a REST API, user auth, file storage, row-level security, and static site hosting. Everything lives on AWS (Aurora Serverless v2, CloudFront, S3).
It was built specifically for the pattern freelancers and agencies live in: AI-assisted builds, multiple concurrent client projects, and the need to hand things over cleanly when the project ships. The core design decision is that no account creation is required — not for you, not for your client. Credentials are issued at provisioning time and travel with the project.
The name comes from HTTP status code 402 Payment Required — reserved since 1997, finally useful now that stablecoins and AI agents can handle micropayments natively.
run402 speaks plain HTTP, so it works with any AI agent or tool. There are three entry points depending on your workflow:
The fastest path for most freelancers: open Lovable or Bolt.new, paste the prompt above, and let the agent do the rest. You get a live URL back in under a minute with no setup on your end.
run402 supports two payment paths. You pick whichever fits your setup:
For most freelancers and agencies today, Stripe credits are the simplest path. You buy a credit balance, your agents burn it down as they provision client backends, and you top up when needed. One billing relationship for N client projects.
The x402 path is designed for agents that manage their own finances autonomously — useful if you're running agents in production that need to self-provision without any human in the loop.
This is the question run402 was built to answer. The short version: access and payment are separate concerns, and you control both independently.
Here's how the handoff flow works conceptually. Think of it as a two-key system:
The payment side transfers independently of access. You can hand over access while you continue paying (useful for retainer arrangements), or transfer billing to the client at the same time. The project doesn’t care which wallet is funding it — it just needs an active lease.
This also makes run402 useful beyond client handoffs: any scenario where multiple people need access to one project — a freelancer + a client’s in-house developer, an agency team sharing a backend, a subcontractor who needs temporary access — all handled by the same access-grant / access-revoke mechanism.
No. That’s the whole point.
run402 doesn’t require account creation at any stage — not for provisioning, not for access, not for the client. Access is credential-based: whoever holds the project credentials (project ID, API keys) can interact with the backend. Sharing access means sharing or delegating credentials, not inviting someone to create a platform account.
This is what makes client handoffs fast. Your client doesn’t need to sign up for anything. They don’t need a Supabase account. They don’t join an org. They don’t set up billing. They get credentials and their project works.
Yes. The infrastructure is AWS-grade: Aurora Serverless v2 (Postgres 16, multi-AZ), CloudFront + S3 for static hosting, TLS everywhere, automated backups with 7-day retention. Each client project lives in its own isolated Postgres schema — one client’s data is never accessible to another.
The prototype tier (free) uses testnet USDC and is intentionally short-lived (7 days) — use it to validate the workflow works before committing a client project to production. The $5/month Hobby tier and $20/month Team tier are production leases with real billing, real durability guarantees, and no expiry risk beyond the lease period.
Hard caps, no overages. Every lease has a hard ceiling on storage and API calls. You will never receive a surprise invoice for a client project that got unexpectedly popular.
Start with the free prototype tier. Build a real client project with your AI agent. See how the handoff feels when it actually works.
Free prototype · No credit card · No Supabase account for your client