Find the spreadsheets your company secretly runs on

The idea

Point it at your company's SharePoint or OneDrive tenant. It crawls every spreadsheet, reads the formulas and edit metadata, and scores each workbook on how much it looks like a running system rather than a document. The output is a register: the twenty workbooks that would hurt most if they silently broke, who has been editing them, and which other files they pull numbers from.

Why build this

Every company past about thirty people has a few of these. The commission calculation. The capacity model the ops lead rebuilt from memory after the last one corrupted. The pricing sheet finance actually invoices from. They have no owner, no tests, no version history beyond whatever the drive keeps, and usually one person who understands the formulas. Nobody set out to build production software in Excel; it accreted.

Auditors already ask for this under the "end-user computing" heading, and the tools that answer it — Apparity, CIMCON, Mitratech — are priced and shaped for banks. A small company gets asked the same question during SOC 2 or a funding diligence round and has nothing to hand over.

It is buildable now because the hard parts are commodity: Microsoft Graph exposes an incremental delta feed over a whole tenant's drives, per-file activity is a documented endpoint, and parsing .xlsx is a solved problem in Python. The work is scoring and presentation, not plumbing.

Stack sketch

• Crawler: Microsoft Graph /drives/{id}/root/delta, resumable via delta tokens, plus /analytics for editor counts. One background worker per drive.
• Parsing: openpyxl in read-only mode. Pull the stored formula strings rather than evaluating anything; tokenize them with the formulas package or a small Lark grammar.
• Link graph: resolve external references ([1]Sheet1!A1, defined names, IMPORTRANGE if you add Drive later) back to file IDs. Store edges in Postgres, traverse with NetworkX.
• Scoring features: formula count and nesting depth, distinct editors in 90 days, edit frequency, inbound external references, presence of VBA, share scope, and hardcoded constants buried inside formulas.
• Backend: FastAPI with Celery and Redis for crawl jobs.
• Frontend: SvelteKit — one register table, one dependency graph view with Cytoscape.js.
• Deploy: Docker Compose, self-hosted. Files stream through memory; only metadata is persisted.

Scope for v1

In: a single Microsoft Graph connector, .xlsx only, the risk score with its component features visible, a sortable register, the cross-workbook link graph, CSV export.

Out: legacy .xls/.xlsb, Google Sheets, cell-level diffing, remediation workflow, alerting, SSO. A single admin OAuth consent is enough for the first version, and shipping without it is how you never ship.

Where it could go

Ownership is the obvious next layer. Attach a named owner to each high-scoring workbook and send a quarterly "is this still yours, is it still in use?" nudge — most registers rot within two quarters without that loop.

After that, change monitoring, which is the control auditors actually want. Hash the formula regions on every delta pass and alert when a formula changes inside a top-twenty workbook. That turns a one-off inventory into something with a reason to stay running, and it is the feature worth charging for.

Further out, migration. A workbook that scores high but turns out to be a three-column lookup with a VLOOKUP wrapper is a table and a small form. An LLM can propose the schema from the parsed structure, and a human approves it.

Watch out for

Read access across an entire tenant's drives is close to the most sensitive permission you can request, so keep it metadata-only, never write file contents to disk, and be ready to demonstrate both. Graph also throttles aggressively at tenant scale — assume 429s are normal and make every crawl resumable from the last delta token.