Founder case study · Higher education
Making institutional reporting defensible — not merely faster.
Rollbook is a traceability product for accredited institutions: every reported number can be explained, reproduced, and defended — from source file to submitted report.
ROLE
Founder · Product · UX · Architecture
STAGE
Pilot / early access
INITIAL MARKET
ATS member schools (~280 institutions)
The founder-operated /ops workbench — work orders, import runs, and field reviews. Synthetic data shown.
Executive summary
Problem
Institutions can produce reports — but often cannot defend how the numbers were calculated when an accreditor, board, or auditor asks.
Opportunity
~280 ATS member schools file the same annual reports from the same class of SIS data, with no product built around provenance.
What I built
A service-led reporting system where every output traces to its source records and governing logic — validated through architecture and full production rehearsal.
What it proves
Domain insight converted into a market-ready product system — problem framing through architecture, build, and go-to-market.
01Validated product foundation — ledger model, ops workbench, and deployment proven in synthetic production rehearsal.
02A deliberate wedge: Populi as the first adapter, the ATS Annual Report Form as the flagship service.
03A synthetic-only data boundary — no real institutional data, SIS credentials, or customer access until controls earn it.
The operational problem
The number is producible. It is not defensible.
Registrars and institutional-research staff assemble annual reports from SIS exports, spreadsheets, and institutional memory. The report ships — but when a board member or accreditor asks "where did this number come from?", reconstruction takes days, and sometimes the answer is a shrug.
Who feels it
Registrars, IR staff, and the presidents who sign the filings — small teams carrying regulatory weight without engineering support.
Why existing tools miss
SIS platforms store records; BI dashboards chart them. Neither preserves the chain from source to submitted figure — the definitions, rules, and versions live in people's heads.
The cost of failure
Audit exposure, days of rework each cycle, and a quieter cost: institutional numbers the institution itself doesn't fully trust.
The product thesis
Reporting tools compete on speed and charts. Institutions need something rarer: numbers they can stand behind.
ROLLBOOK IS
A traceability system for institutional and regulatory reporting.
A governed, service-led workflow: provenance, validation, review, versioned delivery.
A system of record for how numbers were made.
A governed, service-led workflow: provenance, validation, review, versioned delivery.
A system of record for how numbers were made.
ROLLBOOK IS NOT
An SIS replacement.
A generic analytics dashboard.
Black-box automation that produces numbers no one can explain.
A generic analytics dashboard.
Black-box automation that produces numbers no one can explain.
The signature model
Every reported number carries its own chain of custody.
Scroll through the five layers. This chain — not a dashboard — is the product.
01
Source
Where the data originated
02
Definition
What the institution means by the metric
03
Validation rule
Whether the value satisfies required logic
04
Underlying records
Which records support the figure
05
Report version
Which output was delivered, and when
LAYER 01 — SOURCE
Origin is never a guess.
Every number begins as a record in the SIS or a file a registrar exported. Rollbook registers each source file and import run — who supplied it, when, and what it contained — so the first question an auditor asks is already answered.
LAYER 02 — DEFINITION
"Head count" means something specific here.
Two schools can report the same metric and mean different things. Rollbook stores the institution's definition alongside the number — so the metric travels with its meaning, not apart from it.
LAYER 03 — VALIDATION RULE
Failures become reviews, not silent corrections.
Rules run against the records: enrollment logic, completeness checks, cross-field constraints. When a value fails, it opens a field review with a human decision attached — the correction is part of the record, not an overwrite.
LAYER 04 — UNDERLYING RECORDS
Any figure expands to the records behind it.
A reported "142 enrolled" is backed by exactly 142 identifiable student-course records in the school's ledger. The aggregate and its evidence are the same object viewed at two depths.
LAYER 05 — REPORT VERSION
When a number changes, the chain explains why.
Deliverables are versioned. If this year's figure differs from the draft sent in March, the diff points to the import, rule, or review that moved it — which is the difference between a correction and a discrepancy.
The system
Architecture in service of the chain.
Per-school ledgers
Each institution's records live in an isolated ledger — tenant isolation is a traceability feature, not just a security one.
The /ops workbench
A founder-operated console where the reporting service runs: work orders, source files, import runs, field reviews, deliverables.
Governed intake
CSV/XLSX exports first, the Populi API later — every import run recorded, every mapping reviewable.
Synthetic-only boundary
No real institutional data, SIS credentials, or customer access — production behavior rehearsed entirely on synthetic records.
Laravel 13Filament 5PostgreSQL 17PHP 8.3NginxDigitalOcean · Ubuntu · PHP-FPM
The stack serves the story, not the reverse: relational integrity and an operable workbench are what make the chain of custody real.
Critical product decisions
Four decisions carry most of the product's shape.
01
Ledger-first: every school gets an isolated ledger.
The audit trail is the product, so isolation has to be provable — not a filter clause on a shared table.
REJECTED Shared multi-tenant tables. TRADE-OFF Heavier operations per school.
02
Service-led before self-serve.
The founder-operated /ops workbench runs the reporting service today. Learn the real workflow with expert hands on it, then harden it into customer-facing software.
REJECTED Customer-facing school accounts at launch. TRADE-OFF Founder hours in every engagement.
03
File intake before live API.
CSV/XLSX exports are how registrars already work. Starting there meets schools where they are and de-risks the Populi API integration that follows.
REJECTED API-first integration. TRADE-OFF Manual mapping in early engagements.
04
A synthetic-only production boundary.
No real institutional data enters the system until the controls earn it. For a buyer whose product is trust, responsible handling is a feature — demonstrated before it is claimed.
REJECTED Piloting with real exports immediately. TRADE-OFF A slower path to headline outcomes.
From product to business
A narrow wedge, entered deliberately.
CUSTOMER
Registrars and IR staff at ATS member schools — ~280 institutions filing the same annual reports.
OFFERING
Reporting as a governed service; the ATS Annual Report Form is the flagship deliverable.
PRICING
Founder-priced annual engagement — service-led delivery, not per-seat software.
GO-TO-MARKET
Populi as the first adapter and entry point; additional SIS adapters follow the wedge, not the other way around.
DELIVERY
Founder-operated through the /ops workbench; every engagement sharpens the product it becomes.
Evidence & current state
A validated foundation — described precisely.
Rollbook today is a validated product foundation and a completed production rehearsal — not yet a customer-proven platform. That distinction is deliberate, and it is why the claims below are split.
Validated today
● Traceability principle and product concept
● Per-school ledger and tenant-isolation model
● Founder-operated /ops workbench
● Work orders, source files, import runs, field reviews, deliverables
● Synthetic production rehearsal on DigitalOcean
● Synthetic-only data boundary
● Populi as first adapter; ATS reporting as flagship service
● Pricing model, service-led delivery, marketing site & positioning
● Per-school ledger and tenant-isolation model
● Founder-operated /ops workbench
● Work orders, source files, import runs, field reviews, deliverables
● Synthetic production rehearsal on DigitalOcean
● Synthetic-only data boundary
● Populi as first adapter; ATS reporting as flagship service
● Pricing model, service-led delivery, marketing site & positioning
In progress — not yet claimed
○ Paying customers and completed pilots
○ Production use with real institutional exports
○ Live Populi API integration
○ Automated CSV/XLSX parsing and mapping
○ Automated report generation at scale
○ Customer-facing school accounts
○ SOC 2 or formal compliance certification
○ Quantified customer outcomes and retention proof
○ Production use with real institutional exports
○ Live Populi API integration
○ Automated CSV/XLSX parsing and mapping
○ Automated report generation at scale
○ Customer-facing school accounts
○ SOC 2 or formal compliance certification
○ Quantified customer outcomes and retention proof
What this proves
One person carried this from insight to operable system.
Founder judgment
A narrow, defensible wedge chosen over a broad, generic one.
Product leadership
Thesis, decisions, and trade-offs made explicit and sequenced.
UX & systems thinking
The traceability chain as both the interface model and the data model.
Technical execution
A deployed, rehearsed Laravel/PostgreSQL system — built and operated solo.
Market translation
Domain insight priced, positioned, and pointed at 280 named institutions.