SLW / devportal
Production apps
@teammate
App lifecycle

Every app, from idea to live — and moving up is a switch, not a rebuild.

One place for every app. Apps go Experiment → Incubating → Operational. The whole framework — dev app, dev database, CI, previews, the progress board, approvals — gets built while an app is Incubating, with production built but dark. Going live just flips it on.

Experimentprod ✕ none
Throwaway. Dev data only. No production.
Incubating
Two modes: build on dev data (no gates), or run real data — same approvals & gated workflow as live apps.
New build or import an existing app (e.g. from Replit) — creates repo, database, deployed app + board.
Operationalprod ● live
Live. Team depends on it. Gates enforced.
💡
Why this shape. An experiment graduates the moment someone commits to building it for real, a second person relies on it, or it touches real data — that's when it earns a parallel dev app and enters Incubating. Approvals scale with risk automatically: no production, no gates; production live, gates on.
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

Show steps for:
Once, ever

One command, then Claude Desktop

~10 minutes, one time
1

Run one command to build your workspace

It installs what's needed, signs you into GitHub (your browser opens — click Authorize, maybe twice), and builds your personal SLW Workspace in the cloud with every app you have access to already inside.

Press the Windows key, type powershell, Enter, then paste:

> irm rivent.dev/setup | iex

Open the Terminal app, then paste:

$ curl -fsSL rivent.dev/setup | bash

Safe to re-run any time — it repairs whatever's missing.

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

Connect & open a project

Each work session you open a secure link, then pick the app you want.

Each session

~15 seconds

3

Open your secure link

In PowerShell, run this and leave the window open — wait for the big TUNNEL OPEN box, then minimize it:

> irm rivent.dev/connect | iex

This opens the tunnel that lets Claude Desktop reach your workspace. Closing it (or a reboot) disconnects — just run it again next session.

Nothing to open

On Mac, Claude Desktop connects to your workspace directly — no command needed. Go straight to the next step.

4

Connect it in Claude Desktop

Click the environment pill (bottom of the Code window) → your SLW Workspace connection. First time only: + Add SSH connection and enter these (also saved on your Desktop as Rivent-Workspace-Connection.txt):

highlighted = what you type indashed = swap in your own value
SSH Host
codespace@localhostcs.your-workspace.mainThe same for everyone on Windows.the name gh codespace list shows.
Port
2222leave emptyYour workspace's secure port.Nothing to enter on Mac.
Identity
C:\Users\you\.ssh\codespaces.auto/Users/you/.ssh/codespaces.autothe full path setup printed (your username in place of you).
5

Open your app folder

When Select Remote Folder appears, clear the box, type /workspaces, click Go, then click into your app and Select Folder:

terminal
Terminal
podcast
Podcast
lpflow
LP Flow
slide-library
Slide Library
dealflow-app
Deal Flow

You'll only see the apps you have access to. To switch apps later, reopen the folder picker.

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.

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

Coming back after a restart? Your workspace, sign-in, and Claude Desktop connection all stay saved — just re-run irm rivent.dev/connect | iex (Windows) to reopen the link, then open Claude Desktop.

💡
One quick command each session. On Windows you run connect when you sit down (~15s); everything else is already saved. (SLW work laptops block auto-start, so this stays a manual step — Mac connects without it.)

That's it — you're set up.

Each session: run connect (Windows), open Claude Desktop, pick your app under /workspaces, build.

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.