UX/UI design, web development, and full-stack modernization for the world's first comprehensive online quantitative and qualitative encyclopedia of religious cultural history
Client location: Vancouver, BC; London, UK
The Database of Religious History (DRH) is the world's first quantitative and qualitative encyclopedia of cultural history populated exclusively by experts. Hailing from UBC, Stanford, and the London School of Economics, the team behind it assembled out of a shared recognition that no modern scholar can keep up with the current rate of scholarly output. Their mission is to help researchers overcome data overload by gathering knowledge directly from experts into a single database that is universally accessible, instantly updatable, and infinitely expandable.
Pieoneers has been the engineering partner behind the platform for years, taking it from a small experiment to a production system used daily by researchers around the world. In 2025 and 2026, we led a comprehensive modernization of the application, ten times faster than a traditional modernization of comparable scope, with senior engineers directing AI tools throughout.
Our Involvement
Product strategy
UX & Visual design
Technical Architecture
Codebase Modernization
Workflow Optimization
Hosting & Dev Ops
Technologies
Python
Django
React
TypeScript
GraphQL
Hasura
Apollo
TanStack Query
React Hook Form
Tailwind CSS
Claude Code
2025–2026 Modernization Phase
The Database of Religious History is now in its second decade as a production platform. Over the course of 2025 and 2026, we led a comprehensive modernization of the application's framework foundations, state management, data layer, and styling system, while the platform continued to ship features and serve researchers without interruption.
The latest phase of work was led by Andrew Manshin, our CTO, working with Claude Code as the primary engineering accelerator. The combination compressed work that would conventionally take six to twelve months into a matter of weeks: approximately ten times faster than the same modernization would take with a traditional team and traditional tools.
Why this was needed
After years of incremental additions, the application carried the architectural layers of every era it had lived through. Modern React patterns had displaced the ones the app was originally built on. Bundled dependencies were aging out of support. A new feature could touch six libraries and four conventions before reaching production. The platform still ran reliably for thousands of researchers, but every change cost more than it should have.
How we approached it
Rather than rewriting, we modernized incrementally. The application kept shipping features throughout. There was never a point at which the system was half-broken. Every change shipped on its own merit, behind tests, lints, and type checks.
Andrew directed every architectural decision. Claude Code handled pattern translation at scale: bulk component conversions, dependency reference tracing, type generation, and the slow, mechanical work that compounds across thousands of files. The senior judgment was applied where it mattered: deciding what each piece of state actually represented, where to draw the line between legacy and modern data layers, and how to diagnose the latent bugs that surfaced when stricter checks were turned on.
What we modernized
React component model
Every component was converted from the legacy create-react-class API to modern React function components. The last legacy context bridges were replaced with React.createContext providers and custom hooks. React 18 StrictMode was enabled across the application, and the latent bugs it surfaced were resolved, including a memory leak in the Google Maps and d3 overlay teardown path in the Visualize module that had gone undetected for years.
State management
Baobab, the long-running global state container, was removed entirely. Each piece of state on the global tree was evaluated independently and migrated to the right home: local component state where appropriate, React Context where the state was genuinely cross-cutting, and TanStack Query where the state was server data that belonged behind a cache. The result is an architecture future maintainers can reason about without reading library documentation written a decade ago.
Data layer
Apollo Client and a Hasura GraphQL layer were introduced alongside the existing Django REST API. Reads have begun migrating to Hasura where its permission system can serve them more efficiently than the Django endpoints. Writes remain on Django for now. This is the strangler pattern as a deliberate architectural choice: the migration is not blocked on a full GraphQL rewrite, and the application kept shipping features at full pace throughout. A Hasura codegen workflow with end-to-end TypeScript types makes every new GraphQL query type-safe by default.
Forms
The legacy react-form-tools library was replaced with React Hook Form across every form in the application: contribute, questionnaire, editor console, visualize filters, region picker, and others. We developed a composite RHF and yup pattern for multi-step forms so a single useForm instance can drive an entire flow with branched validation. The Contribute flow is the canonical example.
Routing
The old hash-router pattern was retired in favor of React Router v6 with the modern data router. Splash and suspense states were centralized so navigation feels continuous instead of flashing between unrelated loading states.
Dependency cleanup
jQuery, Bootstrap, the legacy d3 wrapper, the bespoke form-tools library, the old yup package, multiple stale axios wrappers, orphaned types directories, and a long tail of supporting stale packages were all removed. The decision to remove each dependency was made by the senior engineer. The work of finding and rewriting every reference was AI-assisted.
Per-app polish
The Contribute flow was rebuilt as a single composite RHF form with per-step validation gates and localStorage persistence. The Questionnaire's answer-set, sub-question, and progress widgets moved off Baobab to modern Context. Browse received a search-as-separate-mode UX, debounced year filters, lazy-mounted maps via IntersectionObserver, and JavaScript-side sort fixes for the Elasticsearch search endpoint. Visualize received the StrictMode-safe Google Maps and d3 teardown, full-screen listener cleanup, and a fixed Quick Visualization timeline range. The Editor Console subtree was moved onto modern Context and React Query, with the Pending tab badge now reading a single preloaded count endpoint so it no longer flickers.
Why this matters for the business
The DRH platform now runs on a modern, supported, type-safe foundation. New features cost less to build. Onboarding a new engineer no longer requires learning a decade-old global state library. Production incidents are easier to diagnose because the surface area of legacy patterns has shrunk dramatically. And critically, none of this required taking the application offline or deferring research features while modernization was underway.
The work also demonstrates something we have written about elsewhere: AI coding tools pay off when senior engineers are directing them, and modernization is the category of work where the payoff is most measurable.
The Platform
To understand the DRH it is best to follow the path from expert registration to entry publication and analysis.
Questionnaire
The journey begins when an expert registers for an account. Once registered, and approved by an editor in the same field of study, an expert may begin completing a questionnaire.
Questionnaires consist of hundreds of questions that nest in complicated ways and vary depending on the user’s responses.
This is the heart of the DRH system and an area we spent a great deal of time improving to be faster, easier to use, and less daunting for experts.
Browse
Once the questionnaire has been answered, an expert can apply to have their entry published. Published entries are available to everyone, and we built an entirely new “Browse” tool to help with search and discovery.
The browse tool allows navigating entries by Author, Region or Religious group and provides, search, sorting and advanced filtering to speed up finding what you’re looking for.
We completely re-engineered this part of the app for speed and ease of use — the feedback so far has been phenomenal.
Try browsing DRH yourself.
Entry
When you’ve found the right entry it’s time to open up the Entry Detail view. This view wraps all the complexity of the questionnaire in an easy to navigate, reader friendly user interface. Read through an entry, jump the part you’re most interested in, download it for offline viewing or challenge the expert’s answer. It’s all possible in the new Entry Detail view.
Go check an example of an entry.
Editor Console
Behind the scenes of all this is an advanced management dashboard called the “Editor Console”. The editor console was purpose built to make it easier for DRH editors, directors and administrators to manage new registrations, existing experts, entries, polls, and the system at large.
Designing this tool required input from multiple members of the DRH team and a core understanding of the workflows and processes that were in place to keep the system operational. The results exceeded all expectations.
Visualization & Analysis
A long-standing priority for the platform has been advanced tools for visualization and analysis: where the database becomes a research instrument rather than just a repository.
The Visualize module is now StrictMode-safe and runs on the modernized React and data stack, ready for further analytical features to be layered on top.
Foundational Outcomes
The outcomes below reflect the major product improvements delivered to DRH over the course of our partnership, before and through the 2025–2026 modernization.
A more streamlined expert registration workflow
The old registration form had some critical flaws and left users with a bad first impression so the entire process was reviewed, revised and simplified so that experts now spend less time signing up and more time working on entries.
An entirely new Questionnaire interface
Convincing experts to share their knowledge isn’t easy, getting that knowledge into the DRH should be. The new questionnaire runs client side for super-charged speed, autosaves as the expert answers and provides a far more intuitive interface. 10 out of 10 experts agree — it is a dramatic improvement.
Browse, Filter, Search and Discover
Published entries are easier to find than ever with the new browse tool. Sporting advanced filtering, sorting, search and three different categories to browse, it’s a whole new way for scholars to discover new entries.
Entries redefined
Entries are large and the old interface used to take ages to load and navigating the complex structure was a chore. The new entry detail view is fast – more than 10X faster – and has dramatically improved navigation, readability and the ease of interacting with published entries.
For the Editors
As important as experts are in getting data points into the database, nothing gets published without the hard work of DRH editors. That’s why we designed them an ‘Editor Console’ that lets them see and control everything they need, all in one place. From approving new experts to publishing completed entries and everything in-between, the new Editor Console does it all.
Hyper Advanced Hosting and Dev Ops
The DRH ran on a basic server that was manually configured and updated via SSH. This was both insecure and provided ample opportunity for error since the production credentials were shared and there were many steps to the manual updates. We transformed the DRH’s antiquated setup by first containerizing the app with Docker, then creating an entirely new server setup configured with Ansible and hosted on Amazon. Finally we hooked it all up to our Continuous Integration (CI) and Continuous Delivery (CD) platform built with Gitlab. This is a seriously production grade setup.
Modernized for the next decade
In 2025–2026, the application's framework foundations, state management, data layer, and styling system were brought fully current, with senior engineers directing AI tools throughout. The platform is now running on a modern, supported, type-safe stack, ready for the next phase of features and growth.
The most obvious outcome is that everyone is now incredibly impressed by the platform when they see it, and experts enjoy interacting with the site and are experiencing much fewer problems.
Things are working so smoothly that we have experts we’ve never heard of signing up, getting approved, setting up their entries, completing the poll, and publishing completely without any hand-holding or glitches, which is simply wonderful and incredible.
Edward Slingerland, Project Director, Database of Religious HistoryProfessor at Department of Asian Studies, UBC
More Projects We Delivered
Innovative mobile application and web platform with integration to medical imaging and health data
Patient portal and web platform for Bodycomp Imaging–a leading provider of DEXA scans, utilizing superior Hologic scanners for high-resolution medical imaging
A web application for a technologically advanced, not-for-profit, sustainability project
A digital score keeping and record management web platform and iPad application for youth sports
A cutting-edge mobile app with bluetooth integration and intuitive UX or a leading precision measurement instrument manufacturer
The Sosido platform simplifies information exchange, fosters idea sharing, and enhances collaborations among healthcare professionals.