Founder & designer · Higher education
Making institutional reporting defensible rather than merely faster.
Rollbook is a traceability product for accredited institutions: every reported number can be explained, reproduced, and defended. The trail runs from source file to submitted report.
ROLE
Founder · Product · UX · Architecture
STAGE
Pilot / early access
INITIAL MARKET
ATS member schools (~280 institutions)
Field review in context. It shows verified rows, flagged records, year-over-year change, and the reviewer action path that makes a reported number defensible.
Summary
Problem
Institutions can produce reports, but they 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. It was validated through architecture and a full production rehearsal.
What it proves
Domain insight converted into a market-ready product system. The work ran from problem framing through architecture, build, and go-to-market.
01Validated product foundation. The ledger model, ops workbench, and deployment were proven in a 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. They are 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 is the product, not a dashboard.
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, including 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 becomes 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. That is the difference between a correction and a discrepancy.
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 rather than 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, and it is demonstrated before it is claimed.
REJECTED Piloting with real exports immediately. TRADE-OFF A slower path to headline outcomes.
The system
Architecture in service of the chain.
Per-school ledgers
Each institution's records live in an isolated ledger, because 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 is recorded, and every mapping is reviewable.
Synthetic-only boundary
No real institutional data, SIS credentials, or customer access. Production behavior was 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.
Evidence & current state
A validated foundation. Described precisely.
Rollbook is validated and ready for market. The product foundation is complete, and a full production rehearsal proved it works end to end. Rollbook is now open to its first partner institutions.
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
What this proves
One person carried this from insight to operable system.
Scope judgment
A narrow, defensible wedge chosen over a broad, generic one.
Explicit trade-offs
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 that was built and operated solo.
Positioning
Domain insight priced, positioned, and pointed at 280 named institutions.
C.Price
MBA·PMP
UX/UI Design · Design Systems · Accessibility
© 2026 C.Price
Atlanta, GA (metro)