# Open Mercato: a TypeScript CRM/ERP foundation built for AI coding agents

> Open Mercato is an MIT-licensed TypeScript framework that fixes multi-tenancy, RBAC, events and module layout as conventions so Cursor, Claude Code and Codex generate features instead of arguing about architecture. It ships CRM, ERP and commerce modules, but its own README is still the main map.

**open-mercato/open-mercato** — The AI-Engineering Foundation Framework for CRM/ERP and commerce: open-source TypeScript, with multi-tenancy, RBAC, events and domain modules already decided as conventions and specs, so Cursor, Claude Code and Codex build features instead of re-deciding architecture. Start with 80% done.

- Repository: https://github.com/open-mercato/open-mercato
- Website: https://www.openmercato.com/
- Stars: 1,780 · Forks: 429
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-mercato-open-mercato

## What Open Mercato actually fixes: AI agents that do not know where code goes

The README states the problem in one line: AI code assistants generate code, but they do not decide where it goes, how it should be layered, or whether it stays consistent across 30 or 50 engineers. That is the gap Open Mercato targets. It is not an AI product in the sense of a chatbot or a model; it is a repository layout, a set of conventions and a spec set that an agent can read before writing anything.

The audience is narrow and stated plainly. The README says it is built for CTOs who have already deployed Cursor or Copilot and noticed it is not enough, and for developers who want to build business applications and backends without constantly checking their own work. The pitch of starting at 80 percent done refers to ready-made CRM, Sales, OMS and Encryption features, with the remaining work framed as the part that differentiates a business.

That framing is worth taking seriously as a positioning claim rather than a technical one. Every framework claims to remove decisions. The specific decisions Open Mercato removes are named in the description: multi-tenancy, RBAC, events and domain modules are decided as conventions and specs. Those are exactly the areas where an agent left to its own judgment produces plausible but inconsistent code, because there is no single correct answer to copy from the training data.

## Module auto-discovery, per-module migrations and a per-request DI container

The architecture section of the README is the most concrete part of the project. Each feature lives under src/modules/<module>, and the framework auto-discovers frontend and backend pages, APIs, CLI commands, i18n files and database entities from that directory. There is no central registry to update when a module is added, which is the mechanism that makes agent-generated modules land in the right place.

Persistence uses MikroORM with per-module entities and migrations. The README is explicit that there is no global schema and that migrations are generated and applied per module. This is a real architectural commitment with consequences: a module owns its tables, and cross-module joins have to be handled deliberately rather than assumed.

Dependency injection uses an Awilix container constructed per request. Modules register and override services and components through a di.ts file. Multi-tenancy is anchored in a core directory module that defines tenants and organizations, and most entities carry tenant_id plus organization_id columns. Security combines RBAC roles, zod validation, bcryptjs hashing and JWT sessions, with role-based access enforced in routes and APIs. Events are published as domain events and processed by persistent subscribers, either locally or through Redis.

The stack is Next.js App Router, TypeScript, zod, Awilix, MikroORM and bcryptjs. Nothing here is exotic, which is the point: an agent has likely seen all of it, and the framework supplies the layer above it that the agent would otherwise invent.

## Installing Open Mercato and running the monorepo for the first time

The README lists the prerequisites before any command: Node.js 24, Git, and PostgreSQL plus Redis, with Docker Desktop named as the easiest route. The package.json engines field pins node to 24.x, so a newer or older runtime is outside what the repository declares.

For the monorepo path, which the README labels core development and full demo, the first steps install Node 24 and activate the Yarn version through Corepack:

```bash
brew install node@24   # or: nvm install 24 && nvm use 24
corepack enable && corepack prepare yarn@4.12.0 --activate
git clone https://github.com/open-mercato/open-mercato.git
```

The clone line in the README is truncated in the published text, so confirm the repository URL against the GitHub page before pasting it. Note also that the README pins yarn@4.12.0 in the quick start while package.json declares packageManager as yarn@4.17.1; Corepack reads the package.json field, so the resolved version may differ from the one in the instructions.

The repository ships a docker-compose.yml that brings up the supporting services. It defines a postgres service on the pgvector/pgvector:pg17-trixie image, exposing port 5432 by default through the POSTGRES_PORT variable, and an opencode service for the AI provider layer on port 4096 through OPENCODE_PORT. Provider selection uses OM_AI_PROVIDER and OM_AI_MODEL, with OPENCODE_PROVIDER and OPENCODE_MODEL kept as a backward-compatibility fallback, and the API key variables are ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_GENERATIVE_AI_API_KEY and OPENROUTER_API_KEY.

```bash
docker compose up -d
yarn install
yarn dev
```

After yarn dev, the scripts/dev.mjs runner starts the development environment. The package.json exposes variants worth knowing about: dev:classic, dev:verbose, dev:greenfield, dev:app for the app only, and dev:ephemeral for a throwaway setup. If file watching misbehaves on WSL, there is a dedicated dev:fix-wsl-watchers script, which tells you the maintainers have hit that problem themselves.

## Where Open Mercato is the wrong choice

The most important limitation is that Open Mercato is a framework, not an application. The README calls the result almost ready apps, and the 80 percent figure covers CRM, Sales, OMS and Encryption features. The remaining 20 percent is code you write. A team looking for a CRM to configure through an admin UI, with no intention of maintaining a TypeScript monorepo, will spend more time here than on a hosted product.

The second constraint is operational. Node.js 24 is required, PostgreSQL and Redis are both needed, and the module system depends on MikroORM migrations being generated and applied per module. That is a heavier local baseline than a single-binary tool, and it means schema changes are a per-module concern rather than one migration directory.

Third, the documentation situation deserves a direct note. The README is long and marketing-forward, and its quick-start block is truncated mid-command in the published version. Several claims, such as growing test coverage, are stated without numbers. The repository does carry AGENTS.md, CLAUDE.md, BACKWARD_COMPATIBILITY.md, UPGRADE_NOTES.md and a CHANGELOG.md, which is where the real operational detail lives. Anyone evaluating this should read those files rather than the README's feature list, because the upgrade and compatibility documents are what determine the cost of following releases.

Finally, the AI-harness premise cuts both ways. If your team has not standardized on an agent workflow, the spec-first structure is overhead without a payoff, and you are left judging the framework purely on its CRM and ERP modules against mature alternatives.

## Open Mercato compared with building on a generic application framework

The obvious alternative is starting from a general-purpose TypeScript application framework and assembling tenancy, permissions, events and domain modules yourself, or from an established CRM/ERP platform that you extend through plugins rather than by owning the source.

The difference is where the decisions live. With a generic framework, multi-tenancy means choosing between schema-per-tenant, row-level scoping or database-per-tenant, then enforcing that choice consistently across every query and API route. Open Mercato has already decided: tenant_id and organization_id on most entities, tenants and organizations defined in a core directory module, and organization trees with role- and user-level visibility controls. RBAC is feature-based, combining per-role and per-user feature flags with organization scoping.

That is a genuine trade. You get consistency and an agent that can follow the pattern, and you give up the freedom to pick a different tenancy model without fighting the framework. The same applies to migrations: per-module migrations keep modules independent, but any change that spans modules needs coordination that a single schema would not require.

Against a plugin-based CRM or ERP, the difference is ownership. Open Mercato is MIT-licensed and the README frames it as full code ownership with no per-seat pricing. The cost is that you are now maintaining a codebase, including its upgrade path, which the presence of UPGRADE_NOTES.md and BACKWARD_COMPATIBILITY.md makes explicit.

## Maintenance, licensing and what upgrades cost

The repository is not archived, and the last push was on 2026-09-10, which is recent relative to the latest release v0.7.0 on 2026-08-26. Before that, v0.6.7 shipped on 2026-08-05 and v0.6.6 on 2026-07-17, so the release cadence through mid-2026 is roughly monthly. The version in package.json matches v0.7.0.

That cadence is the upgrade cost. A monthly minor release on a framework that owns your tenancy, RBAC and migration conventions means every upgrade is a code review, not a dependency bump. The repository acknowledges this with BACKWARD_COMPATIBILITY.md and UPGRADE_NOTES.md at the top level, and the docker-compose.yml shows the pattern in practice: the OM_AI_PROVIDER and OM_AI_MODEL variables are the current way to select a provider, while OPENCODE_PROVIDER and OPENCODE_MODEL are retained only as a backward-compatibility fallback. Configuration surfaces do get renamed.

The licence is MIT, which permits commercial use and modification. That is a permissive licence, and it means the framework carries no copyleft obligation on your own modules. It also means there is no commercial entity obliged to support you; the README points to docs.openmercato.com and the issues page as the routes for help. Nothing in the repository describes a paid support tier, so treat support as community-based unless the project states otherwise elsewhere.

## Who should adopt Open Mercato, and who should not

Adopt it if you are building a multi-tenant business application in TypeScript and you have already felt the specific pain the README describes: agents producing code that works in isolation but does not fit the surrounding structure. The module convention under src/modules gives those agents a target, and the spec-first approach means the conventions travel with the repository rather than living in a senior engineer's head.

Do not adopt it if you want a finished product to configure, if you cannot run PostgreSQL and Redis alongside Node.js 24, or if your team has no agent workflow and no intention of adopting one. In those cases the framework's central value proposition does not apply, and you are evaluating it only on its CRM and ERP modules.

The first thing to verify is not the feature list. Clone the repository and read AGENTS.md and CLAUDE.md to see how the AI harness is actually specified, then read UPGRADE_NOTES.md and BACKWARD_COMPATIBILITY.md to understand what a version bump costs. If those documents describe a process your team can follow, the architecture is worth the commitment. If they do not, the 80 percent head start will not survive the first upgrade.

## Conclusion

Adopt Open Mercato if your team has already put Cursor, Claude Code or Codex in front of engineers and the output keeps drifting, and you accept a Node.js 24, PostgreSQL and Redis baseline plus a MikroORM per-module migration model. Do not adopt it if you want a finished CRM to configure rather than a codebase to extend, or if you cannot run Docker locally. Before committing, clone the repository, read AGENTS.md and CLAUDE.md, and check whether the module structure under src/modules matches how your team already splits work.

## FAQ

### What is Open Mercato?

It is an open-source TypeScript foundation framework for CRM, ERP and commerce applications, described in its README as the AI-Engineering Foundation Framework. It ships conventions and specs for multi-tenancy, RBAC, events and domain modules so that AI coding agents build features instead of re-deciding architecture.

### What do I need installed before running Open Mercato?

The README lists Node.js 24, Git, and PostgreSQL plus Redis, with Docker Desktop named as the easiest way to get the databases. The package.json engines field pins node to 24.x, and the repository includes a docker-compose.yml that starts a postgres service and an opencode service.

### Does Open Mercato work with Cursor, Claude Code and Codex?

The project description states that its conventions and specs are designed so Cursor, Claude Code and Codex build features rather than re-deciding architecture. The repository includes AGENTS.md and CLAUDE.md at the top level, which are the files those tools read for project-level instructions.

### Is Open Mercato free to use commercially?

The repository is licensed under MIT, which permits commercial use and modification. The README also frames the project as open-source with full code ownership and no per-seat pricing, though nothing in the repository describes a paid support tier.

## Sources

- [License: MIT](https://github.com/open-mercato/open-mercato/blob/main/LICENSE)
- [open-mercato/open-mercato on GitHub](https://github.com/open-mercato/open-mercato)
- [Project website](https://www.openmercato.com/)
- [README](https://github.com/open-mercato/open-mercato/blob/main/README.md)
- [Releases](https://github.com/open-mercato/open-mercato/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-mercato-open-mercato