Bullwinkle
a comprehensive exploration of what it takes to create blended-language books at scale
Goals
When Prismatext's first MVP, Gringlish, went live, it proved the viability of our blended-language reading experience. It cut book creation time by 99% and demonstrated that readers loved the concept of language immersion through literature. But Gringlish was a prototype at heart—rigid, slow, and limited to a single variant per language. It couldn't scale, it lacked automation, and updating books meant reprocessing entire files.
The next evolution, Bullwinkle, set out to change all that. It wasn't just an engineering challenge—it was a product design challenge, one that demanded a deeper understanding of how users wanted to experience bilingual reading, and how our internal workflows could scale to meet that demand.
Our goals were ambitious. We aimed to increase the number of language variants per book from one to twenty-seven, introduce true versioning and fine-grained translation control, and reduce time-to-publish by another 90%. Beyond efficiency, we wanted precision: the ability to target individual words or phrases and edit their translations without needing to re-blend an entire book. This would fundamentally change how we maintained and improved content quality.
The overarching design goal was modularity. Bullwinkle needed to function as an adaptable system—a set of interlocking components that could evolve independently as our capabilities expanded.
Before writing any code, it's important to understand how Bullwinkle relates to the apps and services it interacts with.
Insights
The most valuable research came from two sources: user behavior and our own limitations. From Gringlish, we learned that users wanted something replayable. They weren't content to read a single “blended” version of a book; they wanted to re-read familiar stories with different words translated each time, to challenge themselves as their fluency improved. That feedback completely reframed how we approached word selection.
Instead of simply applying a uniform translation density, we built a system for ranking words across different genres and difficulty levels. That ranking became the foundation for dynamic translation sets, allowing Bullwinkle to produce 27 meaningful variants per title—each with its own pedagogical nuance.
Externally, we had few benchmarks to lean on. At the time, large-scale text-generation and translation systems were still primitive compared to what's available today. That forced us to build nearly everything from scratch: word segmentation, alignment logic, and the blending algorithms themselves. While daunting, it gave us total control over the product design, ensuring that every component—from interface to logic—served our specific learning model.
We built our own e-reader in part because our need for rich footnotes wasn't available in other e-readers.
A visual workflow of book processing is necessary to understand how each step relates to the next, as well as informing the development of each module.
The entire Bullwinkle codebase is written in Python, and covers a wide range of functionality, from EPUB processing to LLM integration.
Mockups demonstrating foreign word density levels on a page.
Constraints
Time was our most pressing constraint. We had promised investors a working system by Christmas, and our publishing partners were waiting on new titles that couldn't be delivered without Bullwinkle. With limited staff and no external contractors, I was responsible for designing the full experience, building the logic, and communicating progress to the broader team.
We also faced technical constraints. The new system's expanded capabilities risked ballooning file sizes, which would make downloads slow and data-heavy. To solve this, I designed a two-part optimization strategy:
- De-coupling text from media assets, allowing content to be updated or transferred independently
- Aggressive compression, including wrapping entire book text in GZIP archives for faster transfer
Concepts
With the lessons from Gringlish in hand, I began drafting Bullwinkle's specification document. This was both a product roadmap and a design manifesto—outlining not just what the system would do, but why each feature mattered. It merged user insights, internal feedback, and technical requirements into a cohesive vision for how blended-language books should be authored, managed, and experienced.
From that foundation, I created wireframes that illustrated how each stage of the blending process would behave. These weren't just visual aids—they defined the architecture of the backend pipeline. Each screen represented a system state: ingestion, translation, blending, quality assurance, and publication. The act of wireframing the backend gave shape to the user experience of authoring itself, and those same diagrams later supported our 2023 patent application.
The design language of Bullwinkle prioritized transparency. Each phase of the pipeline offered clear progress states and manual override points, so the team could step back incrementally during troubleshooting. This balance of automation and human control became one of the defining principles of Prismatext's internal tools.
Tradeoffs
No ambitious project is without compromise. The biggest tension in Bullwinkle's design was between automation and nuance. Full automation was tempting—it would have made the process lightning fast—but the subtleties of bilingual learning required a more controlled approach. We needed systems that could adapt to linguistic irregularities, not steamroll them.
Another tradeoff was technical: to accurately calculate page layouts and prevent cropped content, we built a custom Markdown-inspired syntax rather than using a standard Markdown parser. While this meant maintaining our own spec, it allowed for more precise control of text flow and visual alignment—a product design decision rooted in the reading experience itself.
Impact
The completion of Bullwinkle was transformative for Prismatext. We achieved every major goal: time-to-publish dropped by 90%, book creation scaled effortlessly across 27 variants per language pair, and translation accuracy improved dramatically. The new versioning system gave us the ability to track and visualize improvement cycles, providing valuable data on how many iterations a title needed before it reached “perfect” status.
Beyond measurable metrics, Bullwinkle fundamentally changed how the company operated. The modular architecture meant that each part of the system—translation, blending, output, and asset optimization—could evolve independently. That flexibility paved the way for future innovation and made Prismatext's entire publishing process more resilient.
It also proved pivotal in securing investor confidence and intellectual property protection. The system's design documentation and process wireframes became key components of our patent filing, formalizing the innovations behind blended-language publishing.
On a personal level, this project tested every skill I had—as a designer, developer, and leader. Building Bullwinkle solo forced me to balance vision with execution, trust with discipline. More than anything, it reinforced a principle that's guided every project since: great systems design is as much about clarity and communication as it is about code.