Open Mercato: a TypeScript CRM/ERP foundation that puts architecture decisions in the repo

The problem is architectural drift in AI-generated code, not missing features

The README states the diagnosis 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 a narrower claim than most framework pitches. Open Mercato is not selling faster CRUD. It is selling a fixed set of conventions that a coding agent can read, so the agent stops inventing a folder structure on every request.

The intended audience is stated twice and consistently. First, CTOs who have already deployed Cursor or Copilot and found it insufficient. Second, developers building business applications who do not want to re-check the assistant's output on every change. Both groups share a symptom: the assistant is productive per file and unproductive per repository.

The framework's answer is to pre-decide the parts that are expensive to change later. Multi-tenancy, RBAC, domain events and module boundaries are described as conventions and specs that ship with the repo, not as options you configure. Whether that is a relief or a constraint depends entirely on how closely your domain matches the ones the repository already models.

Module layout, per-module migrations and a per-request DI container

The architecture section is short and specific. Each feature lives under src/modules/<module>, and frontend pages, backend pages, APIs, CLI commands, i18n files and database entities are auto-discovered from that directory. There is no central registry to update when you add a module, which is the mechanism that makes agent-generated code land in a predictable place.

Persistence is MikroORM with per-module entities and migrations. The README says there is no global schema and that migrations are generated and applied per module. That is the most consequential design decision in the project. It keeps modules independently evolvable, and it means your migration tooling has to iterate over modules rather than run one ordered sequence.

Dependency injection uses Awilix, with a container constructed per request. Modules register and override services and components through a di.ts file. The per-request scope is what makes tenant and user context available to services without threading it through every function signature.

Multi-tenancy is anchored in a core module called directory, which defines tenants and organizations. Most entities carry tenant_id and organization_id. The README also mentions multi-hierarchical organizations with role- and user-level visibility controls, which is a stronger claim than flat tenant isolation and is the part most worth checking against your own org model.

Security is listed as RBAC roles, zod validation, bcryptjs hashing, JWT sessions, and role-based access in routes and APIs. Events are published as domain events and consumed by persistent subscribers, running either locally or through Redis.

Getting it running: Node 24, yarn 4.12.0, PostgreSQL and Redis

The prerequisites are explicit: Node.js 24, Git, and PostgreSQL plus Redis, with Docker Desktop named as the easiest route for the databases. The monorepo path in the README starts with brew install node@24 on macOS or Linux, or nvm install 24 && nvm use 24, then corepack enable && corepack prepare yarn@4.12.0 --activate. The clone line in the supplied README is truncated mid-URL, so treat the exact repository URL as something to confirm on the project page rather than copy from this article.

Node 24 is not a soft recommendation. It is the version the setup instructions install, and the stack listed in the highlights (Next.js App Router, TypeScript, zod, Awilix, MikroORM, bcryptjs) is pinned to that toolchain. Running on an older LTS is an untested configuration as far as the supplied material goes.

Redis is required, not optional in practice, because the event subscribers are described as running locally or through Redis. If your deployment target does not include Redis, the event layer is the first thing you will have to rework.

The README also points to a live demo at demo.openmercato.com and a screenshot gallery in SCREENSHOTS.md, which is the fastest way to judge the admin panel before you spend a day on the monorepo. Beyond the quick start, the README does not enumerate environment variable names or migration commands in the portion provided, so those come from docs.openmercato.com rather than from this article.

What the repository does not tell you about upgrades and versioning

The release history is the weakest part of the supplied material. Three releases are listed: v0.7.0 on 2026-08-26, v0.6.7 on 2026-08-05, and v0.6.6 on 2026-07-17. That is a patch cadence measured in weeks, and the jump from v0.6.7 to v0.7.0 happened three weeks after the previous patch. Nothing in the README describes a deprecation policy, a migration guide between minor versions, or a compatibility promise for modules written against an earlier release.

For a framework whose entire pitch is that conventions are fixed, this matters more than it would elsewhere. If module contracts shift between v0.6 and v0.7, the specs your coding agent reads are only stable within a version. The README does not say whether the specs are versioned alongside the code, though the claim that specs ship with the repo suggests they are.

The MIT license removes the legal question. You can fork, modify and redistribute, and there is no per-seat pricing to model, which the README contrasts directly against what it calls a per-seat pricing trap. What MIT does not give you is a support contract or an upgrade guarantee. If you fork to escape a breaking change, you own the merge cost from that point forward. That is a normal open-source trade, not a defect, but it should be priced into the decision before a team builds on it.

Where it is the wrong tool

Open Mercato is a poor fit when your domain does not resemble CRM, sales, orders or production. The README frames the value as starting at 80 percent done, and that percentage is only real if the remaining 20 percent is genuinely the part that differentiates you. On a product with no customer records, no order lifecycle and no organizational hierarchy, you inherit the tenancy and RBAC machinery without the modules that justify it, and you are paying the complexity cost for nothing.

It is also the wrong choice if you need a stable plugin API for third parties. The DI container is built per request and modules override services through di.ts, which is a powerful internal mechanism. It is not the same as a published extension contract with semantic versioning guarantees, and the release cadence above suggests the surface is still moving.

A third case: teams without PostgreSQL and Redis in their operational stack. The README requires both. There is no documented SQLite or in-memory fallback in the supplied material, so evaluating it on a laptop still means running two services.

Finally, the AI harness is only as good as the specs it reads. If your team does not read or maintain those specs, the framework degrades into a conventional Next.js monorepo with an opinionated folder structure. The README's own framing, that agents are given skills for adding data tables, forms and whole features, assumes someone is keeping those skills accurate.

How it differs from Medusa and Twenty

The closest comparisons are Medusa for commerce backends and Twenty for CRM, and the difference is where each puts its opinion.

Medusa is a commerce platform with a module system and a documented plugin and extension model. Its center of gravity is the commerce domain: carts, regions, fulfillment, payment providers. Open Mercato instead treats commerce as one of several listed use cases alongside CRM, ERP, self-service portals and production management, and it puts its opinion at the layer below the domain, in tenancy, RBAC, events and module discovery. If you are building a storefront, Medusa gives you more commerce-specific structure. If you are building an internal business application that happens to include ordering, Open Mercato's tenancy and organization model is the part you would otherwise write yourself.

Twenty is a CRM application with an extensible data model, and the README's own description of Open Mercato as having infinitely flexible data definitions through custom entities and dynamic forms overlaps with that. The distinction is that Open Mercato presents itself as a foundation for building applications, with a documented stack (Next.js App Router, MikroORM, Awilix) that you extend in TypeScript, rather than as a finished CRM you configure. The trade is control versus time to first value.

Neither comparison is settled by feature lists. The practical test is whether you want to own the application layer in TypeScript, which is what Open Mercato assumes, or whether you want to configure an existing product.

Maintenance cost and the licence position

The recurring cost here is not licensing. MIT means no fees and no per-seat accounting, which the README explicitly positions against per-seat pricing. The cost is in keeping the conventions coherent as your team adds modules. Every new module adds entities, migrations, a di.ts registration, i18n files and API routes that the auto-discovery has to pick up correctly. The framework reduces the cost of deciding where code goes; it does not reduce the cost of the code itself.

There is a second cost that the README implies but does not quantify: maintaining the specs and skills that the AI harness reads. If those drift from the actual module structure, agent output drifts with them, and the failure is quiet rather than loud. That is the maintenance item most likely to be underestimated, because it is documentation work that only pays off through the assistant.

On licensing, MIT permits commercial use, modification and redistribution, and the README states there is no lock-in and full code ownership. That is the extent of what the supplied material supports. Questions about how MIT interacts with your own distribution model, or with dependencies pulled in by the Next.js and MikroORM stack, belong with your legal counsel, not with this review.

Editorial conclusion

Adopt Open Mercato if your team already runs Cursor or Claude Code on a business application and keeps re-explaining module boundaries, tenant scoping and RBAC in every prompt, because the specs and the src/modules layout are the product here. Do not adopt it if you need a published upgrade path, a stable API surface for third-party plugins, or a stack you can host without PostgreSQL and Redis. Before committing, verify three things against the repository at the tag you intend to use: that apps/mercato builds on Node.js 24 with yarn 4.12.0, that the directory module's tenants and organizations tables match your tenancy model, and that the per-module MikroORM migrations apply cleanly in your CI database.

Official sources

1. License: MIT
2. open-mercato/open-mercato on GitHub
3. Project website
4. README
5. Releases