Appinio's People Team · 30.05.2025 · 12min read
At Appinio, we're constantly pushing the boundaries of market research, delivering insights from over 190 markets and collecting millions of opinions every day. To keep up with this rapid growth and our "Think 10x" mindset, our engineering practices need to be just as agile and efficient. In this post, our Expert Engineer Mohi shares how we transformed our chaotic development workflow into a single streamlined Nx monorepo.
The old setup: A tale of dependency chaos
Before our monorepo journey, our frontend setup included four separate Angular projects and three shared npm libraries, spread across different repositories. In theory, this modular approach seemed solid. In practice, it caused what we called "dependency chaos."
Each library had dependencies on the others, and updates triggered a slow, manual chain of version bumps and syncing. These moments that we called "freeze mode" brought development to a halt. Urgent hotfix? Blocked. QA waiting on changes? Blocked. New feature ready to merge? Blocked.
This wasn't just a technical issue, it impacted our speed, developer happiness, and ability to deliver value.
The "Nightmare of Bumps & Syncs": We had to wait for changes in each library to be merged and released before manually updating our main projects. Because of internal dependencies, this had to follow a strict order. Only after this complex syncing process was our main dev branch finally "clear" and safe for everyone to start building new features without clashing with outdated dependencies.
It became clear that this setup couldn’t scale with our ambitions.
The real cost of "Dependency Chaos": Impact on our developers and speed
Beyond the sync issues, our multi-repo setup (4 separate repos, 3 shared npm libraries, and over 6 GitHub Actions) seriously disrupted daily work at Appinio. This wasn’t just a tech problem - it also slowed us down, frustrated our developers, and blocked us from delivering value quickly.
Onboarding? A Maze:
New hires walked into a web of disconnected projects. Instead of building features, they had to spend valuable time understanding and setting up multiple, disparate codebases, each with its own intricacies.
Everyday Work Was Slower:
- Tech updates were a marathon: Want to upgrade Angular or a key library? That meant repeating config, testing, and deployment across every project, which was an exhausting, error-prone process.
- Context switching chaos: Developers constantly switched between projects, making sure they were in the right repo for the task. If a feature touched multiple libraries, the work multiplied and changed across several repos, separate pull requests, and independent reviews all before one feature could be finished.
- Testing & deployments were painful: Setting up tests and managing deployments for each repo was tedious. One failure meant re-running everything.
This overhead killed momentum. As many of us noticed, our delivery pace lagged behind our potential. Even urgent hot fixes forced us to pause everything and development literally froze. Not ideal for anyone.
The search for a smarter way: Why we chose Nx
It became clear our current setup wasn’t scalable. Managing multiple disconnected codebases created constant friction and slowed us down. This pain surfaced repeatedly in team retros, prompting us to search for a better solution.
Since we use TypeScript and Angular, our research quickly led us to monorepos which is a single codebase for all apps and libraries. Big names like Google and Meta use this approach to boost speed and efficiency.
At first, we looked into Lerna, a once-popular tool for JavaScript monorepos. But it had become slow and poorly maintained. Thankfully, I had recently worked with both Lerna and Nx, so we spun up a POC with Nx and were instantly impressed.
Building a monorepo system from scratch didn’t make sense when Nx already offered a mature, community-backed solution. So why did we choose Nx?
- Smart monorepo management: Nx isn’t just one big folder, it brings structure. It helps manage multiple apps and libraries in a single repo with clear boundaries, efficient tooling, and automation.
- Great angular support: Nx offers first-class support for Angular, making it a natural fit for our existing technology stack. Beyond Angular, it supports various other frontend frameworks and even backend technologies, providing a future-proof foundation.
- Speed where it matters:
- Affected commands: Nx intelligently detects only the code that has changed and its direct dependencies. This means we only build, test, and lint the affected parts of our project, dramatically saving time. You won't even "feel" the performance impact as we add more and more code to the base.
- Caching & Orchestration: If code hasn’t changed, Nx skips unnecessary work. It also runs tasks in the smartest order, automatically.
- Distributed execution: Nx can spread heavy tasks across machines to get things done even faster.
- Consistent, scalable workflows: With built-in generators and strict tooling, Nx ensures every part of the codebase stays clean, consistent, and easy to work with.
Most importantly, Nx freed us from "freeze mode". No more waiting on syncs or managing endless branches. We can now develop and release features continuously with fewer roadblocks and more confidence.
The Monorepo migration: Smooth sailing (mostly!) and what we learned
Migrating to the Nx monorepo was a big move but surprisingly smooth. Thanks to a clear plan and prior experience with similar migrations, the process was structured, efficient, and, honestly, felt pretty straightforward.
We used the opportunity to upgrade to the latest Angular version, fixing technical debt and adopting new features. We also set strict coding standards (with ESLint and TypeScript) from the start to keep code quality high across the board.
One of the biggest success factors? Tight collaboration with our DevOps team. By aligning early, we created scripts, agreed on naming conventions, and avoided surprises. Nx’s flexibility also helped and it works naturally with Angular CLI, so our workflow didn’t break.
The actual migration? Core codebases moved over in just two hours. The team then dedicated a sprint to polish, test, and fine-tune the new setup. The significant win here was moving to a single, unified setup for all our linters, tests, end-to-end (e2e) tests, and builds – a stark contrast to our previous fragmented approach.
There were a few hiccups with some hidden quirks in old code that needed manual fixes, but nothing major. Overall, it was more time-consuming than difficult.
We also tackled the learning curve head-on. I ran internal tech talks to introduce Nx and share best practices. These sessions helped the team understand not just the how, but the why and this made a huge difference in adoption.
In the end, this well-planned migration laid the foundation for a faster, cleaner, and more consistent development experience which finally freed us from "freeze mode" for good.
The “After” State: Unlocking Speed and Confidence at Appinio
Once the Nx monorepo was live, the impact was immediate and exactly what we had hoped for. Like many other teams, we embrace Agile development and Scrum, and our core desires were always for speedy, continuous development, and the ability to go live with new features whenever we desired. With Nx, that vision became reality.
Since the migration:
- We’ve created almost 200 pull requests in record time.
- Our productivity has doubled, with 2x more story points delivered per sprint compared to before. ( "points per sprint" is our team's way of measuring the amount of work we successfully complete within a two-week development cycle)
That means we’re not just working faster but we’re tackling more complex features and delivering real value, sprint after sprint. Confidence is up, blockers are down, and the numbers speak for themselves.The Nx monorepo has not just reorganised our code; it has fundamentally transformed how we work, enabling Appinio to accelerate feature delivery, enhance collaboration, and embrace our "Think 10x" mindset with renewed vigor.
The Monorepo Revolution: What It’s Meant for Us and What It Could Mean for You
Our journey to the Nx monorepo has been transformative. What started as a solution to "dependency chaos" has evolved into a cornerstone of our engineering philosophy at Appinio.
Today, our teams work without the stress of "freeze moments," shipping features the moment they're ready. It's not just a technical upgrade, it’s a cultural shift that’s empowered our developers and accelerated how we deliver value.
We were so proud of the transformation that we shared our journey at Angular Berlin. It was a chance to spotlight the exciting engineering work at Appinio and connect with other passionate developers. We’re now expanding this approach beyond frontend, introducing monorepo benefits to our backend and mobile teams as well.
This move has been more than just a success, it’s shaped the way we build, collaborate, and grow. And we’re just getting started.
Our Advice to You
If your team is facing the pain of tangled code, "freeze moments," or scattered repositories, we strongly recommend giving the monorepo approach a serious look with Nx as a top contender.
Yes, change can feel daunting. But the improvement in developer experience is worth it. A happier, faster team is a more proactive team, ready to move with what we at Appinio call a “Think 10x” mindset.
Some teams avoid big shifts like this. We’re here to say: lean in. The payoff isn’t just cleaner code, it's more flexibility, faster delivery, and a stronger connection between your tech and your business goals. For us, it’s been a game-changing step forward. It might be for you too.
And if you're passionate about building smart, scalable systems we’re hiring! We'd love to hear from engineers who are excited about shaping the future of tech at Appinio.
