Sheet 01 / 04Pattern 01 of 04
Pillars 01 / 03

The operational core

ERP, CRM, and BI for a business run on spreadsheets and tribal knowledge.

Representative stack

  • Postgres
  • TypeScript
  • Next.js
  • .NET
  • dbt
  • AWS
Sheet 02 / 04The operational core

01The situation

The business works — that's the problem. It works because four people carry the process in their heads and a lattice of spreadsheets holds the data. Growth means more people, and the heads don't scale.

This engagement replaces the lattice with a system of record: operations, customers, and reporting in one place, with the process encoded so it survives a resignation.

02How the gates apply

Assay carries unusual weight here: most of the work is discovering what the process actually is, as opposed to what the org chart says it is. Expect the discovery interviews to surface three different versions of every workflow.

Cast runs in increments that go live one department at a time — the spreadsheets retire gradually, never in a big-bang cutover.

Temper focuses on data migration integrity: the old spreadsheets are the test fixtures.

03What you receive

  • SYSTEM OF RECORD — DEPLOYED, DOCUMENTED
  • DATA MIGRATED AND RECONCILED IN WRITING
  • ROLE-BASED ACCESS MODEL
  • REPORTING LAYER FED BY MODELED DATA
  • REPOSITORIES AND RUNBOOKS, OWNED BY YOU

04Where this goes wrong without discipline

  • Skipping discovery and building to the org chart's version of the process — the real one surfaces in month four, as rework.
  • Big-bang cutover. The Friday the spreadsheets are switched off is the Friday everything breaks.
  • Treating reporting as a later phase. If the numbers aren't modeled from day one, the dashboards will disagree with the spreadsheets forever.

Next — Start with discovery

Bring us the raw idea.

Discovery is a fixed fee. The recommendation is honest — even when it's “don't build.”