The Monorepo Strategy for Multi-Platform Startups

When I joined AssetPool as fractional CTO, the team was maintaining three separate codebases: a Vue.js web app, a Flutter mobile app, and a Node.js API. Every feature shipped three times. Bug fixes required three PRs. The cognitive overhead was crushing a team of five.

The Problem With Separate Codebases

It’s not just the duplication — it’s the drift. Over time, each codebase develops its own conventions, its own abstractions, its own bugs. The web app validates email addresses differently from the mobile app. The API returns error formats that one client handles but the other doesn’t.

This isn’t a tooling problem. It’s an architecture problem.

One Repo, One Truth

We consolidated everything into an Nx monorepo:

apps/
  web/          # Vue.js SPA
  mobile/       # Flutter app
  api/          # NestJS backend
libs/
  shared/       # TypeScript types, validators, constants
  ui/           # Shared component logic
  api-client/   # Generated API client

The libs/shared directory became the single source of truth. Every validation rule, every enum, every business constant lives there and is imported by all three apps.

What Changed

Feature velocity doubled — shared types and validators meant less per-platform work
Bug surface shrank — a fix in libs/shared fixed all platforms simultaneously
Onboarding improved — new engineers learned one repo structure, not three

The Hard Parts

Monorepos aren’t free. The CI pipeline needed careful optimization — we used Nx’s affected commands to only build and test what changed. Flutter’s Dart code couldn’t directly share TypeScript types, so we built a code generation step that produced Dart classes from our TypeScript interfaces.

The investment paid for itself within the first quarter.

If you’re running a startup with fewer than 20 engineers and shipping to multiple platforms, a monorepo isn’t optional — it’s survival.