Galaxies Survey Builder
A game research platform backoffice rebuilt from scratch in three weeks — full schema compatibility, surgical state management, and admins who no longer needed a developer to do their job.
- TypeScript
- React
- GraphQL
Galaxies was building a research intelligence platform for the Brazilian gaming industry — aggregating survey responses from gamers and turning them into market insights for studios and publishers. The backoffice that powered that research depended on a survey builder that had grown fragile: administrators had to guess at the interface or loop in the original developer to understand how it worked.
I was brought in to own the full rewrite of that survey builder, from v1 to v2, against a three-week deadline with a fully remote team of five.
The Constraints
The v1 builder had an established schema already in use across every existing survey. Any rewrite had to maintain full backward compatibility — forms already saved in the database had to load correctly in the new UI, and anything new had to remain parseable by the same downstream form renderer. Changing the schema was off the table.
The v1 implementation also loaded and tracked too much state in bulk, which caused performance issues as forms grew — a problem that had to be solved without breaking anything upstream or downstream.
Backoffice
Rebuilding the survey builder
Designed and built the v2 survey builder from scratch. The page let administrators configure every aspect of a research question dynamically: category, image, caption, question type (free text, multi-select, and others), accessibility metadata, and i18n strings — all in a single interface.
I redesigned the state model to be surgical, tracking only what was actively being edited rather than holding the entire form in memory. The architecture drew from patterns built at FDTE for similar form-heavy interfaces — favoring simplicity and predictability over generality.
The hardest constraint was schema compatibility: new output had to be parseable by the existing renderer, while every form already in the database loaded correctly without migration.
The v2 shipped to production within the deadline. The most meaningful outcome was usability: administrators could configure surveys independently without asking the developer who wrote v1 what the fields meant.
Technologies
- React — component tree for the dynamic survey builder
- Material UI — design system used throughout the backoffice UI
- GraphQL — queries and mutations for loading and persisting survey configurations
- TypeScript — end-to-end type safety across the form schema
Technical Highlights
- Schema-compatible rewrite — the new UI had to produce output parseable by the existing renderer and load all legacy forms without migration, making backward compatibility the main design driver
- Surgical state management — v1 held the entire form in memory; the rewrite tracked only the active edit scope, eliminating the performance issues that made the old builder slow on complex surveys
- Architecture from prior patterns — modeled after form systems built at FDTE, favoring a simple, predictable structure over a generic one