SLW / devportal
Production apps
@teammate
Welcome

Pick a project — set it up once in Claude Desktop.

Each project runs in a cloud workspace with the app and dev database ready. You reach it through the Claude desktop app — no browser editor, no local setup — and build by describing what you want. Production data never reaches you.

Experiments

Test a new app idea — without touching the real apps.

Every idea becomes its own small prototype site, stamped from a starter with SLW branding and email-allowlist login already working. This board is the directory: what's proposed, what's being built, what's live.

IdeaProposed byStatusLinks & actionsUpdated
Loading the board…
Proposed waiting for someone to press Start building Building repo + database + hosting ready, Claude session open Live prototype deployed — click through it Retired tried it, didn't stick
1

How it works — two clicks and a conversation

Everything mechanical is automatic. Nothing here touches the production apps.

1

Add the idea

Name + two sentences. It lands on the board as Proposed — nothing is built yet.

Rivent
2

Press "Start building" — wait ~30 seconds

Rivent stamps a private repository from the starter template, gives the idea its own section of the experiments database, and wires up hosting. You never see GitHub, Vercel, or Supabase.

Rivent
3

Open it in Claude and press send

Press Build with Claude on the row — it opens Claude Code with the repo selected and "build it" already typed. Press send; Claude knows the idea and the house rules from the repo. Then just react and iterate in plain English. The live link appears on this board on its own.

Claude Code
💡
Prototypes stay protected. Every stamped app ships with @slw.vc email sign-in built in — nothing sits on the open internet. And prototypes must never contain real SLW data without Shawn's OK. Prefer Claude Desktop? An experiment connects like any project — see Start here, using its repo name from the row.
First-time login

Start here — how it works, and your setup.

Everything you need to go from zero to shipping. Read how it works, do the one-time setup, connect your first project — then you're working. About 10 minutes the first time; seconds every day after.

1

How it all works

The Codespace is your environment — a cloud computer with the app running. Claude Desktop is your interface — you connect it to that workspace and build by talking. Nothing runs on your laptop; production data never reaches you.

01

One link, one sign-in

Open rivent.dev and sign in with your @slw.vc email. Bookmark it — it's the front door to every project.

02

A Codespace is your environment

GitHub builds a cloud workspace from the repo's .devcontainer — dependencies and dev-database wired up, identical for everyone. It runs on practice data; production is never injected. You never open the browser editor — you reach the workspace through Claude Desktop.

03

Claude Desktop is your interface

The native Claude app connects to that workspace over SSH. You get the Claude interface, with the real running environment behind it — one place to work.

04

Build by describing

Tell Claude what you want in plain English. It runs inside the Codespace — sees the real code, runs the app, uses the dev database.

05

Reviewed & persistent

Changes are reviewed before they go live, and the workspace persists — reconnect tomorrow right where you left off.

Stays open while
You're working
Idle-suspends after ~30 min, resumes on reconnect.
Compute cost
~$0.18 / hr
Billed to the org only while active. Auto-suspends.
Your Claude plan
Separate bill
You sign into Claude Desktop with your own account.
2

Set up your machine

Once per computer

Install two tools

~5 minutes, one time ever
1

Install the GitHub CLI & sign in

This lets your computer open cloud workspaces. In Terminal:

$ brew install gh
$ gh auth login

Choose GitHub.com → HTTPS → login with a browser. If you ever hit a "codespace scope" error, run gh auth refresh -h github.com -s codespace.

2

Install Claude Desktop & sign in

Download the Claude desktop app and sign in with your own Claude plan (Pro or Max). This is your interface for every project.

3

Open a project & connect Claude

Do this once per project. Already set up your machine (blocks 1–2)? Those are done forever — start right here for each new project. Setting up a second project just adds it alongside the first in your Claude Desktop dropdown.

For each project

Three steps, first time only

3

Create your cloud workspace

Pick your project and run the command in Terminal — it spins up the workspace (~30–60s the first time) with the app, dependencies, and dev database ready. No browser editor opens; you'll reach it through Claude Desktop.

Project: 
$ gh codespace create -R rivent-dev/LPCRM3
4

Register the workspace for Claude

One command tells your machine how to reach it, and shows its address:

$ gh codespace ssh --config >> ~/.ssh/config
$ gh codespace list # note the name, e.g. solid-parakeet-…

Your workspace address is cs.<that-name>.main — you'll paste it next.

5

Connect it in Claude Desktop

Click the "Where Claude runs" dropdown (bottom of the Code window) → + Add SSH connection, and fill in the four fields:

highlighted = what you type indashed = swap in your own value
Name
LP FlowAnything you like — just a label for this connection.
SSH Host
cs.your-workspace.mainfrom Step 4the name gh codespace list printed — written as cs.NAME.main.
Port
leave emptyNothing to enter — filled in automatically.
Identity
/Users/you/.ssh/codespaces.autofrom Step 4your Mac username in place of yough created this key for you.

Select the connection — Claude installs itself on the workspace (~20s). The dropdown now shows LP Flow instead of "Default."

4

Then, every day

6

Describe what you want, in plain English

Claude runs inside the workspace — it sees the real code, can run the app on the dev database, and makes the change. Your work goes up as a reviewed change; nobody edits the live app directly.

LP Flow › Add a "last contacted" date to the investor list and sort by it.

Coming back later? Open Claude Desktop → pick the project from the dropdown → keep going. No setup — it's already connected.

💡
You won't need to type paths. Each workspace opens straight in its project folder, so Claude is ready the moment you connect.

That's it — you're set up.

Everything after today is: open Claude Desktop, pick your project, build.

Coming soon

The project board — how work gets tracked & shipped.

Every change lives on our GitHub Project board, from a rough idea to a shipped feature. This is a first draft of how we'll use it.

🚧 Not live yet

The flow below is a draft preview — the columns and process aren't finalized. This tab lights up once it's set.

1

Where the board lives

All projects share one GitHub Projects board. Open it from any project card (Project board →) or bookmark it directly. Each card on the board is one piece of work — a fix, a feature, or an idea — and it moves left to right as it progresses.

Open the board ↗

2

The columns

📥

Inbox

Raw ideas and requests, unsorted. Anyone can drop one here — a sentence is enough.

📋

Up next

Triaged and ready to pick up, roughly in priority order.

🔨

In progress

Being worked on right now — a branch is open and Claude is on it.

👀

In review

A pull request is open, waiting for a teammate to approve.

Shipped

Merged and live. The card links to the PR that delivered it.

3

How an idea becomes a feature

1

Capture the idea

Add a card to Inbox — or use /capture while working and Claude files it for you.

2

Pick it up

Move a card to In progress, open the project in Claude, and describe what you want.

3

Open a pull request

Claude does the work on a branch and opens a PR — the card moves to In review.

4

Review & ship

A teammate approves, CI passes, it merges — the card moves to Shipped.

📝
Placeholder draft. The columns, labels, and exact flow aren't final — tell me what the board should actually track and I'll shape this into the real guide.
Roles & rules

App Operators — who can build apps, and the rules they follow.

An App Operator can take an app from idea to fully live in our stack — repo, database, hosting, portal — without being an account admin anywhere. This page is the rulebook: what the role grants, who holds it, the rules of the road, and exactly how a migration works.

Operate — the everyday

Build, deploy, iterate

Code, hosting, env vars, CI, portal listing. Unrestricted on green CI — this is most of the work.

Provision — the guarded step

Databases & data

Creating a database and copying data runs through the migration script (backup → restore → verify), so the one destructive step can’t be fumbled.

1

What an App Operator can do

Least privilege on every platform: enough to build and run apps, never enough to touch billing or delete an organization.

PlatformCan doCan’t do
GitHubrivent-devCreate app repos, push, merge PRs, set CI & secrets on their own appsChange settings on shared repos, delete the org, billing
SupabaseSLW DatabasesCreate & manage project databases, run migrationsDelete the org, billing, manage members
Vercelslw1010Deploy apps, manage project env varsBilling, delete the team
Cloudflarerivent.devDeploy Pages, edit rivent.dev DNSAccount admin, other zones
Replitsource appsOpen, edit & export ReplsTeam billing & members
🛡️
Guardrails still apply on top. The sensitive paths — database schema and production / deploy config — stay gated by review (CODEOWNERS + rulesets), so even a repo-admin operator can’t bypass sign-off on those. Whoever creates a repo is its admin; the shared repos stay Write-only.
2

Who’s an operator right now

PersonRoleStatus
Loading the roster…

Add or remove an operator

One command on the server grants the role — it handles GitHub + Vercel automatically and prints the three manual invites (Cloudflare, Supabase, Replit). Remove someone by taking them out of the same five places.

$ add-app-operator <github-username> <email>
3

The rules of the road

Seven rules cover every scenario. They keep operators fast on the safe things and careful on the few that matter.

1

You own what you build

You’re admin on any repo you create. Org rules still gate the database and production paths — those changes need review, no matter who you are.

2

Small & verified goes straight to main

If it’s small and tests pass, ship it. Features, migrations, and anything risky go through a pull request with green CI.

3

Never hand-copy a database

Data moves only through the migration script. It backs up first, restores, and verifies row counts — so the one irreversible step can’t go wrong quietly.

4

Each app gets its own database

A production DB plus a -dev twin, following the house pattern. Spinning them up is your call — just be intentional: each active database ≈ $10/mo (~$20 for the pair).

5

Dev never holds real production data

Practice data only in dev and experiment databases. Real SLW data or secrets go into a dev environment only with Shawn’s OK.

6

One repo per app, in rivent-dev

Named for the app; its database matches the name. Keeps the portal, Codespaces, and databases lined up one-to-one.

7

People are added & removed in one place

Use add-app-operator to grant the role. Reverse it by removing them from the same five platforms — membership is the access.

4

Migrating an app off Replit

Five stages, same every time. The one that decides the path is Stage 1 — whether the app has a real database.

STAGE 1

Diagnose

Run the report prompt in the Replit Agent. It reports the stack, the secrets it needs, and — the deciding question — whether it has a Postgres database.

STAGE 2

Code out

A new repo in rivent-dev, code pushed, Replit-specific bits stripped out.

STAGE 3

Database

If it has one, the script creates its Supabase project (prod + dev), copies the data across, and verifies it. Skipped entirely for apps with no database.

STAGE 4

Hosting & kit

Deploy to Vercel or Cloudflare, load the secrets, add a devcontainer + CI, and list it on the portal.

STAGE 5

Cut over

Smoke-test the live app, then turn the Replit app off. Nothing is deleted until the new one is proven.

Where it ends up living — the same shape as every other SLW app:

Source
GitHub
rivent-dev / <app>
Database
Supabase
its own project (+ dev)
Hosting
Vercel / CF
under rivent.dev
Dev in
Codespace
via devcontainer
Old Replit
Retired
off after cutover
5

Questions & scenarios

The situations that actually come up — click any to expand.

I want to migrate one of my Replit apps.
Start with the diagnose step — run the report prompt in that app’s Replit Agent so we know the stack and whether it has a database. Then it’s the five stages above. If several apps are moving, pilot one first to prove the flow, then batch the rest.
My app needs a database — what happens to the data?
It gets its own Supabase project (a production database and a -dev twin). The migration script copies your data across with a backup taken first and a row-count check after, so nothing is lost. Budget ≈ $10/mo per active database (~$20 for the pair), billed to the org.
How do I make someone an App Operator?
Run add-app-operator <github-username> <email> on the server. It adds them to GitHub + Vercel automatically and prints the three manual invites (Cloudflare, Supabase, Replit). They accept the GitHub and Vercel emails, and they’re in.
How do I remove someone?
Take them out of the same five platforms they were added to — GitHub team, Vercel, Cloudflare, Supabase, Replit. Membership is the access, so removing it revokes everything. Apps and databases they built stay put; they’re owned by the org, not the person.
I need to do something an operator can’t.
That’s an owner action by design — billing, deleting an organization, org-wide settings, or a change to a gated production/database path. Ask Shawn. The role deliberately stops short of these so a mistake or a compromised account can’t reach them.
Who pays for the databases and hosting?
The org (SLW). Supabase is on the Pro plan; each additional active database ≈ $10/mo. Vercel and Cloudflare usage is org-billed too. Operators can create these resources — the spend guardrail is Rule 4: be intentional.
What happens to the old Replit app?
It keeps running untouched until the migrated app is smoke-tested and confirmed live. Only then do you turn Replit off. Nothing is deleted mid-migration — there’s always a working version.
Can an operator change a production app or its database?
Not directly. Day-to-day app changes ship on green CI, but production/deploy config and database schema are gated by review — even for repo admins. That’s the line between “operate” and “owner-approved.”
Where will my app live after moving?
Code in GitHub (rivent-dev), its own Supabase database, hosted on Vercel or Cloudflare under rivent.dev, and developed in a Codespace — identical to every other SLW app, so anyone on the team can pick it up.