How Gera Thinks About Shared Infrastructure

Published 21 April 2026 · 10 min read · Gera Services

Quick answer: Every Gera product shares the same 15+ core packages: auth, payment, database, notification, AI, analytics, compliance, localization, search, storage, UI components, and testing. One implementation, 31 consumers. This is the single largest reason our per-product cost is a fraction of a standalone startup's.

The principle

Build once, use everywhere. Any capability that more than one product needs belongs in a shared package. The cost of maintaining that package is amortised across every product that imports it. The benefit of quality improvements compounds — a bug fix in core-auth improves 31 sign-in flows at once.

The 15 packages

core-auth — JWT, refresh tokens, OAuth, 20-country login picker.
core-payment — Stripe, Idram, M-Pesa, UPI, PIX, iDEAL routing.
core-database — Prisma client, migration discipline.
core-notification — email templates, SMS, push.
core-ai — Claude / GPT / Gemini wrappers, prompt versioning.
core-analytics — PostHog, GA4, custom events.
core-compliance — GDPR, consent logs, DSAR.
core-localization — i18n, hreflang, RTL.
core-search — Elasticsearch, faceted search, reranking.
core-storage — S3/MinIO with signed URLs.
core-testing — shared Jest + Playwright fixtures.
ui-components — 200+ React / React Native components.
tailwind-config — shared design tokens.
shared-types — TypeScript types mirrored across services and apps.
data-scrapers / job-scraper — cross-product data ingestion.

Why monorepo, not microservices-microrepos

Each approach has trade-offs; we picked monorepo for three reasons:

Type-safety across product boundaries. A field rename in shared-types is caught at compile time for every consumer.
Atomic changes. Rolling out a new GeraCoin rewards API is one PR, not 31 coordinated PRs.
Discoverability. New engineers can read any product in the same editor.

The trade-offs

Build times. Turborepo caching is essential. Without it the monorepo is slow.
Regression blast radius. A bad change in core-auth can take down everything. We ship with feature flags and staged rollouts.
Dependency bloat. One package upgrading a dep can affect 31 products. We keep upgrades deliberate and tested.
Repo size. Larger clone, larger CI. Acceptable trade-off.

What we do NOT share

Business logic unique to one vertical lives in that service. GeraClinic's doctor credentialing flow has nothing to do with GeraHome's handyman bookings. We resist the urge to over-generalise — premature generic abstractions are worse than copy-paste.

The compounding effect

In year one, each shared package paid back for itself after 2-3 products. By product 31 each package has paid back more than 10x. New product 32 costs fractionally the effort of new product 2. That is the economic engine of the portfolio.