Capability Guardrails
Before building, check the user's request against these lists. If a feature falls under "Not Possible," tell the user clearly in plain language and suggest the alternative.
What run402 CAN do
- Postgres database — tables, columns, constraints, indexes, SQL queries
- REST API — full CRUD (create, read, update, delete) with filtering, pagination, ordering via PostgREST
- Row-level security — user_owns_rows, public_read, public_read_write templates
- User authentication — email/password signup, login, token refresh, logout
- File storage — upload, download, signed URLs, list objects (S3-backed)
- Static site hosting — deploy HTML/CSS/JS, get a shareable URL, SPA support
- Multiple tiers — Prototype ($0.10, 7 days), Hobby ($5, 30 days), Team ($20, 30 days)
- Testnet (free) — Base Sepolia with faucet for test USDC
What run402 CANNOT do
These features are not available on run402. If the user asks for any of these, explain the limitation in plain language and suggest the alternative.
| Not Possible | Tell the user | Alternative |
|---|---|---|
| Fully custom domain names (myapp.com) | "You can't use your own domain name (like myapp.com) right now, but you can get a memorable subdomain like myapp.run402.com." | Claim a subdomain via POST /v1/subdomains in Step 15. Your app gets a URL like https://myapp.run402.com. |
| Server-side code / backend logic / lambdas / edge functions | "Everything runs in the browser. There's no way to run code on a server behind the scenes." | All logic runs client-side in JavaScript. Use the database for shared state. |
| Real-time WebSocket connections | "Live instant updates aren't available. But your app can check for new data every few seconds automatically." | Use polling (timed fetch every 3-10 seconds) for "near real-time" updates. |
| Email / SMS / push notifications | "Your app can't send emails, texts, or notifications. But it can show alerts inside the app itself." | In-app notifications, badge counters, or "new items" indicators that appear on page load/refresh. |
| Payment processing (beyond x402) | "Your app can't take payments from your users (no credit cards, no Stripe checkout)." | Track IOUs or balances in the database. Use external payment links if needed. |
| OAuth / social login (Google, Facebook, etc.) | "Sign-in is email and password only. No 'Sign in with Google' button." | Email/password authentication is built in and works well. |
| Custom database extensions | "You can use standard database features but can't add special add-ons." | Use standard PostgreSQL features (JSON columns, generated columns, etc.). |
| File sizes over 50 MB per deployment | "Your entire app needs to be under 50 MB. That's plenty for most apps, but no large video files." | Optimize images, use external hosting for large media files. |
| More than 100 requests/second | "Your app can handle about 100 people using it at the same time. For bigger events, some requests might be delayed." | Design for reasonable concurrency. Use caching strategies in the client. |
How to use this page
During the spec phase (steps 1-4), check the user's feature requests against the "Not Possible" list above. If a match is found:
- Tell the user clearly using the suggested language in the "Tell the user" column.
- Offer the alternative.
- Ask if they'd like to proceed with the alternative or skip that feature.
- Never attempt to build something that will fail — catch it here.
During the implement phase (steps 9-14), if you realize a planned feature hits a guardrail, stop and revisit with the user before continuing.