The idea
A self-hosted service that connects to the admin APIs of the SaaS tools a company actually pays for — Slack, Google Workspace, Zoom, GitHub, Figma, Salesforce, and a growing plugin list — and builds a single view of who has a seat, how recently they logged in, and what it costs. It flags seats unused for 60+ days, users with licenses on tools they've never opened, and overlapping tools that do the same job (two design apps, three project trackers). Before each renewal it produces a short report: seats to reclaim, estimated dollars saved, and a Slack digest to the finance or IT owner.
Why build this
Every mid-size company accumulates SaaS sprawl: a manager buys 20 seats for a rollout, half the team never activates, nobody downgrades at renewal because nobody's job is to notice. IT and finance teams increasingly ask "what are we actually paying for" but the answer lives in a dozen admin consoles, none of which talk to each other. SaaS management platforms exist (Zylo, Productiv, Torii) but they're enterprise-priced and built for procurement teams, not the 50–500 person company that just wants a clear list before the next Slack Enterprise Grid invoice arrives. Self-hosting it also means the login/usage data — which is sensitive, since it maps directly to who's actively working — never leaves the company's infrastructure.
Stack sketch
- Backend: Python with FastAPI, one connector module per SaaS provider using their admin/SCIM APIs (Slack SCIM API, Google Workspace Admin SDK, GitHub Enterprise API, Zoom Admin API)
- Scheduler: APScheduler or a simple cron container to pull usage snapshots nightly
- Storage: Postgres for seat/user/cost history, so trends over time are queryable, not just a point-in-time snapshot
- Frontend: a small React or htmx dashboard — one table per tool, sortable by last-active date and monthly cost per seat
- Auth: OAuth admin scopes stored encrypted at rest (age or Postgres pgcrypto), never exposed to the frontend
- Notifications: a weekly Slack digest via incoming webhook, plus a CSV export for finance
- Deployment: Docker Compose, matching the pattern of a typical internal-tools stack — one container per service behind a reverse proxy on the internal network
Scope for v1
- In: 4–5 connectors for the most common tools (Slack, Google Workspace, GitHub, Zoom, one more by request), nightly usage pull, a dashboard listing seats with last-active date and per-seat cost, a manual "mark as reclaimed" action
- In: a single weekly summary email or Slack message with top 5 reclaim candidates by dollar value
- Out: automatic deprovisioning (too risky without human review at this stage), contract/invoice parsing, negotiation or benchmarking features, SSO-based auto-provisioning of the tool itself
- Out: multi-tenant support — v1 assumes one company's admin credentials, not a hosted product serving many customers
Where it could go
The natural next step is contract-aware cost modeling: ingest the actual contract terms (tiered pricing, committed minimums, true-up dates) so the tool can say not just "12 seats unused" but "reclaiming these 12 seats saves $0 until your next true-up in March, but saves $1,400/month after." From there, a request-based provisioning workflow closes the loop — instead of just flagging idle seats, let managers request access through the tool and auto-expire it after a configurable idle window, turning the auditor into the system of record for who has access to what.
A further expansion is tying seat data to security posture: cross-reference the same login data against an identity provider to catch former employees who still have active licenses somewhere the offboarding checklist missed — a genuinely dangerous gap this tool is well positioned to close as a side effect.
Watch out for
Every provider's admin API has different rate limits, pagination quirks, and definitions of "active" (last login vs. last API call vs. last message sent), so connectors need per-provider tuning rather than a generic abstraction — resist the urge to force a single interface too early. Admin-scope OAuth tokens are also high-value targets, so encryption at rest and tight scope minimization aren't optional polish, they're the reason a company would trust self-hosting this over a SaaS alternative in the first place.