Movr is more than just a fitness app; it’s a “movement health” platform designed to assess individual biomechanics and prescribe personalized corrective exercises.
In 2024, I joined the team as the Principal Engineer, reporting directly to the CTO. Unlike previous roles where my focus was often purely on shipping features, my mandate at Movr was broader: to mature the engineering practices, solidify the architecture, and ensure the platform was robust enough to handle rapid scaling and enterprise partnerships.
Operating as a Principal Engineer meant constantly zooming in and out. One hour I might be deep in the weeds of a complex database query, and the next I’d be in a strategic meeting discussing the roadmap for the next quarter.
Working directly under the CTO allowed me to have a significant impact on high-level decisions. We weren’t just writing code; we were designing the factory that produces the code. My goal was to create an environment where features could be delivered quickly without sacrificing stability or increasing technical debt.
A major part of my work involved optimizing our cloud infrastructure. We leaned heavily into a Serverless architecture using AWS Lambda.
We used DynamoDB as our primary data store. NoSQL offers incredible performance, but it requires disciplined access patterns. I worked on optimizing our data models to ensure that as our user base grew, our query latency remained low. This involved restructuring how we stored user sessions and workout history to prevent “hot partitions” and ensure efficient retrieval.
The most technically interesting project I worked on at Movr was one that started as an annoying pattern.
Every time we onboarded a new enterprise partner, they needed customized exercise logic: different progressions, localized content, branded variations. The old system handled this through exceptions: if-statements, overridden records, special-cased queries. It worked for one partner. At two partners it was uncomfortable. At three it would have been a maintenance problem. We could see the ceiling.
The solution was to redesign the system around a “Base + Override” structure, similar to Class Table Inheritance. Instead of special-casing partner logic in code, we gave the data model a hierarchy:
At runtime, a resolution engine walks that hierarchy and returns the most specific applicable record for the current user’s context. Looking for a French version of a partner’s squat exercise? It checks for Partner-Localized first, falls back to Partner-Default, then falls back to Global. The logic is explicit and predictable.
What made this genuinely interesting was making the engine schema-aware, rather than hard-coding it to specific tables, it could map to any database column at design time and evaluate those mappings dynamically at runtime based on the user’s current partner context. Adding a new partner with a new set of overrides required no new code. It required configuration.
The real beneficiary was the clinical team. Previously, onboarding a new enterprise partner required engineering involvement for every custom logic permutation. After the rules engine, the physiotherapists and clinical leads could build and iterate on adaptive treatment flows independently. The engineering overhead for new B2B contracts dropped significantly, which at Movr’s stage was the difference between a partnership being feasible or not.
The migration itself was careful. We built the new system in parallel with the old one, wrote tests that verified both produced identical output for existing cases, and cut over gradually. The “official” migration was quiet: by the time we flipped the switch, the new engine had already been running alongside production for weeks.
Technology is only as good as the team and processes behind it. A significant portion of my energy went into strengthening the “internal product”: the developer experience.
I championed a shift toward full test coverage. We moved away from the idea that testing is a “nice to have” and integrated it into the core definition of done. By implementing rigorous unit and integration tests, we gave the team the confidence to refactor complex logic without fear of breaking existing functionality.
To maintain high velocity, we automated everything we could. I helped refine our CI/CD pipelines (using GitHub Actions) to ensure that code was automatically linted, tested, and deployed. This reduced the “deployment anxiety” that often plagues teams and allowed us to release updates to users multiple times a week.
I believe that a senior engineer’s job is to make themselves redundant by sharing knowledge. I spent time creating detailed technical documentation and standard operating procedures (SOPs). This wasn’t just about “how to run the code,” but “why we built it this way,” ensuring that future engineers could understand the architectural decisions we made.
My time at Movr was a masterclass in balancing immediate product needs with long-term technical health. We successfully delivered critical features to end-users, improving their movement health, while simultaneously rebuilding the engine in flight.
Leaving the codebase cleaner, faster, and more robust than I found it is always my goal, and at Movr, I believe we achieved exactly that.
emanuelpetre.dev