Your agent writes the app. We make it shareable.
The login, the permissions, the database — already there. You write only the part that's yours, then share it like a document, inside your company.
The audit and the spec run before you sign up. Registration waits until you deploy.
import bcrypt from "bcrypt";
import session from "express-session";
import { pool } from "./db.js";
app.use(session({ secret: process.env.SECRET }));
app.post("/register", async (req, res) => {
const { email, password } = req.body;
const hash = await bcrypt.hash(password, 12);
await pool.query(
"INSERT INTO users (email, pw_hash) VALUES ($1,$2)",
[email, hash]
);
req.session.uid = email;
res.redirect("/");
});
app.post("/login", async (req, res) => {
const { email, password } = req.body;
const u = await pool.query(
"SELECT id, pw_hash FROM users WHERE email=$1",
[email]
);
const ok = u.rows[0] &&
await bcrypt.compare(password, u.rows[0].pw_hash);
if (!ok) return res.status(401).send("Nope");
req.session.uid = u.rows[0].id;
res.redirect("/");
});
function requireAuth(req, res, next) {
if (!req.session.uid) return res.redirect("/login");
next();
}// the visitor is already signed in.
// this is who they are:
const user = req.header("X-App-User");Private · The first deploy is always private. Only you hold the URL — check it, then decide who's next.
Named · Only the people you name can open it. No links that work for anyone who finds them.
Organization · Everyone signed in to your organization can open it. Access stops at the org edge — never outside it.
runtime: node-22
start: npm startAnd even this is inferred from your package.json.
Hand it to your colleagues, not a zip file.
Your tool works. Now you want the person next to you to open it — same data, same place, no "install this first." But there's no login on it, no way to say who's allowed, and nowhere it can just live for the team. So it goes out as a zip, or "run it yourself," or it stays on a laptop under a desk. Building it was the easy part. Getting everyone into the same one is the wall.
Build, deploy, share.
Build
Tell your agent what you need — Claude Code, Cursor, Codex. The skill is already installed, so the code is written to the contract from the first line.
Deploy
Say "deploy this." The agent creates the app, pushes the folder, reads the logs, and fixes itself if something breaks. No git, no repository, no admin rights to arrange first.
Share
Pick a level in the sharing dialog. The first deploy is always private — you get the URL, you check it, and only then does anyone else. Changing access never redeploys and never edits code.
Private · The first deploy is always private. Only you hold the URL — check it, then decide who's next.
Named · Only the people you name can open it. No links that work for anyone who finds them.
Organization · Everyone signed in to your organization can open it. Access stops at the org edge — never outside it.
The value is what's already there.
Not in your code
- Authentication — comes from the corporate account, through the proxy.
- Setting up a database —
DATABASE_URLis there the moment the app exists. - Storage —
STORAGE_*is there too. - Domain and certificate — done.
- Resource config — there is nothing to declare.
runtime: node-22
start: npm startAnd even this is inferred from your package.json.
The contract
- Listen on
$PORT. - Read the user from the request header.
- Keep state only in Postgres and S3.
- Treat the filesystem as read-only.
- Don't write your own auth.
- Answer a health check.
- Declare secrets by name.
No required SDK. No framework to learn. Plain code just works, in any language your agent writes. That is the difference from Val Town and Convex — worth saying out loud.
Bring what you've got.
You built a tool before you'd heard of any of this. Here is every honest change, and how much each one actually costs.
| What changes | How much it hurts |
|---|---|
| Port | Usually already process.env.PORT. Nothing to change. |
| Files → S3 | Half an hour, mechanical. |
| SQLite → Postgres | The biggest piece. |
| Delete your own auth | Small, but easy to miss. |
About that login. Your app won't break with its old one in place — it'll just work. The visitor simply signs in twice: your organization first, then your homemade form. That second login is dead weight, so the agent removes it rather than repair it.
If you already have data. There's one more step — matching your existing users to their accounts. It's easy to forget, and a real headache when you do. We don't hide it.
Answers for whoever signs off.
Ten apps build faster than one.
The catalog
One list of every app in the organization: yours, the ones shared with you, everything you're allowed to open. Without it, nobody knows a colleague already built the tool they need.
Composition
Let Billing read the customer table that CRM already owns. The tenth app is faster than the first, because the data is already there — instead of ten drifting copies of the same customer list.
Small tools rot. We don't let them.
Dependencies drift. Code an agent wrote works today and quietly breaks in three months. We keep the ground underneath patched and current, and we notice when something stops answering — so the tool you built in spring still opens in winter.
The objections worth answering.
"We already have Retool."
Retool needs the person building the tool to know Retool. Here the agent builds it, and the tool is plain code — the same code your people already write.
"Isn't sharing employees' code a security hole?"
A scanner runs before anything is shared, with a report on where data flows. Apps are isolated from each other, and access never leaves the organization.
"What if the author leaves?"
An admin takes ownership of the app. Nothing is stranded on a departed account.
Start from either end.
If you already have code, have it audited. If you're about to build, install the skill so it's written to the contract from the start.
The audit and the spec work without signing up — you register only when you deploy. Viewers are free; only the people who build apps pay.