Why This Article Matters for FBT
FBT is not a single-product company. You are building a platform ecosystem — RentFlow as the SaaS product, Zentra as the identity layer, CatchMoment as an AI video product, and FIROSE Group's digital suite. All of these need to evolve independently, share infrastructure, and integrate with each other without becoming entangled. This is precisely the problem the article addresses.
Article Concept → FBT Application
Every concept in the article maps 1:1 to something FBT is already building or planning. Here's the complete translation table — what the article teaches vs. what FBT should implement, and where.
Host API
Controlled interface between core app and plugins
Plugin Lifecycle
init → mount → update → unmount lifecycle hooks
Independent Bundling
Each plugin compiled as its own Vite/esbuild bundle
Lazy Loading
Dynamic import() — load plugin only when user needs it
Security Model
Restricted API surface, permission boundaries
Hot-loading
Vite HMR for plugin live-reload during development
CI/CD for Plugins
GitHub Actions per plugin — lint, test, bundle, deploy
Project-by-Project Plugin Plan
Each FBT project has a specific plugin architecture story. The following details show exactly what to build, what the plugin host exposes, and which article concepts apply directly.
RentFlow
Zentra
CatchMoment
FIROSE Group
FBT Code Adaptations
Here's how to translate the article's code examples into FBT's actual Next.js 15 and React 19 stack, with Zentra security integration.
// fbt-shared/plugin-loader.ts — FBT Production Plugin Loader
import { use, cache } from 'react'; // React 19
// Strict allowlist — no arbitrary URLs
const PLUGIN_REGISTRY: Record Promise> = {
'owner-dashboard': () => import('@rentflow/plugin-owner'),
'manager-dashboard': () => import('@rentflow/plugin-manager'),
'resident-dashboard': () => import('@rentflow/plugin-resident'),
'superadmin-panel': () => import('@rentflow/plugin-superadmin'),
};
// Cache plugin promises — deduplicate concurrent loads
const loadPlugin = cache(async (key: string, hostAPI: RentFlowHostAPI) => {
const loader = PLUGIN_REGISTRY[key];
if (!loader) throw new Error(`Unknown plugin: ${key}`);
const { default: plugin } = await loader();
await plugin.init(hostAPI);
return plugin;
});
// React 19 — Suspense-native plugin component
export function PluginBoundary({ pluginKey }: { pluginKey: string }) {
const plugin = use(loadPlugin(pluginKey, hostAPI)); // Throws promise → Suspense
const Component = plugin.getComponent('Dashboard');
return Before vs After for FBT
FBT Implementation Roadmap
The article gives all the technical pieces. Here's the FBT-specific sequence — ordered to deliver value fast without a big-bang rewrite.
Start with Zentra. Write ZentraHostAPI and RentFlowHostAPI TypeScript interfaces. These are the foundation everything else builds on. No runtime code yet — just contracts. This is the article's "How to Define the Host API" applied to FBT's actual domain.
Move OwnerDashboard, ManagerDashboard, and ResidentDashboard into separate packages under packages/. Each gets a plugin.ts with init/unmount. The main app/ dynamically imports based on Zentra JWT role claim. Immediate bundle size win.
Create createSecureHostAPI(zentraToken) that derives plugin capabilities from live JWT claims. A Resident plugin that tries to register an Owner-only panel throws a typed error at init time. The security layer is Zentra-native, not custom-built.
CatchMoment's 8 repos already have natural boundaries. Formalise each as a CatchMomentPlugin with typed capabilities (gpu-inference, storage-write, highlight-generate). The event-service becomes the HostAPI orchestrator — loading the right pipeline plugins for each event type.
Add the GitHub Actions workflow the article describes — one per plugin package. Each runs type-check, lint, test, build, and a verify-contract script that confirms the plugin satisfies its HostAPI interface. Railway auto-deploys changed plugin bundles. Cowork sessions can target specific plugin packages with confidence.
Neat & Fresh, Femison, and AR Perfumes each get a content plugin. The FIROSE Group website becomes a plugin host. Division teams deploy their product catalog updates without a website release. Hot-loading in development lets marketing see live changes in the host context instantly.
When FBT Should NOT Use This
The article explicitly lists when plugin architecture is wrong. Let's map this honestly to FBT's situation.
Partly — early-stage features
New EduConnect or early-stage features should not start as plugins. Build monolithic first, extract when boundaries are clear.
Yes — some RentFlow flows
The resident onboarding QR flow is tightly coupled to the property assignment logic. Don't plugin-ise this — the coupling is load-bearing. Keep it in core.
Partly — CatchMoment GPU pipeline
The GPU inference hot path itself should not use plugin dynamic import — too slow. Load it eagerly at event start. Only the UI components are plugin-lazy-loaded.
Not applicable — Zentra handles it
FBT is in the clear. Zentra's OIDC token scopes provide exactly the security layer the article recommends. You already have the infrastructure.
Yes — new project kickoffs
When starting a new FBT project with Cowork, build monolithic first for 4–6 weeks. Once domains are clear, extract plugins. The Kickoff Prompt should scaffold conventional structure.