If you build client apps for a living with AI tools, the building part is solved. The handoff is not.
Org invites. Billing migrations. Credential ceremonies. Every single client.
Client work deserves a platform shaped like the job: your agent provisions a full stack
per client, the client tests the live app from day one, ownership transfers cleanly,
and you keep maintain access for the retainer.
Paste this into your coding agent and watch the whole loop run:
Please build me a demo app using run402.com/llms-cli.txt (curl it)
Free prototype tier·AWS Aurora in production·No signup for you or your client
Everyone building for clients hits the same wall. The building part works. The handoff doesn’t.
You build under your own accounts because asking a non-technical client to sign up for a cloud platform before work begins kills deals. Now you have 5 client projects under your name, each with separate billing, separate credentials, and a growing list of things you need to remember to transfer when the project ships.
Project transfers on the usual platforms require both parties to hold accounts. The client joins your org. Billing migrates separately. The frontend lives on one platform and the data on another, so the handoff happens twice. One step breaks and you’re untangling it on a weekend.
10 clients = 10 dashboards, 10 organizations, 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.
Designed for client work end to end: agent-provisioned full stacks, no client signups, a clean transfer, and maintain access that outlives the handoff.
Your AI agent reads the run402 docs and fires one API call. A full stack is provisioned in seconds: Postgres database, REST API, auth, file storage, static hosting. One atomic deploy ships the whole app, database included. Your client tests the live URL from day one, while you build.
# Agent reads the docs, then provisions the project: POST https://api.run402.com/projects/v1 # Then applies the whole app in one atomic commit: POST https://api.run402.com/apply/v1/plans { "project": "prj_...", "database": { "migrations": [{ "id": "001_init", "sql": "CREATE TABLE projects (...);" }] }, "site": { "replace": { "index.html": {...} } }, "subdomains": { "set": ["acme-portal"] } } POST https://api.run402.com/apply/v1/plans/:id/commit ✓ https://acme-portal.run402.com live in ~3 seconds ✓ project_id, anon_key, service_key returned ✓ Client watches the live app evolve. No dashboard, no setup.
When the project ships, offer it to your client by email. They claim it from the link and the project is theirs: their billing, their credentials. No platform account creation, no org migration, no rebuild. The live site never blinks.
# Offer the project to your client by email: POST https://api.run402.com/projects/v1/:project_id/transfers { "to_email": "client@acme.com" } # They claim it from the emailed link: POST https://api.run402.com/agent/v1/transfers/:transfer_id/claim ✓ Client receives fresh project credentials ✓ Billing is now the client’s ✓ No org invite. No account creation. Nothing to migrate.
The client owns the project and pays for it. You keep maintain access, so “can you fix the header” is a message to your agent, not a re-onboarding project. Retainer revenue without holding the client’s app hostage. The client can revoke your access whenever they choose; you were never in the way.
# After the transfer: 1. Client owns the project and its billing 2. You keep member access for maintenance 3. "Fix the header" arrives → your agent redeploys 4. Client can revoke your access at any time Same agent. Same project. Ongoing revenue.
Everything your agent needs to build and ship a real client app. Not a toy. AWS infrastructure behind it.
/rest/v1 patterns your agent already knows*.run402.com subdomainsSpin up a project for each client. Each is its own isolated lease. Free prototype for testing the workflow, then $5 to $20 per month per production project.
Pay with card credits your agents spend as an allowance, or let the agent pay per call over machine rails (x402 or MPP). Two equal paths, your choice. Each client project can be its own tier. Optional: KMS signers for on-chain signing, $0.04/day per wallet plus $0.000005 per call. Non-custodial. See /billing/.
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 status.run402.com
Each project is isolated. One client’s data is never accessible to another. Leases expire cleanly with a ~104-day soft-delete grace. The client’s live site keeps serving throughout; deploys and secret rotation lock after day 14; permanent deletion at day ~104. Renew anytime during grace to reactivate instantly.
Slots into the AI-assisted 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
Familiar REST patterns
(/rest/v1,
JWT auth, RLS policies) mean your agent doesn’t need to learn a new SDK.
Everything you need to know before putting a client project on run402.
A full stack 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 site hosting (static and Astro SSR). Everything lives on AWS (Aurora Serverless v2, CloudFront, S3).
It was built 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 and 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 AI agents can pay for what they use.
Plain HTTP under the hood, so it works with any AI agent or tool. Three entry points depending on your workflow:
The fastest path for most freelancers: open your AI tool, paste the prompt above, and let the agent do the rest. You get a live URL back in minutes with no setup on your end.
No crypto needed. Two payment paths, equal standing. You pick whichever fits your setup:
For most freelancers and agencies, card credits are the simplest path: one credit balance, N client projects, top up when needed.
This is the question the platform was built to answer. The short version: access and payment are separate concerns, and you control both independently.
Here’s the handoff flow, as a two-key system:
The payment side transfers independently of access. You can hand over billing while keeping maintain access (the retainer arrangement), or step away entirely and let the client revoke you. The project doesn’t care which wallet is funding it; it just needs an active lease.
The same access-grant / access-revoke mechanism covers every multi-party scenario: a freelancer plus the client’s in-house developer, an agency team sharing a project, a subcontractor with temporary access.
After the transfer, the client owns the project and pays for it. You stay a member with deploy access until they decide otherwise.
In practice: the maintenance request arrives, your agent (which already knows the project) makes the change and redeploys, and the client’s live site updates. No re-onboarding, no credential archaeology, no “can you add me back to the org” thread.
The client’s side of the bargain: revocation is one action, theirs alone, any time. Maintain access is a working relationship, not a hostage situation. That is what makes it easy for clients to say yes to.
No. That’s the whole point.
Account creation isn’t required at any stage: not for provisioning, not for access, not for the client. Access is credential-based: whoever holds the project credentials can interact with the project. 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 sign up for anything, doesn’t join an org, doesn’t set up billing before they even own the thing. They claim the project and it works.
Yes. The infrastructure is AWS-grade: Aurora Serverless v2 (Postgres 16, multi-AZ), CloudFront + S3 for 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) is intentionally short-lived (7 days): use it to validate the workflow before committing a client project to production. The $5/month Hobby tier and $20/month Team tier are production leases with real billing and real durability guarantees.
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.
Run the whole loop free: your agent builds a real project, your client sees it live, and you feel what the transfer is like when it actually works.
Please build me a demo app using run402.com/llms-cli.txt (curl it)
Free prototype · No credit card to start · No account for your client