Apr 2026
Microfrontends with Turborepo and Vercel
I used the apps/users and apps/blogs applications in my Turborepo as independently deployable frontends, while still keeping a shared developer experience through common tooling, shared packages, and predictable deployment pipelines on Vercel.
Why I chose this structure
The main goal was to let different parts of the product evolve without forcing every UI change through one large frontend deployment. I wanted the users experience and the blogs experience to move at their own pace while still living in one repository.
Turborepo gave me the right monorepo foundation for that. It let me keep apps/users and apps/blogs separate as real applications, while still sharing code, TypeScript configuration, linting, and any reusable UI or utility packages from the workspace.
How the microfrontend setup worked
I treated each app as its own deployable surface. The users app focused on user-centric flows, while the blogs app owned the blog-related experience. That separation made ownership clearer and reduced the blast radius of changes.
Instead of duplicating everything, I leaned on Turborepo to share the foundation. Shared packages helped me keep common logic and conventions in one place, and Turbo caching kept local development and CI fast even as the repo grew.
Why Vercel fit the deployment model
Vercel worked well because each app could be deployed as its own project while still pointing back to the same repository. That gave me clean app-level deployments, preview environments for isolated changes, and a workflow that matched the microfrontend boundary I wanted.
In practice, this meant I could update the blogs app without coupling that release to users, and vice versa. The combination of Turborepo for workspace orchestration and Vercel for app-specific deployment made the architecture feel lightweight instead of over-engineered.
What this improved
The biggest win was team and codebase autonomy. Each frontend area had a clearer responsibility, deploys were easier to reason about, and shared code still stayed centralized instead of drifting apart.
This approach gave me the benefits of microfrontends without losing the productivity of a monorepo. I could keep consistency where it mattered, but still ship the users and blogs applications as independently managed experiences.