Sixty practice books — five subjects across twelve grades, each with question papers and machine-checkable answer sheets — is not something any sane person lays out by hand. So we built the machine that does it: structured question banks in, finished print-ready books out.
Print is a rendering target
Web developers think in screens, but a printed page is just another rendering target — one with brutal, unforgiving rules. Nothing reflows after the ink dries. A diagram that drifts two millimeters ruins a thousand copies. Automating print taught us a discipline of precision that quietly improved everything else we build for screens.
The interesting problems were pedagogical, not technical. Difficulty has to ramp correctly across grades. Diagrams must be generated, placed and referenced consistently. Answer sheets need to align with scanning hardware. Every rule a human editor holds in their head had to become an explicit, testable rule in the system.
The pattern generalizes
Catalogs, reports, certificates, manuals, question papers — any document a business produces repeatedly at volume is an automation candidate. If your team dreads 'layout week' every quarter, that dread is a product requirement nobody has written down yet.
Days of work, done in minutes, identically correct every time. That's not a pitch — it's just what happens when you treat documents as software output instead of manual labor.