01 / 12
IAR Services × ZOOP
←→ or scroll

Git Gud:
one repo per product,
not one per service.

A simpler way to build and ship an entire product — proven on a live IAR Services product, and what it could look like for ZOOP.

Bhargav D
Engineer · building Claims
What I did with Claims

Scattered services → one repo + shared libraries.

0Claims services — separate, each repeating its own config & setup
enginecore claims API & lifecycle parseremail → structured claims intelligenceOCR & document AI visionML damage detection dashboardclaims processor web UI analyticsreporting dashboards pulseinternal support tooling sparkboardprototyping workspace
0repo — services kept, shared code pulled into libraries
claims/
services/  sorted by language
engineparserintelligence visiondashboardanalytics pulsesparkboard
packages/  ← extracted shared libraries
eslint-configtypescript-configpy_toolkit
Let's define it — no jargon

One git clone.
Every service inside.

A monorepo is a single repository holding many independently-deployable services — each in its own folder, its own owner, its own code. All that changes: they share one root, one history, and one pull request when a change spans two of them.

It is not
One giant tangled program where everything imports everything. Services stay separate, separately owned.
It is
Many services, one workspace — with tooling that only builds, tests, and deploys what changed.
The repo boundary should match the product — not the service.
Same services, same owners. One home, one history.
The difference, concretely

Same services.
Different coordination cost.

 
Per service
Per product
Cross-service change
N PRs, N reviews — hope they land together
1 PR, 1 review, lands atomically
Tool versions
Drift silently — each repo pins its own
Pinned once, enforced everywhere
Shared code
Copy-pasted, or bumped by hand
Imported directly, always current
New-hire setup
Clone N repos, follow N READMEs
Clone once, one setup command
The services don't change. The coordination does.
Every row is the same work — just fewer places to do it, and nothing left to drift out of sync.
Not a religion — a judgment call

When it's worth it. When it isn't, yet.

Good fit

  • Services that ship features together
  • One team, or tightly-collaborating teams
  • Shared UI, config, or types across services
  • Onboarding pain is already recurring

Weak fit — for now

  • Totally separate release cadence + audience
  • Acquired code not yet in the workflow
  • No shared reviewers or roadmap
  • A standalone tool nobody else touches
Claims is a textbook good fit.
One team, shared config & types, services that ship features together — every box ticked.
Four layers, not four rivals

The tools that make it fast, not painful.

miseversion manager · the foundation
Pins the exact Node, Python, Go, pnpm version per service. One command → every version matches.
pnpm workspacespackage layer
Shared packages live once, not copy-pasted — every service imports the current version.
Nxpolyglot orchestrator
Multi-language graph + affected + caching. Powers Claims.
TurborepoJS/TS orchestrator · Vercel
Pure JS/TS — simpler, remote caching. Powers ZOOP UI.
Four layers, not four rivals.
mise underneath both. Claims runs Nx, ZOOP UI runs Turborepo — same discipline, right tool per stack.
The part people worry about most

One pipeline. It only touches what changed.

STEP 01
Push / tag
Commit lands on develop or a version tag
STEP 02
Detect affected
Tooling lists the changed projects
STEP 03
Build + test
Only affected services run — rest skipped
STEP 04
Deploy selectively
Each affected service ships independently
.github/workflows/ci.yml live in Claims today
# job: detect — computes what actually changed
AFFECTED=$(pnpm nx show projects --affected --base=HEAD~1)
# → only these projects build, test, and deploy
Change one service. Build one service.
The pipeline asks the tooling what's affected, then acts only on that — a monorepo doesn't mean rebuilding everything.
This is how the biggest teams already build

Not fringe. The default at scale.

G Google
0
commits a day into one repo — about 24K of them automated. 2B lines of code, 25K engineers, one source of truth.
CACM 2016 · Potvin & Levenberg
M Microsoft
0
files & 300 GB in one Git repo for Windows. Their tooling cut git status from 13s → 2.7s at that scale.
MS DevBlogs · "largest Git repo," 2017
M Meta
10s of M
files, commits & branches — one of the largest repos anywhere. Built Sapling + a virtual filesystem to run it.
Meta Engineering · Sapling, 2022
Not a pitch — two of our repos already run this way

We're already doing this, today.

Case 01 · full product line

Claims

Nx + mise · API, dashboard, ML, email — the whole product
0
services
0
.git size
0
languages
Case 02 · frontend library

ZOOP UI Platform

Turborepo + mise · pnpm workspaces
0
packages
0
.git size
0
commits
One real commit. 4 packages. One review.
chore(common): update configuration (#146) — React & Svelte consumers updated atomically, in one history.
ZOOP UI Platform · live
The advantage that matters at the product level

A small team + AI agents can drive a whole product.

Cost
Fewer engineers to ship the same product. One person, backed by agents, owns a full vertical — not one repo of it.
AI leverage
Split repos wall agents off — they see one repo, can't propagate a change, lose context at every boundary. One repo = whole-product context in a single window.
Team
A new hire — or a new agent — is productive in one clone. No tribal knowledge locked in whoever owns "the other repo."
0
services in one real PR, one review
0
clone → setup → dev → running
0
version-drift incidents since mise
0
an agent sees the whole product
One worked example — if we applied this to ZoopSign

Here's the folder ZoopSign would get.

zoopsign-platform/ ├── apps/ // what users & admins open │ ├── raftel/ signing dashboard │ ├── luffy/ marketing site │ └── zsp-admin-portal/ internal admin ├── services/ // backend platform │ ├── skypiea/ core backend │ ├── kaido/ eStamp management │ ├── esign/ Aadhaar eSign gateway │ └── egghead/ coin / billing ├── sdks/ // published, built together │ └── kaido-sdk/ └── infra/ └── marine-ford/ Azure provisioning + ops
What we get
A skypiea API change and its raftel fallout ship in one PR — reviewed together, atomic.
Ownership
Folder-level CODEOWNERS — same as today. Each team still reviews its own service.
Reversible
Git history splits back out cleanly. Not a one-way door.
Beats "big"
kaido alone is 239 MB today. Claims — 10 services merged — is 125 MB total.
Why this matters for the team that owns it

Do more product,
with fewer people.

The point isn't tidiness — it's leverage. A product in one repo is a product a small team, amplified by AI agents that see all of it at once, can actually own end to end.

For the team
One clone, one mental model. Ship across signing, billing & the dashboard in a single PR — no coordination tax.
For the budget
The same product needs fewer hands. Headcount goes to features, not to keeping 15 repos in sync.
For AI delivery
Agents work the whole product in one context — the multiplier that lets a lean team punch above its size.
Start small: 3 repos, one product, 4 weeks Reversible — not a one-way door Proven in Claims + ZOOP UI