Universal dev server · MCP connector · cubby.pro

Your chat already builds apps. Cubby makes them real.

The universal dev server for AI-built applications.

n.b.

Cubby is not a code generator — your chat is the generator; Cubby is where the app runs.

works in Claude today — the connector is a URL you paste.

in Claude · your team’s chat

“Build us a PTO tracker — requests, approvals, and a who’s-out calendar the whole team can see.”

tools/call → plan_app

cubby · deploy logmcp

▸plan_apppto-tracker · 4 tables · 3 roles✓ ▸scaffoldtypescript · react · postgres✓ ▸deploy_appbuild · migrate · route✓ livepto-tracker--h7k2m.cubby.pro authsign in with Cubby · built in dbpostgres · its own instance exitexport rehearsed · rebuilds anywhere

host table · representative builds — every app at its own address scheme · appname--xxxxx.cubby.pro

№	app	host	db	auth	conn	state
01	pto-tracker	pto-tracker--h7k2m.cubby.pro	pg · own	requireUser()	—	live
02	on-call-rotation	on-call--q3w8d.cubby.pro	pg · own	requireUser()	—	live
03	visitor-sign-in	visitors--m2c6r.cubby.pro	pg · own	requireUser()	—	live
04	lead-triage	lead-triage--k4v9j.cubby.pro	pg · own	requireUser()	1 vaulted	live
05	kpi-dashboard	kpi--d8f2w.cubby.pro	pg · own	requireUser()	1 vaulted	live

§01 protocol

From a sentence to a running system.

Three tool calls sit between a description and a deploy. They are real MCP tools — the same names you’d read in the trace above.

Describe it in chat.

In the chat your team already pays for, you say what you need. Cubby’s connector hands the chat real tools — plan_app shapes tables, roles, and views before a line is written, so you approve a plan, not a surprise.

plan_app → pto-trackerdraft

tablesrequests · people · balances · audit

rolesadmin · manager · member

viewsmy requests · approvals · who’s out

authrequireUser() on every route

Cubby materializes it.

The plan becomes a running application: scaffold lays down TypeScript and React; deploy_app builds it, runs migrations on the app’s own Postgres, wires real auth, and puts it live at its own address.

cubby · materializerun

▸scaffoldapp skeleton · typescript/react✓ ▸dbprovision postgres — its own, not a schema✓ ▸authsign in with Cubby · requireUser()✓ ▸deploy_appbuild · migrate · route✓ livepto-tracker--h7k2m.cubby.pro

Share it.

Send the address — that’s the rollout. Teammates sign in with Cubby and it just works. One CNAME if you want your own domain. And the exit is rehearsed: export any day; apps rebuild and run anywhere in seconds.

share sheetpto-tracker

▸https://pto-tracker--h7k2m.cubby.pro

sign-inteammates sign in with Cubby

Members, dues, and waivers in one place.

dbpostgres · its own

authrequireUser()

schema3 tables · dues ledger

urlsignup--w1z8q.cubby.pro

The eleventh is yours.

describe it in the chat you already pay for

representative builds · every address follows the scheme appname--xxxxx.cubby.pro · under the hood: typescript/react on the app’s own postgres

§03 headless

Every app you build is also its own MCP server.

Use your apps from the same chat that built them. Every Cubby app answers at its own /mcp: ask it questions, take actions — and it runs as you, with the same sign-in and permissions as the app’s screens. A real capability of what Cubby builds, arriving in early access.

in Claude · the chat that built it

“Who’s off next week? Approve Dana’s request.”

tools/call → pto-tracker /mcp

pto-tracker · /mcpruns as you

▸readlist_pto_requests · who’s off next week✓ →reads the app’s own who’s-out data ▸writedecide_pto_request · approve Danagated confirm“approve Dana’s request?” — yes✓ ✓doneanswered + acted · app never opened

pto-tracker · headlessearly access

▸pto-tracker--h7k2m.cubby.pro/mcp

runs asyou · same sign-in, same permissions

toolsdeclared by the AI that built it

writesconfirm before they run

exitworks anywhere the app runs

the app is its own MCP server · same requireUser() as its screens · the connector at cubbyapps.com builds; the app at cubby.pro answers.

§04 guarantees

Boring where it counts.

The parts you never see are the parts built first.

isolation

Apps live apart.

Every app runs separate from every other — its own runtime, its own data, its own address. A bug in the league tracker can’t see the quote calculator.

database

A whole Postgres each.

Not a schema on a shared box. Each app gets its own Postgres, provisioned at deploy. Your data has a front door, and it’s yours.

connections

Vaulted, never pasted.

Connections to internal systems — Salesforce, Snowflake, the price list — live in a vault. The chat gets a capability, never the credential.

exit

The exit is rehearsed.

Export is real and tested: apps are standard TypeScript and React, and they rebuild and run anywhere in seconds. The door out is why you can trust the door in.

auth · sign in with Cubby, built in domains · one CNAME for your own stack · typescript/react under the hood headless · every app’s /mcp runs as you · same sign-in the full security page →

The install is a paste and a sign-in.

Cubby’s connector is one URL. Paste it into Claude, sign in, and the tools are there — plan_app, scaffold, deploy_app — inside the chat your team already pays for. The walkthrough, including the ChatGPT route, lives at /connect. For Claude Code there’s the Cubby plugin: install it, then sign in.

claude › customize › connectorsmcp

step 1add connector → paste Cubby’s URL

step 2sign in to Cubby → pick a workspace

step 3say what you need, in plain words

§05 · a walkthrough

Want a walkthrough for your team?

Leave a work email and Matty will set one up. Or skip the line: sign in and start building.

rebuilding in the open · early access · sign in at app.cubbyapps.com.

reservation card№ 000011

cubby№ 000011 · reserved

doorwork first · people later

sign inapp.cubbyapps.com · today

hostyourapp--xxxxx.cubby.pro · pending

the eleventh cubby · reserved for you