A multi-tenant product platform - shared foundation, per-tenant configuration, and industry modules. Travel is the first working vertical.
abstract placeholder - real visuals ship with the product
Client-facing business applications are mostly the same product wearing different clothes. A booking app for a travel agency, a patient system for a dental clinic, and a course platform for an educator share the same skeleton: accounts, tenants, admin tooling, domain records, operational views.
Building that skeleton from scratch on every project is the real cost - not the domain logic. Repicode exists to make the skeleton reusable.
A modular monolith in active development: a shared product foundation - identity, tenancy, RBAC, configuration, workflow - with industry modules built on top. The travel vertical is implemented end to end; dental and LMS remain target verticals.
03Complexity & Concurrency
4 case-specific challenges
Too generic and the platform does nothing; too specific and it's just one product with extra steps. The line that held: infrastructure is shared, workflow is configurable, domain logic lives in modules.
The travel module only proves the platform if it builds nothing twice. It reuses the foundation's organizations, customers, catalog items, transactions, payments, documents, workflow, audit and outbox - a second auth or tenancy system would break the premise.
Every 'just make it configurable' decision creates a schema you now have to maintain. Tenant configuration covers terminology, themes, feature flags, workflows, preferences and enabled modules - anything deeper belongs in a module, not a config flag.
Modules have to work without knowing about each other. The platform defines the contracts - tenancy, auth, data ownership - and each module implements its domain inside them.
04System Blueprint
Service boundaries / data model
Product Foundation
shared platform services
Industry Modules
implemented - dental & LMS are target verticals
Product Configuration
terminology · themes · feature flags · preferences per tenant
Client Product Instance
a configured vertical app per tenant
05Engineering Trade-offs
Deliberate choices made to preserve velocity without sacrificing correctness.
Travel is the first real module, and it had to prove the foundation can carry a vertical without parallel infrastructure - no separate app, microservice, or second auth/tenancy/payment/workflow system. It reuses all of them.
Every table carries organization_id, and cross-tenant relationships use composite foreign keys - (organization_id, id) - so referential integrity is tenant-safe by constraint, not by application-code convention.
Booking states from inquiry to departure are seeded as a global workflow definition all tenants share. The module gets lifecycle management and guarded transitions without building its own engine.
Booking creation accepts an Idempotency-Key for safe retries, and critical mutations run transactionally with audit, activity and outbox events - retryable and observable by default.
Each surface ships a dedicated OpenAPI spec - the travel spec alone covers packages, departures, bookings, payments, visas and operational endpoints. The frontend builds against the contract, not against assumptions.
06Surface Breakdown
Product surface / Repicode
Product surface / Repicode
Product surface / Repicode
07Project Status
Actively building. The foundation - organizations, RBAC, tenant configuration, workflow - and the travel module are implemented: 35 migrations, dedicated OpenAPI specs, and a booking lifecycle running end to end through the product frontend.
Travel is the first working vertical, not a launched product. Dental and LMS remain target verticals. Status: building.
Current project status
BUILDING08Retrospective & Takeaways
PROJECT INDEX / 09
The next chapter starts here