Close every account when someone leaves

The idea

When someone leaves a twenty-person company, the offboarding checklist is a doc that lists the eight tools someone remembered in 2023. The other thirty accounts — the analytics tool a contractor bought, the status page, the transactional email provider — stay live until a renewal invoice reminds you. This is a web app that assembles the real list per person from systems you already run: identity provider logs, the password manager, SCIM directories, and org membership APIs. It produces an offboarding run: one row per account, each with a state, an owner, and a timestamped record of who revoked it.

Why build this

Every company between five and two hundred people has this problem and nobody owns it. IT-in-name-only is a founder or an ops generalist, and the tools that solve it properly (Okta Lifecycle Management, BetterCloud, Nudge Security) are priced and scoped for companies with an actual IT department. The failure mode isn't hypothetical: dormant accounts on tools with production access are a standard breach path, and the first real SOC 2 audit asks for termination evidence that nobody kept.

What makes it buildable now is that the discovery data is already sitting in APIs most teams have turned on. Google Workspace and Microsoft Entra both log every OAuth grant and SAML sign-in. 1Password and Bitwarden expose events feeds that show which vaults and items a person opened. Slack, GitHub, Linear, and Notion all list org members. You are not scraping anything — you are joining five read-only feeds on an email address.

Stack sketch

• Next.js App Router with TypeScript, deployed on Fly.io or a single VPS
• Postgres with Drizzle for accounts, people, runs, and an append-only event log
• WorkOS for admin SSO into the app itself, since your buyer already has an IdP
• Discovery connectors: Google Workspace Admin SDK Reports API (token and login applications), Microsoft Graph auditLogs/signIns, Okta System Log, 1Password Events Reporting API, Slack admin.users.list, GitHub org members
• BullMQ on Redis for connector syncs — each connector is a job that upserts observations, never writes to the vendor
• Connector credentials encrypted per-tenant with libsodium sealed boxes, keys in the host's secret store, never in Postgres plaintext
• Evidence exports rendered server-side with Playwright's PDF printer

Scope for v1

In: two discovery connectors (Google Workspace and 1Password), a reviewed account inventory per person, an offboarding run with per-account states (revoke, transfer, keep), manual check-off with a note, and a signed CSV plus PDF export of the completed run. Deduplication of aliases and shared logins to a single person record.

Out: any write to a vendor API. No automatic revocation, no SCIM deprovisioning, no browser extension, no mobile app, no spend data. v1 earns trust by being read-only and by being right about the list — if the inventory has three false accounts on it, nobody will trust the fourth.

Where it could go

The obvious next step is closing the loop: SCIM DELETE /Users for the vendors that support it, and Google's users.signOut plus token revocation for OAuth grants. That turns a checklist into a one-click offboard, and it's where people will pay a real per-seat price. Keep it opt-in per connector and keep the manual path working, because the first time an automated sweep revokes the wrong person's GitHub access you lose the account.

The second path is the reverse direction: continuous access review. The same inventory, run quarterly against current staff, answers "who has admin on our payment processor" — which is the question auditors and insurers now ask in writing. The third is finance: join the account inventory against card transactions from Ramp or Brex and you can show a founder the tools they're paying for that nobody signed into last quarter. That report sells itself in a screenshot.

Watch out for

Audit log retention is the trap — Google keeps login events for six months, and anything a departing person used less often than that is invisible to discovery. Say so in the UI and supplement with the vendor list from expenses, rather than implying the inventory is complete. The other risk is scope creep in the literal sense: the admin API scopes you need to read these logs are broad enough that a security-minded buyer will read your OAuth consent screen carefully, so request per-connector and document each scope.