From research code to 1,000 users: rebuild, don't patch
Leading a 5-engineer team to turn a research LLM platform into Aideator, a production system with 20× the capacity.
Deliberatorium is a UM6P research platform that uses LLMs to structure large-scale deliberation. When I joined as technical lead it was research code: it topped out around 50 concurrent users, its research concepts weren't productised, and years of historical deliberations had to survive any change.
Re-architect instead of patching
Incremental fixes would have kept the scaling ceiling. With a 5-person cross-functional team, I rebuilt the full stack on React and TypeScript, FastAPI, PostgreSQL and Redis, deployed with Docker. More work up front, in exchange for removing the ceiling: the new system, Aideator, went from about 50 to more than 1,000 concurrent users.
Keep the history
Starting fresh would have been easier. But for a research platform, continuity is the value. I owned the end-to-end migration, ingesting the historical data while re-implementing research-paper concepts as production LLM features.
Standards before features
Early on I set Docker-based deploys, code review and CI practices. The first weeks were slower; after that, every engineer shipped the same way, and those standards were adopted across the project.
The takeaway
- If the ceiling is architectural, patches only move it slightly.
- A migration is a product decision: decide what must survive before you write code.
- Team standards are a multiplier; set them before the feature rush.