Sometimes the best content is hidden behind the worst interfaces. That was exactly the problem with Teaching Books.
An old colleague, Nick, reached out to me when I was in the early days of founding Before Labs. He founded owned Teaching Books, at the time, an educational resource platform that had been serving teachers for over two decades. He had a simple question: did I know anything about responsive websites? I needed the work, and I'd been focused on responsive design for years. I said absolutely.
What I found was a classic case of technical debt meeting modern expectations. Teaching Books had great content—a massive library of books and teaching resources used by educators across the country. But it was trapped in a 20-year-old Perl application with a dated desktop interface that hid the value.
Teaching Books is sold to states, local governments, and school districts. These aren't customers with unlimited budgets or patience for poor user experience. They need tools that work, and they need to see value immediately. When you're competing for limited educational funding, your product needs to communicate its worth the moment someone lands on it. The interface was actively hiding the content. The books and teaching resources were the stars of the show, but the design made them nearly impossible to appreciate or navigate effectively.
Then there was the technical foundation. 18 years of operational processes, business logic, and workflows were baked into this Perl codebase. This wasn't just code—it was the entire operational backbone of the business. The question: could we modernize the experience without destroying the foundation everything was built on? We correctly believed we could.
We built our approach around two core decisions.
1: Make the books shine. This became our north star. Every design decision came back to the same question: does this help the books and teaching resources stand out? Are we making it easier to find books? When you find them, is it immediately clear what resources are available? The content was already great. We just needed to get out of its way.
2: Preserve what works. Here's where we made the decision that defined the entire project: we would not touch the backend. Taking 18 years of operational processes and rewriting them for a company that wasn't minting money (educational budgets are tight) would have been irresponsible. Maybe with today's AI tools it would be feasible, but at the time, it would have been project suicide.
We partnered with Wild Shore, a design agency, to create a visual system that put books front and center. I worked with my friends at Penso on the build. We rebuilt the entire front end using modern frameworks while learning just enough Perl to interface with the existing backend. We essentially went back in time technically to move forward in user experience.
The strategy was refreshingly simple. Sometimes it really is. Make the books the star of the show. Highlight book pages and their resources clearly. Make it easy to find books, and when you find them, show exactly what resources are available. Remove any design elements that compete with the content. We approached this like renovating a house with great bones but terrible wallpaper. The foundation—the business logic, the operational workflows, the content management—all stayed intact. We just gave it a modern interface that let users actually see and use what they were paying for.
The project succeeded because we knew what not to do. By leaving the backend largely intact, we avoided months of potential debugging and business disruption. We maintained all existing operational processes without retraining. We delivered a modern, responsive interface in a fraction of the time a full rewrite would have taken. And we kept the project within budget for an educational technology company with limited resources.
Teachers could finally see and access the library that had always been there. The responsive design meant they could use it in the classroom on any device. State and local government buyers could immediately understand the value proposition. Most importantly, we proved that you don't always need to rebuild everything from scratch. Sometimes the best technical decision is knowing what to leave alone.
I think the decision to leave the backend as-is was the best call we made on that project. It's tempting in this industry to want to rewrite everything, to use the latest tools, to start fresh. But Teaching Books taught me that respecting legacy systems and focusing your efforts where they matter most—in this case, the user-facing design—can deliver better results than a ground-up rebuild.
The content was always good. We just had to let it shine.