When Is the Right Time to Use Microfrontends?

Most teams ask "should we use microfrontends?" too early.

A better question is: what pain are we trying to remove, and does frontend splitting actually remove it?

I have been working through this exact decision while refactoring Portal and related products, so this post is the practical version of that answer.

What microfrontends are (in plain terms)

Microfrontends are a way to split a large frontend into smaller, independently developed and deployed frontend applications.

Instead of one giant UI deployment that owns everything, you organize by feature domain:

• a shell app (navigation, auth context, layout)
• domain apps (CRM, Support, Page Builder, Strategy Builder, etc.)
• shared packages for primitives, contracts, and design system

The key benefit is not "cool architecture."
The real benefit is independent change velocity:

• develop one domain without touching unrelated domains
• deploy one domain without redeploying the whole platform
• reduce blast radius when shipping changes

My starting point: frontend monolith + plugin-heavy product

Originally, the Portal frontend was monolithic.

That is interesting because the product itself was already heavily modular in behavior:

• 10+ plugin domains
• each plugin adding completely different functionality
• plugin model similar to WordPress extensibility

On the backend, we already had meaningful separation through Convex components.
On the frontend, everything still lived in one deploy surface.

That was fine to get launched and validate with early clients. It was the right decision at that stage.

The trigger: page builder across all post types

The pressure point showed up when I wanted to build a page builder that worked across any page or post type, similar to WordPress + Elementor.

For example, the CRM plugin adds post types like:

• Contacts
• Marketing tags
• Email campaigns

When Portal plugins register post types, those post types are Puck-enabled so the same builder experience can be reused.

That page builder capability was cross-cutting. It was not "owned" by just one plugin.
I wanted to build and iterate on it without putting existing deployed systems at risk.

Platform economics matter more than architecture opinions

At the same time, cost and deployment constraints became real.

Portal was on Vercel and already pushing the practical limits of the $20/month plan for the way this product evolves.

At that time, the economics were roughly:

• one microfrontend included
• each additional microfrontend around $200/month

That model worked for a Portal/Puck split, but not for aggressively splitting every feature domain into its own frontend deployment.

So the decision was not purely technical.
It was: can the deployment model and pricing support the architecture we actually need?

Why I changed infrastructure direction

More recently, I canceled several small VM subscriptions and consolidated onto a larger bare metal server.

That was a major shift for me because it also meant taking direct control over:

• networking
• deployment topology
• runtime isolation choices
• cost allocation by domain

Networking and infra control was an area I had less experience in before, but this move unlocked architectural flexibility that platform pricing tiers were constraining.

Now I can split frontend domains according to product needs, not according to a third-party plan limit.

What the migration looks like now

I am actively migrating Portal from frontend monolith toward domain-separated frontend apps that talk to a shared Convex backend.

The practical outcome is simple:

• I can develop and deploy only CRM changes
• I do not need to redeploy the entire Portal frontend for every domain update

Previously, even with Turbo cache and Vercel premium builders, feature changes in the large Portal app were often taking 4-5 minutes to deploy.
I was burning $40+ in Vercel build time credits largely because the app had to carry many use cases and many plugin dependencies in one deployment path.

Now, with domain-level frontend deploys:

• deploys are faster
• cost is lower
• those savings are centralized into infrastructure I control

I am paying less monthly and have more flexibility to shape deployment around project constraints rather than provider packaging.

When microfrontends are actually the right move

In my experience, microfrontends start paying off when most of these are true:

1. Many distinct feature domains with weak day-to-day coupling.
2. Different release cadences across domains.
3. High deployment blast radius in current monolith.
4. Growing build times/costs tied to unrelated changes.
5. Clear backend contracts (APIs/components/events) so domain UIs can be isolated safely.
6. Org readiness to maintain platform standards across multiple frontend apps.

If those are not true yet, a monolith is usually better.

When monolith is still the better answer

For many products, Vercel + monolith is still a great choice.

I still use that model where it fits.

For example, straightforward single-target apps (with or without multi-tenancy) often do not gain enough from microfrontend splitting yet:

• ADAscout
• Myladdr

But larger platform-style products with multiple control planes and domain-heavy feature sets do benefit:

• Portal with 10+ plugin domains + Puck page builder
• TraderLaunchpad with AI strategy builder and platform modules
• LaunchThatBot with multiple control-plane surfaces

Reuse flywheel: from feature idea to cross-app domain

One of the biggest advantages of my current structure is the domain reuse loop:

1. Identify a new app/product domain (example: CRM).
2. Build that domain first as a standalone app (example: LaunchThatCRM).
3. Package that logic into a plugin package with UI primitives + Convex component.
4. Integrate it into other apps as a separate frontend deployment.
5. Keep development focused on that domain only, with cleaner testing harnesses and faster release cycles.

That means the same CRM and Support domains can be mounted in multiple environments:

• subscription SaaS platforms
• standalone deployments
• constrained environments that cannot use third-party managed services
• internal tools and passion projects

Real structure examples

Today, one platform deployment can look like:

• Portal (main shell)
• Puck page builder microfrontend
• CRM microfrontend
• Support microfrontend

TraderLaunchpad can follow a similar pattern:

• TraderLaunchpad (main shell)
• Trading Strategy Builder microfrontend
• CRM microfrontend
• Support microfrontend

And I can still run standalone apps with direct plugin mounts:

• LaunchThatCRM (direct CRM plugin UI/component)
• RocketDesk (direct Support plugin UI/component)

That modularity keeps features portable and testable across different product contexts.

Final take

Microfrontends are not a badge of engineering maturity. They are a trade-off.

Use them when your product has truly become a multi-domain platform and monolithic frontend deployment is now your bottleneck in speed, cost, or safety.

If you are still validating product shape, keep things monolithic and move fast.

If you are already managing many domain surfaces, many release rhythms, and rising deployment costs, microfrontends can turn frontend architecture from a bottleneck into a multiplier.

The right time is not when it sounds advanced. The right time is when your current architecture is measurably slowing the business down.