Open Mercato
The AI-native TypeScript framework for building CRM, ERP, and commerce backends with modules, multi-tenancy, and RBAC baked in.
Repository Health
Technical Analysis
Open Mercato is a TypeScript foundation framework for building CRM, ERP, and commerce backends on Next.js. It ships opinionated conventions for modules, dependency injection, multi-tenancy, and access control, so teams — and their AI coding assistants — spend less time re-deciding architecture and more time shipping business logic.
Every feature lives under its own auto-discovered module with pages, APIs, CLI commands, i18n, and MikroORM entities scoped by convention. A per-request Awilix DI container, built-in RBAC, and strict tenant/organization scoping on every entity mean new modules inherit the same security and structure as the core, whether they ship ready-made CRM/ERP domain logic or are authored by the team building on top of it.
What You Get
- A modular monorepo structure where every feature — pages, APIs, CLI commands, i18n, and database entities — lives under its own auto-discovered
src/modules/<module>directory - Multi-tenant data model by default, with
tenant_idandorganization_idscoping enforced on core entities and a built-in organization hierarchy - Feature-based RBAC combining per-role and per-user flags with organization-level scoping, backed by JWT sessions and bcrypt hashing
- Ready-made CRM/ERP domain modules (customers, checkout, content, onboarding) you can extend instead of building from scratch
- A
create-mercato-appCLI scaffolder for starting a standalone app on top of the framework without touching the core
Common Use Cases
- Building a headless commerce or CPQ backend that needs multi-tenant order and customer data models out of the box
- Standing up an internal CRM or ERP admin panel with role-based access control and custom entity definitions
- Giving an AI coding assistant (Cursor, Claude Code, Codex) a fixed set of architectural conventions so generated code lands in the right module instead of sprawling
- Spinning up self-service customer or partner portals with configurable forms and workflows per tenant
Under The Hood
Architecture
Every feature lives under its own auto-discovered src/modules/<module> directory, carrying its pages, APIs, CLI commands, i18n dictionaries, and MikroORM entities together — there’s no central route table or global schema to hand-wire. A per-request Awilix DI container is constructed for each request, and modules register or override services through a local di.ts, so overriding core behavior doesn’t mean forking the core. The directory module defines tenants and organizations as first-class concepts, and most entities carry tenant_id + organization_id, enforced at the data layer rather than left to application code to remember. Authorization layers on top as feature-based RBAC combining per-role and per-user flags with organization-level scoping.
Tech Stack
TypeScript in strict mode throughout (tsconfig.base.json, ES2022 target, decorators enabled for MikroORM), built on Next.js App Router. Data layer is MikroORM 7 against PostgreSQL, with Awilix 13 for dependency injection and Zod 4 for validation. Background work runs through Redis-backed event subscribers; search is powered by Meilisearch. The bundled AI Assistant module (packages/ai-assistant) is built on Vercel’s ai SDK. The whole monorepo (apps/, packages/, plus an official-modules external workspace) is orchestrated with Yarn 4 workspaces and Turborepo for cached, parallel builds.
Code Quality
901 test files under packages/core/src alone is a substantial investment for a framework this size, run via Jest. The team maintains a custom ESLint plugin (packages/eslint-plugin-ds) specifically to enforce design-system conventions across the UI layer, on top of a standard eslint.config.mjs. CONTRIBUTING.md documents a formal main/develop/topic-branch model and requires checking for an existing spec under .ai/specs/ before implementing significant changes — a “spec-driven development” discipline that’s unusual to see codified this explicitly in an OSS repo.
API Design
Two clearly documented onboarding paths: clone the monorepo to work on the core (yarn dev:greenfield), or run npx create-mercato-app my-app to build on top of it without touching core code — each with copy-pasteable setup for macOS/Linux/Windows. The convention-over-configuration model means a new module just needs to exist under src/modules/ to be picked up; there’s no manual route or DI registration step. The tradeoff is real infrastructure to stand up before writing any code — Node 24, PostgreSQL, Redis, and Meilisearch (Docker Compose is provided to ease this) — which is a heavier bar than a typical single-purpose library. A hosted live demo and full Docusaurus documentation site (docs.openmercato.com) let evaluators get a feel for the product before committing to the local setup.