Forem: Tomasz Karwatka

Why We Chose Next.js as the Foundation for an Open-Source CRM

Tomasz Karwatka — Thu, 09 Apr 2026 15:10:31 +0000

When was the last time you were excited to work on CRM code?

I'm serious. CRM development has been stuck in a time warp for decades. Salesforce runs on Apex — a proprietary Java-like language that exists nowhere else. SugarCRM and SuiteCRM are PHP monoliths from the mid-2000s. Microsoft Dynamics is C# and a proprietary Power Platform. Even the "modern" players lock you into low-code builders that fall apart the moment you need real logic.

Meanwhile, the rest of the web moved on. React. TypeScript. Next.js. Server components. Edge functions. Vercel. The entire frontend ecosystem evolved — except CRM.

So we asked: what if you could build a CRM the same way you build a modern web app?

The Bet

I'm Tomasz Karwatka. I co-founded Divante (exit at $65M), Vue Storefront/Alokai (Y Combinator, $40M Series A), Callstack, and Open Loyalty. With my brother Piotr at Catch The Tornado, we've invested in over 40 companies, including ElevenLabs.

I've spent 20 years watching enterprise software be built on stacks that developers dread. And I've spent those same 20 years watching the JavaScript ecosystem become the most productive development environment on the planet.

The bet behind Open Mercato is simple: a CRM built on Next.js, React, and TypeScript will attract better developers, ship faster, integrate easier, and — crucially — be the first CRM framework that AI agents can actually extend reliably.

The Stack — And Why Every Choice Matters

Open Mercato is a full-stack Next.js application. Not "a React frontend with a random backend." The whole thing. Let me walk through the choices:

Next.js App Router — server components for data-heavy pages (customer lists, deal pipelines, reports), client components for interactive UI (drag-and-drop workflows, real-time activity feeds). One framework, one routing model, one deployment. No separate API gateway, no microservice spaghetti.

TypeScript end to end — from Zod schemas that validate API input, through MikroORM entities that map to PostgreSQL, to React components that render the data. One language. One type system. A type error in your CRM entity shows up in your IDE before you even save the file.

PostgreSQL + MikroORM — not MongoDB, not some proprietary database. PostgreSQL with a mature ORM that gives you migrations, relations, and query building. Plus PGVector for semantic search — because in 2026, a CRM without vector search is a CRM without AI.

Redis — Bull queues for async processing (email sending, webhook delivery, report generation), tag-based cache invalidation for sub-second page loads on large datasets.

Zod — runtime validation at every API boundary. This isn't just type safety — it's what makes AI code generation actually work (more on that later).

Shadcn UI — the design system. Accessible, composable, and built on Radix primitives. Your CRM doesn't have to look like it was designed in 2008.

The whole thing lives in one monorepo. One npm install. One npm run dev. You're staring at a working CRM with authentication, multi-tenancy, RBAC, encryption, and 15+ modules in under five minutes.

What You Get Out of the Box

This isn't a starter template. These are production modules with over 1,000 unit tests:

Core infrastructure that every CRM needs but nobody wants to build:

Multi-tenant Directory — organization hierarchies, user management, team structures. TenantId enforced at query level — cross-tenant data leaks are architecturally impossible
Auth & RBAC — session management, feature-based roles, access control lists. Every API route, every server component, every client action respects the permission model
Encrypted Vault — field-level AES-GCM encryption with per-tenant keys. Encrypt the SSN field, the credit card column, the medical record — each tenant with its own key ring, backed by HashiCorp Vault or environment keys
Audit & Undo/Redo — every mutation is a Command. Every Command is logged and reversible. Complete operation history with who/what/when/where

CRM domain modules that you'd otherwise spend months building:

Customers & Contacts — the customer 360 view with activity timeline, custom fields, relations, tagging
Deals & Pipeline — sales opportunities, stage management, probability tracking, revenue forecasting
Catalog — products, services, categories, variants, custom fields per category
Sales Operations — quotes, orders, negotiation flows, shipping, payment integrations
Workflows — visual process designer. Approval chains, status lifecycles, automated actions. No-code for simple flows, full TypeScript for complex ones
Search — full-text search plus PGVector semantic search across all entities including custom fields. Encrypted index support
Query Engine — flat-table indexing for sub-second queries on 1M+ customer records

The Overlay Pattern — Why Next.js Makes It Work

Here's where it gets interesting. The classic problem with CRM frameworks: you fork, you customize, you can never update again.

Open Mercato solves this with the Overlay Pattern — and Next.js makes it elegant.

The core modules live in the monorepo. Your custom code lives in a separate Overlay layer. The build system scans both layers and generates route registries, DI containers, and component trees. Your code always wins over core defaults.

On the backend, you override services through Awilix dependency injection:

// Custom lead scoring? Override the service. Core untouched.
import { LeadScoringService } from '@open-mercato/crm';

export class MyLeadScoringService extends LeadScoringService {
  score(lead: Lead): number {
    const baseScore = super.score(lead);
    const industryBonus = this.getIndustryWeight(lead.industry);
    const engagementScore = this.calcEngagement(lead.activities);
    return baseScore * industryBonus + engagementScore;
  }
}

On the frontend, you override Next.js pages directly:

// Don't like the default customer detail page?
// Drop your version in the overlay. The router picks it up.

// overlay/app/customers/[id]/page.tsx
export default async function CustomerDetail({ params }: Props) {
  const customer = await getCustomer(params.id);

  return (
    <div className="grid grid-cols-3 gap-6">
      <CustomerProfile data={customer} />
      <ActivityTimeline customerId={customer.id} />
      <MyCustomRiskPanel customerId={customer.id} />
    </div>
  );
}

No patching. No monkey-patching. No build hacks. Just Next.js file-based routing with a two-layer resolution. When Open Mercato releases a new version, you update the core. Your overlay stays untouched. Zero merge conflicts.

Widget Injection lets you add components from one module into another's pages. Event subscriptions let modules react to each other's domain events. Custom fields can be added to any entity at runtime — no migrations needed.

AI-Native — And Next.js Is Why

Every CRM now claims to be "AI-powered." They mean they added a chatbot. We mean something different.

Open Mercato is designed so that AI coding agents — Claude, Cursor, GitHub Copilot — can reliably extend the framework. Three things make this work:

Monorepo = full context. When an AI agent opens the Open Mercato repo, it sees every module, every service, every type, every test. It understands how LeadScoringService connects to DealPipelineService connects to NotificationService. No guessing. No hallucinating across service boundaries.

Deterministic patterns. Every module follows the same Next.js conventions. Routes, server actions, Zod schemas, MikroORM entities, DI registrations, Playwright tests. The AI sees the pattern in 20 modules and replicates it perfectly for the 21st. TypeScript + Zod catch any deviation at compile time.

AGENTS.MD per module. Each module ships with a machine-readable contract: which services can be overridden, which events are emitted, what the Zod schemas look like, where the extension points are. This isn't documentation for you. It's instructions for your AI agent.

The practical result: a feature that takes a senior developer 2–3 days to scaffold gets generated in 30 minutes. The human still reviews, tests, and ships — but reviews working code, not a blank editor.

Next.js matters here because it's the framework AI agents know best. More training data, more examples, more pattern recognition. Ask Claude to write a Next.js App Router page and it nails it. Ask it to write ABAP and... good luck.

Enterprise Security Without the Enterprise Tax

I've worked with HealthTech and finance companies at Vue Storefront and Open Loyalty. I know what happens when you try to retrofit security onto a framework that wasn't built for it. It's expensive, it's painful, and it's never quite right.

Open Mercato has it from day zero:

Field-level encryption — AES-GCM with per-tenant key rings. Not database-level encryption that protects against disk theft but nothing else. Individual field encryption that protects data even if someone has full database access. Without the KMS, the data is useless.

Complete audit trail — every operation logged via the Command Pattern. Who accessed customer X's credit history on March 14 at 3:32 PM from IP 192.168.1.42? One query. One second.

Multi-tenant isolation — TenantId enforced at the ORM level. Queries physically cannot return another tenant's data. Not "we filter it out." The WHERE clause is injected automatically.

RBAC + ACL — "This sales rep can see EMEA deals but not APAC." That's configuration, not custom code.

For regulated industries this isn't a nice-to-have. It's table stakes.

Who Should Use This

Open Mercato is not for a 5-person startup that needs a basic contact list. Get HubSpot. It's great for that.

Open Mercato makes sense when:

You need a CRM that fits your processes, not the other way around
You're consolidating 5–10 SaaS tools into one integrated system
You're in a regulated industry and need field-level encryption plus audit trails
Your team already builds in Next.js/TypeScript and wants to stay in that ecosystem
You've outgrown Retool or similar low-code platforms and need full code control
You want to deploy on your own infrastructure with your own encryption keys

Why Open Source

Your CRM holds your customer relationships — the most valuable data your business has. Locking it inside a vendor's black box with per-seat pricing and no data portability is a business risk.

Open Mercato gives you full source code. Deploy anywhere — Vercel, AWS, your own data center. Control your encryption keys. Fork it if you want (though the Overlay Pattern means you'll never need to). If we disappear tomorrow, your CRM keeps running.

Vendor lock-in in a CRM is like storing your customer Rolodex in someone else's safe and paying monthly to look at it. Open source means you own the safe.

Get Started

The repo is live. The modules are stable, tested, and documented.

git clone https://github.com/open-mercato/open-mercato.git
cd open-mercato
npm install
npm run dev

Five minutes to a running CRM with auth, multi-tenancy, encryption, and 15+ production modules. Then build the parts that make your business unique.

Check out the repo and give it a star if you think CRM deserves a modern stack :)

Tomasz Karwatka — co-founder of Divante, Vue Storefront/Alokai, Catch The Tornado. Building and investing in tech companies since 2004.

open-mercato / open-mercato

AI‑supportive CRM / ERP / Business application framework — built to power R&D, operations, and growth. It’s modular, extensible, and designed for teams that want strong defaults with room to customize everything. Better than Django, Retool and other alternatives - and Enterprise Grade!

Open Mercato

Open Mercato is a new‑era, AI‑supportive platform for shipping enterprise‑grade CRMs, ERPs, and commerce backends. It’s modular, extensible, and designed so teams can mix their own modules, entities, and workflows while keeping the guardrails of a production-ready stack.

Start with 80% done.

Buy vs. build? Now, you can have best of both. Use Open Mercato enterprise ready business features like CRM, Sales, OMS, Encryption and build the remaining 20% that really makes the difference for your business.

Core Use Cases

💼 CRM – model customers, opportunities, and bespoke workflows with infinitely flexible data definitions.
🏭 ERP – manage orders, production, and service delivery while tailoring modules to match your operational reality.
🛒 Commerce – launch CPQ flows, B2B ordering portals, or full commerce backends with reusable modules.
🤝 Self-service system – spin up customer or partner portals with configurable forms, guided flows, and granular permissions.
🔄 Workflows –…

View on GitHub

I Got Tired of Building ERP Infrastructure From Scratch. So I Open-Sourced It.

Tomasz Karwatka — Thu, 09 Apr 2026 15:03:37 +0000

How much of your "custom ERP" is actually custom?

I've been building enterprise software for 20 years. And here's a dirty secret: in every ERP project I've seen, about 80% of the code is the same boring infrastructure. Authentication. Multi-tenancy. Permissions. Audit logs. Encryption. Workflows. The remaining 20% is the actual business logic — the part that matters.

Yet every company builds that 80% from scratch. Every. Single. Time.

The Money Pit I Know Too Well

Quick context: I co-founded Divante (exit at $65M valuation), Vue Storefront/Alokai (Y Combinator, Series A at $40M), Callstack, and Open Loyalty. With my brother Piotr at Catch The Tornado, we invest in about 10 companies a year — over 40 in our portfolio, including ElevenLabs.

Across all these companies, I've watched the same pattern play out. A business needs a custom system to manage operations — orders, inventory, staff, resources, documents. They look at SAP or Oracle. The price tag makes them faint. They decide to build their own. Eighteen months later they have a buggy system that handles authentication, permissions, and audit logs. The actual business logic? Maybe 30% done.

At Divante we spent $1–4 million on each product before it became self-sustaining. Most of that wasn't business logic. It was plumbing.

I got tired of watching this happen. So I built Open Mercato.

A Framework, Not a Product

Open Mercato is an open-source TypeScript framework for building ERP applications. And I need you to understand the difference between a framework and a product.

SAP is a product. You configure it. You bend your processes to fit its boxes. When the boxes don't fit — and they never fully do — you hire consultants at $300/hour to write ABAP code that nobody else can maintain.

Open Mercato is a framework. Like Next.js is a framework for web apps, Open Mercato is a framework for enterprise operations software. You build exactly what your business needs, on top of production-ready infrastructure.

The stack: Next.js, React, PostgreSQL, MikroORM, Redis, Zod. Full TypeScript end to end. One monorepo. No Java, no ABAP, no proprietary DSL. Just TypeScript — the language your team already knows.

What "80% Done" Actually Means

Let me be specific about what you get on day one. This isn't a starter template with a login page. These are production modules backed by over 1,000 unit tests:

Core Infrastructure:

Multi-tenant Directory — organization hierarchies, user management, team structures. Not bolted on as an afterthought — it's the architectural foundation
Auth & RBAC — sessions, roles, feature-based permissions, access control lists. Every endpoint, every query, every UI component respects the permission model
Encrypted Vault — field-level AES-GCM encryption with per-tenant keys. Not "encrypt the whole database." Encrypt the SSN column, the salary field, the medical record — each tenant with its own key
Audit & Undo/Redo — every data operation logged (who, what, when, from where) via the Command Pattern. Full operation history. Full reversibility

Business Modules:

Catalog — products, categories, variants, custom fields per category. Works for physical goods, services, digital products — whatever you sell or manage
Sales Operations — orders, quotes, negotiation flows, shipping, payment integrations. The full order lifecycle
Workflows — visual designer for business processes. Define document lifecycles, approval chains, state machines. No code for simple flows, full code access for complex ones
Staff Management — employees, teams, availability, leave management, resource allocation
Resource Management — company assets, equipment tracking, availability scheduling
Search Engine — full-text and vector search (PGVector). Search across base fields and custom fields with encrypted index support
Query Engine — flat-table indexing of base and custom fields. Sub-second queries on 1M+ records

WMS, POS, and an accounting module are in the pipeline.

The Overlay Pattern — Your Code Never Touches Mine

Here's the thing that makes Open Mercato different from every other framework I've used: the Overlay Pattern.

We took the Open-Closed Principle and made it architectural law. The core is closed for modification. Your custom code lives in a separate Overlay layer. You extend, you override, you inject — but you never edit a core file.

// Need custom pricing logic for your industry?
// Override the service through DI. Core stays untouched.

import { PricingService } from '@open-mercato/sales';

export class WholesalePricingService extends PricingService {
  calculatePrice(item: CatalogItem, context: PricingContext): Money {
    const tierDiscount = this.getTierDiscount(context.customer);
    const volumeDiscount = this.getVolumeDiscount(context.quantity);
    return item.basePrice
      .multiply(1 - tierDiscount)
      .multiply(1 - volumeDiscount);
  }
}

// Register in the Awilix DI container. Done.

When we release an update — you pull it in. Your Overlay stays untouched. Zero merge conflicts. Zero technical debt from framework updates.

This works at every level: service overrides via dependency injection, page overrides on the frontend, widget injection across modules, event subscriptions for cross-module communication, custom fields on any entity at runtime without database migrations.

I've seen too many companies fork a framework, modify the core, and then spend years maintaining a diverging codebase. The Overlay Pattern makes that structurally impossible.

Built for AI Agents — And I Mean It

I know "AI-native" has become meaningless marketing. But Open Mercato was literally built using AI-assisted engineering, and designed to be extended by AI agents. Here's what that means concretely:

Monorepo = full context. AI needs to see the whole picture. When Claude or Cursor sees 20 modules with the same structure — services, commands, events, Zod schemas, tests — it doesn't hallucinate. It follows the pattern.

AGENTS.MD in every module. Machine-readable contracts that describe: which services can be overridden, which events are emitted, which endpoints are available, what the Zod schemas look like. This isn't documentation for developers. It's instructions for AI.

Deterministic patterns. Every module follows the same architecture. Zod validates everything at the boundary. TypeScript catches the rest at compile time. The AI generates code that actually works because the guardrails are baked into the architecture.

The practical workflow:

Write a feature spec in markdown
Point the AI agent to the relevant AGENTS.MD
Agent generates Overlay code — never touching core
TypeScript + Zod catch schema errors at compile time
Playwright tests verify behavior
Human reviews and ships

We've seen features that would take a developer 2–3 days get scaffolded in 30 minutes this way. The human review is still essential — but the human reviews working code, not a blank editor.

Enterprise Security That Doesn't Require a Consultancy

At Vue Storefront and Open Loyalty we worked with HealthTech and finance companies. I know what compliance audits look like. I know the pain of retrofitting security into a framework that wasn't designed for it.

Open Mercato has it from day zero:

Field-level encryption — each tenant gets its own AES-GCM encryption keys. Sensitive fields (salary, medical data, PII) are encrypted individually. Even with full database access, the data is useless without the KMS (we support HashiCorp Vault or environment-based keys).

Complete audit trail — every operation is a Command. Every Command is logged. Who accessed what, when, from which IP. Regulators love this. Your compliance team will love it more.

Multi-tenant isolation — TenantId and organizationId enforced at query level, service level, and API level. Cross-tenant data leakage is architecturally impossible. Not "we have tests for it." The query layer physically cannot return data from another tenant.

RBAC + ACL — feature-based role definitions per module, plus granular access control lists. "This sales manager can see deals in the EMEA region but not APAC" — that's a config, not custom code.

For regulated industries — HealthTech, finance, government, insurance — this isn't a feature list. It's the minimum bar. And most frameworks don't clear it.

Who Should Use This

Open Mercato is not for everyone. If you need a simple task tracker or a basic CRM for a 10-person team, use Monday.com or HubSpot. Seriously — they're great for that.

Open Mercato makes sense when:

Your operations are complex enough that no SaaS fits without heavy customization
You're paying for 5–10 different tools and want one integrated system built around your actual processes
You're in a regulated industry and need field-level encryption, audit trails, and data sovereignty
You have a TypeScript dev team (or a software house partner) that can build and maintain custom modules
You're replacing a legacy ERP or outgrowing low-code platforms like Retool
You want to own your operational data — on your servers, in your data center, with your encryption keys

Why Open Source

I could have built this as a closed SaaS with per-seat pricing. I know the playbook — I've run it multiple times.

But your ERP is the nervous system of your company. Every order, every employee record, every workflow, every financial transaction flows through it. Locking that into a vendor's black box is a business risk.

With Open Mercato you see every line of code. You deploy on your infrastructure. You control your encryption keys. If we disappear tomorrow — your system keeps running. Try that with SAP.

Vendor lock-in in an ERP is like building your factory on rented land. Open source means you own the ground under your feet.

Get Started

Open Mercato is in production. The core modules are stable, tested, and documented.

If you're building enterprise operations software in TypeScript and you're tired of reinventing authentication, permissions, audit logs, and multi-tenancy for the hundredth time — check out the repo. Take the 80%. Ship the 20% that actually matters.

And if you have questions — I'm always happy to talk about building enterprise software. It's been my life for 20 years and I still find it weirdly exciting :)

Tomasz Karwatka — co-founder of Divante, Vue Storefront/Alokai, Catch The Tornado. Building and investing in tech companies since 2004.

open-mercato / open-mercato

AI‑supportive CRM / ERP / Business application framework — built to power R&D, operations, and growth. It’s modular, extensible, and designed for teams that want strong defaults with room to customize everything. Better than Django, Retool and other alternatives - and Enterprise Grade!

Open Mercato

Start with 80% done.

Core Use Cases

💼 CRM – model customers, opportunities, and bespoke workflows with infinitely flexible data definitions.
🏭 ERP – manage orders, production, and service delivery while tailoring modules to match your operational reality.
🛒 Commerce – launch CPQ flows, B2B ordering portals, or full commerce backends with reusable modules.
🤝 Self-service system – spin up customer or partner portals with configurable forms, guided flows, and granular permissions.
🔄 Workflows –…

View on GitHub

Open Mercato: Why I'm Building a TypeScript CRM Framework Instead of Another SaaS

Tomasz Karwatka — Thu, 09 Apr 2026 14:56:38 +0000

How many times have you heard: "Salesforce is too expensive, but we don't have an alternative"?

I've heard it dozens of times. From Divante's clients, from companies in our Catch The Tornado portfolio, from founders I grab coffee with. Everyone complains about the same thing: CRMs are either too rigid, too expensive, or both.

So I thought — fine, let's build something different.

A Problem I've Seen for 20 Years

Over the past two decades I've built and co-founded several software companies. Divante (exit at a $65M valuation), Vue Storefront/Alokai (Y Combinator, Series A — $40M), Callstack, Open Loyalty. Together with my brother Piotr at Catch The Tornado, we invest in about 10 companies a year. We have over 40 in our portfolio, including ElevenLabs.

Throughout all these years I've seen one repeating pattern: companies buy off-the-shelf SaaS, then cry because they can't adapt it to their processes. Or they build everything from scratch and cry because it takes 18 months and costs millions.

There's nothing in between. Zero.

What Open Mercato Actually Is

Open Mercato is an open-source TypeScript framework for building CRM and ERP applications. It's not another product to configure. It's the foundation on which you build exactly what your company needs.

Think of it this way: React is not a website. React is a framework you use to build a website. Open Mercato is not a CRM. It's a framework you use to build your CRM.

The tech stack? Next.js, React, PostgreSQL, MikroORM, Redis, Zod. Full TypeScript, from frontend to backend. One monorepo, full context for the developer — and for AI.

"Start with 80% Done"

Building an enterprise CRM from scratch is hell. I know this because at Divante we spent $1–4 million on each product before it became self-sustaining — I'm talking about Vue Storefront and Open Loyalty.

Most of that cost isn't business logic. It's infrastructure: authentication, multi-tenancy, RBAC, audit logging, data encryption, caching, queuing. Every enterprise needs the same set, and every company builds it from scratch.

Open Mercato gives you that 80% out of the box. You build the remaining 20% — the part that makes your business unique.

What you get on day one:

Directory — multi-tenant core with organization hierarchy and user management
Auth — sessions, roles, feature-based RBAC, access control lists
Encrypted Vault — field-level encryption with per-tenant keys (AES-GCM)
CRM Foundation — customers, deals, sales pipeline, activity timeline
Catalog — products, categories, variants, custom fields per category
Workflows — visual designer for business processes
Search Engine — full-text and vector search (PGVector)
Audit & Undo/Redo — every operation is reversible and logged

These aren't mocks. These are production modules backed by over 1,000 unit tests.

Overlay Pattern — Or Why You Won't Have Technical Debt

The biggest pain when customizing frameworks? You fork, modify the core, and then every update is merge hell.

In Open Mercato we applied the Open-Closed Principle literally. The core is closed for modification but open for extension. All your custom code lives in the Overlay layer — you never touch core files.

In practice it looks like this:

// Want to override tax calculation?
// Don't fork the core. Override the service via DI.

import { TaxCalculationService } from '@open-mercato/core';

export class MyCustomTaxService extends TaxCalculationService {
  calculate(order: Order): Money {
    // Your logic, your rules, your country
    return this.applyLocalTaxRules(order);
  }
}

// Register in the DI container (Awilix) and you're done.

When Open Mercato releases a new version — you update the core and your Overlay stays untouched. Zero merge conflicts, zero technical debt.

Same on the frontend. Want to replace a customer page? Page Override. Want to inject a widget from one module into another? Widget Injection. Want to add a custom endpoint? Scaffolding generates CRUD in seconds.

AI-Native — And I Don't Mean Marketing Fluff

I know everyone slaps "AI-powered" and "AI-native" on everything now, including toasters. But here it means something specific.

Open Mercato is built so that AI agents (Claude, Cursor, GitHub Copilot) can effectively extend it. How?

First — monorepo. AI needs context. When an agent sees the entire codebase, it understands dependencies between modules. When it sees a single file — it hallucinates.

Second — deterministic patterns. Every module in Open Mercato has the same structure. Services, commands, events, Zod schemas, tests. The AI doesn't have to guess how to write a new module — it follows the pattern it sees in 20 existing ones.

Third — AGENTS.MD. Every module contains a machine-readable file that describes the extensibility contract: which services can be overridden, which events it emits, which endpoints it exposes. This isn't documentation for humans. It's instructions for AI.

In practice the workflow looks like this:

You define the feature spec in markdown
You point the AI agent to the module's AGENTS.MD
The agent generates code in the Overlay layer
TypeScript + Zod catch errors at compile time
Playwright tests verify behavior
A human does code review

Sounds simple? It actually is — because the architecture enforces it.

Enterprise Security Without Enterprise Complexity

At Vue Storefront and Open Loyalty we worked with companies in finance and HealthTech. I know how much pain it costs to meet security requirements when the framework doesn't support them out of the box.

Open Mercato has it baked in from day zero:

Field-level encryption — not the whole database, but specific fields (e.g., SSN, card number). Each tenant has its own encryption keys. Even if someone gains server access — without the KMS (Key Management System, e.g., HashiCorp Vault) the data is useless.

Audit log on every operation — who, what, when, from which IP. We use the Command Pattern, which also gives us undo/redo on all data. A regulator asks "who modified patient record X on March 14 at 3:32 PM"? You have the answer in one second.

Multi-tenant isolation — TenantId and organizationId are enforced at every layer. Cross-tenant data leak? Architecturally impossible, not just "hard to do."

This isn't nice-to-have. For regulated industries it's a deal breaker.

Who This Is For

Let me be clear — Open Mercato is not for everyone. If you're running a 5-person startup and need a basic CRM, get HubSpot. Seriously.

Open Mercato makes sense when:

Your company has unique processes that no SaaS can handle
You're paying for 5–10 different SaaS tools and want to consolidate
You're in a regulated industry (HealthTech, finance) and need field-level encryption plus audit trails
You have a dev team (or a software house) that can build in TypeScript/Next.js
You want to replace low-code platforms (Retool and the like) with something that gives you full control over code and data

Why Open Source

I could build a closed SaaS. I know how to build SaaS — I've done it multiple times. But CRM/ERP is the backbone of a company. It's the system where your most important business data lives.

I don't want you to depend on us. I want you to see every line of code that handles your data. I want you to be able to deploy it on your own server, in your own data center, with your own KMS.

Vendor lock-in in a CRM is like renting an apartment where you can't change the locks. Open source is a mortgage — more work, but the house is yours.

What's Next

Open Mercato is already in production. We have CRM, Catalog, Sales Operations, Staff Management, Workflows, and HRM modules. In the pipeline: WMS (warehouse), POS (point of sale), an accounting module, and an integration marketplace.

If you're building enterprise business applications in TypeScript and you're tired of writing infrastructure from scratch — check out the repo. Take the 80%, build your 20%.

And if you have questions — reach out. I'm not a great writer and never will be, but I can talk about building tech products for hours :)

Tomasz Karwatka — co-founder of Divante, Vue Storefront/Alokai, Catch The Tornado. Building and investing in tech companies since 2004.

open-mercato / open-mercato

AI‑supportive CRM / ERP / Business application framework — built to power R&D, operations, and growth. It’s modular, extensible, and designed for teams that want strong defaults with room to customize everything. Better than Django, Retool and other alternatives - and Enterprise Grade!

Open Mercato

Start with 80% done.

Core Use Cases

💼 CRM – model customers, opportunities, and bespoke workflows with infinitely flexible data definitions.
🏭 ERP – manage orders, production, and service delivery while tailoring modules to match your operational reality.
🛒 Commerce – launch CPQ flows, B2B ordering portals, or full commerce backends with reusable modules.
🤝 Self-service system – spin up customer or partner portals with configurable forms, guided flows, and granular permissions.
🔄 Workflows –…

View on GitHub

Twenty vs Open Mercato: CRM Product vs AI-Supportive Platform Foundation

Tomasz Karwatka — Wed, 25 Mar 2026 20:16:33 +0000

Twenty has quickly become one of the most visible modern open-source CRMs—a fresh alternative to Salesforce and Pipedrive with a slick UI and strong community momentum.

At the same time, Open Mercato positions itself not as “yet another CRM”, but as an AI-supportive foundation for building enterprise‑grade CRMs, ERPs, and commerce backends.

In this article, I’ll compare Twenty and Open Mercato, then focus on when it makes more sense to choose Open Mercato as the underlying platform for your product.

Quick overview: product vs foundation

You can frame the difference like this:

Twenty – a modern open-source CRM product that you can self‑host or consume as SaaS, aiming to be a community‑powered alternative to Salesforce and Pipedrive.
Open Mercato – an AI-supportive CRM/ERP foundation framework designed to power customized CRMs, ERPs, and operations platforms.

If you imagine the stack:

Twenty is closer to “the finished CRM app your sales team can use today”.
Open Mercato is closer to “the platform your product team uses to build its own CRM/ERP‑like product”.

Positioning table

Aspect	Twenty	Open Mercato
Primary role	Modern, user‑friendly open-source CRM product	AI‑supportive foundation for CRM/ERP/commerce products
Orientation	Sales and GTM teams using a ready CRM	Product & platform teams building their own vertical SaaS
Scope	Deals, contacts, pipelines, activities, basic automation	CRM, ERP, commerce, self‑service portals, workflows, scheduling
Mental model	“Install and run your CRM”	“Assemble your own enterprise platform from modules and custom entities”

Architecture and tech stack

Both projects embrace modern web stacks, but their architecture goals differ.

Twenty architecture

From the public materials and documentation, Twenty is:

A modern, open-source CRM built as an alternative to Salesforce/Pipedrive.
Focused on great UX (Notion‑inspired editing, boards, filters) and a cloud‑ready architecture.
API‑friendly, with REST and GraphQL interfaces for integrations and automations.
Licensed under AGPLv3, with a SaaS offering from the core team.

The core goal: a delightful CRM your team can adopt quickly, with customization primarily at the data/UX level rather than as a general‑purpose app framework.

Open Mercato architecture

Open Mercato is explicitly framed as an AI-supportive platform and ships with:

TypeScript-first stack – Next.js App Router, Node.js, MikroORM, zod, Awilix DI.
Strict modular architecture – each feature lives under src/modules/<module> with auto‑discovered pages, APIs, CLI, i18n, and DB entities.
Per‑module schema & migrations – no global schema; migrations generated and applied per module.
Multi‑tenant by default – tenant and organization IDs on entities; SaaS‑ready from day one.
Feature‑based RBAC – role‑ and user-level feature flags gating pages and APIs.
Field‑level encryption – tenant‑scoped, field‑level encryption hooks at ORM level for PII and sensitive data.
Event subscribers & workflows – domain events processed via subscribers (local or Redis).

The core goal: a composable backend for enterprise‑grade CRMs/ERPs, optimized for long‑term extensibility, AI agents, and multi‑tenant SaaS.

Architecture table

Aspect	Twenty	Open Mercato
Tech focus	Modern open-source CRM app with strong UX	TypeScript/Next.js modular framework
API/headless	REST & GraphQL APIs for integrations	Headless/API‑rich by design for apps and portals
Multi‑tenancy	Primarily single CRM instance per deployment/SaaS	Multi‑tenant and multi‑org by default
Security	Standard auth, roles, modern SaaS patterns	Field‑level encryption, tenant‑scoped keys, RBAC
Licensing	AGPLv3, with commercial SaaS option	MIT open source for the framework

Extensibility and customization

Both offer customization, but they solve different problems.

Customizing Twenty

Twenty focuses on being an enjoyable CRM with:

Flexible data structures (custom fields, views, filters).
A Notion‑like UX to model your pipeline and workflows.
APIs to integrate with other tools or build light extensions around it.

This is perfect if you want “Salesforce/Pipedrive‑like functionality but open source, nicer, and under your control”.

Building on Open Mercato

Open Mercato gives you framework‑level extension points:

Drop‑in modules with their own entities, pages, APIs, CLI, and translations.
Custom entities and dynamic forms defined per module and managed live in the admin.
Domain events and subscribers for complex workflows and automations.
Multi‑tenant, multi‑hierarchical organizations with fine‑grained RBAC.

Instead of “tuning a CRM”, you are designing a product: for example, a vertical SaaS for logistics, healthcare, manufacturing, or services that happens to include CRM capabilities.

Extensibility table

Aspect	Twenty	Open Mercato
Custom fields/views	Yes, configurable CRM objects, filters, pipelines	Yes, via module-defined entities & dynamic forms
Extension surface	App-level: scripts, APIs, integrations	Framework-level: modules, overlays, events, CLI, APIs
Use case	Tailor a CRM to your team’s workflows	Build new products (CRMs, ERPs, commerce, portals) on a shared foundation

Product maturity and ecosystem

Twenty

Twenty has attracted a lot of attention as the “modern open-source CRM”:

Strong GitHub traction and community buzz.
Polished UI and modern UX, often highlighted by reviewers.
Available as self‑hosted open source (AGPLv3) and as an official SaaS.

If you want a CRM that your sales or CS team can start using quickly, this ecosystem is a big advantage.

Open Mercato

Open Mercato is focused more on product builders than end‑users:

v0.x releases, growing star count and contributions.
Strong emphasis on docs for architecture, customization, and framework usage.
Community oriented around building modules and products on top of it.

If you are building software for others (SaaS, internal platforms, products), this developer-first posture matters more than prebuilt CRM screens.

When Open Mercato is the better choice

So when should you pick Open Mercato over Twenty?

1. You’re building a multi‑tenant SaaS or vertical platform

If the goal is to build a product, not just run a CRM for one company, Open Mercato is the better foundation:

Multi‑tenant by default, with tenants and organizations modeled in the core.
Modules you can mix and match: CRM, operations, workflows, schedules, commerce.
Clean separation between framework and the product you’re building.

Examples:

A vertical SaaS for agencies, clinics, or field services that needs CRM + scheduling + project management.
A B2B marketplace backend with custom flows and self‑service portals.

2. You need ERP‑like or operations‑heavy workflows

Twenty focuses on CRM—pipelines, contacts, companies, activities.

If your domain includes operations, production, or logistics in the same system, Open Mercato fits better:

Order processing, production management, and service delivery flows.
Resource scheduling, availability, and bookings.
Custom entities across CRM and ERP boundaries, not just sales objects.

3. Your team wants a TypeScript-first framework

Both are modern, but if your engineering culture is:

TypeScript/React everywhere
Comfortable with Next.js, Node.js, ORMs, DI
Used to building product architectures rather than customizing monoliths

…then Open Mercato’s stack will feel native.

You can think in modules, entities, events, and APIs instead of patching around a single CRM app.

4. You plan for AI agents and automation as first-class citizens

Twenty exposes good APIs for integrations and automations around a CRM.

Open Mercato intentionally brands itself as AI-supportive:

Strongly typed entities and APIs.
Event-driven architecture suitable for agents and background workflows.
Structured data across tenants and organizations.

If your roadmap includes AI agents that act inside your system (e.g., triaging tickets, orchestrating workflows, updating orders), having a framework designed for that use case is a big win.

5. You need strict multi‑tenant security and field‑level encryption

If you are building a platform in regulated or privacy‑sensitive domains:

Multi‑tenant, field‑level encryption is built into Open Mercato’s ORM lifecycle.
Encryption maps and deterministic hashes enable secure lookups while keeping PII encrypted at rest.

This kind of design is uncommon in typical CRM products, and it becomes crucial once you’re handling sensitive data for many customers.

When Twenty is the better choice

To keep it balanced: there are many cases where Twenty is exactly what you need.

Choose Twenty when:

You want a ready-to-use CRM with modern UX.
Your main needs are pipelines, contacts, tasks, basic automation and reporting.
You prefer to customize through configuration, views, and light scripting instead of building modules.
You value a CRM-focused product roadmap and AGPLv3 self-hosting option.

In that situation, Open Mercato might be too low‑level—you would be rebuilding a CRM that Twenty already provides.

Decision checklist

Here’s a quick decision helper:

“We need a great CRM our GTM team can adopt fast” → Twenty
“We’re building a multi‑tenant SaaS / vertical platform” → Open Mercato
“Our scope is CRM-only” → Twenty
“We need CRM + operations + custom workflows in one product” → Open Mercato
“We customize via config, fields, views” → Twenty
“We design modules, entities, APIs, and AI workflows” → Open Mercato
“We want AGPL CRM we can self-host” → Twenty
“We want an MIT foundation to build on and extend” → Open Mercato

Open Mercato vs ERPNext: When a Modern TypeScript Framework Beats a Mature ERP

Tomasz Karwatka — Wed, 25 Mar 2026 20:07:36 +0000

Open Mercato is often misunderstood as “yet another ERP,” but it actually plays a very different role than ERPNext. Where ERPNext is a mature, full‑featured ERP, Open Mercato is a modern TypeScript framework for building your own ERP/CRM‑like platforms.

In this article I’ll compare both projects and then zoom in on when Open Mercato is the better choice.

Quick overview: framework vs product

Before diving into architecture and features, it’s useful to clarify positioning.

Open Mercato – a framework for building CRM/ERP/commerce platforms, headless/API‑first, module-centric, AI‑supportive. It gives you the building blocks to create your own B2B SaaS or internal platform.
ERPNext – a ready‑made ERP covering accounting, inventory, HR, projects, manufacturing, and more. You configure it, extend it, and run your company on it.

You can think of Open Mercato as “Next.js for ERP/CRM products” and ERPNext as “WordPress for running your company”: technically both are extensible, but they optimize for very different use cases.

Positioning table

Aspect	Open Mercato	ERPNext
Primary role	Foundation framework for custom ERP/CRM/commerce	Full, generic ERP application
Orientation	Product builders, dev shops, SaaS teams	Businesses that want a ready ERP
OOTB scope	Core CRM/ops modules, meant to be extended	Large set of business modules out of the box
Mental model	“Build your own vertical platform”	“Adopt and adapt an ERP”

Architecture and tech stack

One of the sharpest differences is in architecture and tech choices.

Open Mercato architecture

Open Mercato is built with a modern JS/TS stack:

TypeScript everywhere
Next.js (App Router) on the frontend
Node.js backend with dependency injection
ORM (e.g. MikroORM) with per‑module schema and migrations
PostgreSQL as a default relational database
Modular design: each feature lives in src/modules/<module>

Key ideas:

Each module owns its entities, migrations, services, and API.
Multi‑tenancy is a first‑class concern (tenant/org IDs, scoping).
The system is explicitly designed to be extended without modifying core code (Open–Closed Principle).

This is very natural for modern product teams who already live in the TypeScript / React ecosystem.

ERPNext architecture

ERPNext is built on the Frappe framework:

Python on the server side
Frappe as the web framework with DocTypes as central concept
MariaDB/PostgreSQL as database
Frontend using JS/Vue, server‑rendered pages and forms
A layered architecture of modules, controllers, DocTypes, and reports

Key ideas:

You model business data via DocTypes (similar to strongly structured models).
You extend via Frappe apps, custom DocTypes, hooks, and scripts.
The system is monolithic‑but‑modular: a large codebase where many modules share the same environment.

Architecture table

Aspect	Open Mercato	ERPNext
Language/stack	TypeScript, Next.js, Node.js, PostgreSQL	Python (Frappe), MariaDB/Postgres, JS/Vue
Architecture	Modular, per‑module schema, DI, multi‑tenant	Monolithic‑but‑modular on Frappe
API/headless	Headless/API‑first by design	Traditional web app; APIs via Frappe
Encryption	Field‑level encryption hooks in ORM, multi‑tenant	Mostly handled via DB + app‑level patterns

Extensibility and customization

Both projects are extensible—but the style of extensibility is different.

Open Mercato approach

Open Mercato is built around the Open–Closed Principle: you extend modules, but you don’t modify core code.

Typical customization patterns:

Add new modules under src/modules/*
Define custom entities, with migrations generated per module
Create dynamic forms and custom fields through an admin layer
Hook into domain events and subscribers
Use overlays and configuration to change behavior without forking

This feels similar to how you extend a modern web framework: strong boundaries, clean dependency injection, and a clear place to put your code.

ERPNext approach

ERPNext customizations are usually done via Frappe apps and DocTypes:

Define new DocTypes and custom fields
Add server scripts and client scripts
Use hooks and events to react to changes
Modify forms, reports, print formats, workflows

It is powerful, but because it sits inside one big ERP, it’s easy to end up with tightly coupled business logic that is harder to extract or reuse outside that context.

Extensibility table

Aspect	Open Mercato	ERPNext
Custom entities	First‑class via modules + ORM + dynamic forms	DocTypes and custom fields
Code isolation	Clear module boundaries, DI, overlays	Possible, but easy to create cross‑module deps
Workflows/events	Domain events, subscribers, tenant‑level workflows	Built‑in workflow engine and hooks
Multi‑tenant SaaS	Multi‑tenant by default	Typically single‑tenant per site

Product maturity and ecosystem

Another major difference is maturity and the surrounding ecosystem.

Open Mercato

Open Mercato is a newer project:

v0.x releases
Fast‑moving roadmap
Growing early adopter community
Dev‑first docs and examples
MIT license for the framework

This is appealing if you want a modern codebase and are comfortable shaping the platform with the maintainers.

ERPNext

ERPNext is a very mature ERP:

Over a decade of development
Thousands of deployments globally
Large community and partner ecosystem
Rich documentation, tutorials, and implementer know‑how
GPLv3 license for ERPNext itself

This is appealing if you want proven ERP workflows and a big ecosystem of implementers and community answers.

Maturity table

Aspect	Open Mercato	ERPNext
Age	Young, fast‑moving	>10 years of evolution
Ecosystem	Early dev‑focused community	Large global user & partner base
Modules	CRM, operations, scheduling, sales	Finance, HR, MRP, inventory, projects…
Licensing	MIT	GPLv3

When Open Mercato is the better choice

Now the key question: when does it make more sense to choose Open Mercato instead of ERPNext?

1. You are building a SaaS product, not just implementing an ERP

If your main goal is to create a B2B SaaS product (horizontal or vertical) rather than just digitize one company’s processes, Open Mercato is a far better starting point.

Typical examples:

Vertical SaaS for a niche industry with non‑standard workflows
Multi‑tenant platform used by many organizations
Marketplace or ecosystem where each tenant has its own rules
Product where the “ERP‑like” part is just one piece of the value

In these scenarios, you will spend more time fighting a classic ERP to behave like a product platform than you save from prebuilt modules.

2. You need deep, domain‑specific workflows

ERPNext shines when your processes are reasonably close to “standard ERP” patterns: sales orders, purchase orders, inventory, HR, manufacturing, projects.

If your domain is weird (in a good way):

Complex multi‑stage operations
Heavy collaboration flows
Unique compliance or audit requirements
Time/resource scheduling that doesn’t map to standard MRP

…then Open Mercato gives you the primitives to model your domain cleanly without hacking around an existing ERP abstraction.

3. You want a TypeScript/React engineering experience

If your team is already all‑in on:

TypeScript
React / Next.js
Node.js
Modern tooling (ESLint, Prettier, pnpm, Turbo, etc.)

…then you’ll simply ship faster with Open Mercato than with a Python + Frappe stack.

There’s a huge productivity win in using the same language and mental model across backend, frontend, and shared types.

4. You plan heavy AI and automation from day one

Most ERP systems were not designed with AI‑first use in mind. If your product vision involves:

Agents that act inside your system
Copilots that help users complete flows
Automated decision‑making based on structured data

…then a framework with:

Strong typing
Clear domain models
Event‑driven architecture
Well‑structured APIs

is simply a better foundation. That’s exactly the space Open Mercato aims at.

5. You care about clean module boundaries and long‑term maintainability

Open Mercato’s emphasis on:

“Extend, don’t modify core”
Clear module boundaries
Overlays instead of forks
Per‑module migrations

is designed to make long‑term evolution much safer. If you expect many years of development, multiple product lines, and an evolving roadmap, this pays off.

With ERPNext, you can architect for maintainability too, but the gravitational pull of “just patch the ERP” is strong, especially under time pressure.

6. You need field‑level encryption in a multi‑tenant environment

If you’re handling sensitive data (healthcare, finance, legal, etc.) for many tenants, the combination of:

Multi‑tenant by design
Field‑level encryption hooks at the ORM layer

gives Open Mercato an edge as a foundation for regulated or privacy‑sensitive products.

When ERPNext is the better choice

To be fair: there are many scenarios where ERPNext is the obvious answer.

Pick ERPNext when:

You need a mature ERP running your own company’s operations.
Your processes are close enough to standard ERP flows.
You want to go live quickly with minimal low‑level coding.
You value a large implementation ecosystem and battle‑tested modules.
Your team is comfortable with Python and Frappe.

In that situation, Open Mercato might be too low‑level: you’d be rebuilding modules that ERPNext already has.

Decision checklist

You can use this checklist as a quick decision tool:

“We’re building a multi‑tenant SaaS product” → Open Mercato
“We’re implementing ERP for one company” → ERPNext
“We live in TypeScript/React world” → Open Mercato
“We have Python/Frappe expertise” → ERPNext
“Our domain is highly custom, non‑standard” → Open Mercato
“Our flows look like typical ERP processes” → ERPNext
“AI‑first product with agents and automation” → Open Mercato
“We just need best practices ERP with reports” → ERPNext

If you tell me whether you’re building a new SaaS product or looking to run internal operations, I can help you sketch a more concrete architecture and module split for your case.

Open Mercato vs Odoo: Why the Future of ERP Is Framework-Based (Not SaaS)

Tomasz Karwatka — Tue, 17 Mar 2026 10:00:57 +0000

Open Mercato vs Odoo: The Future of ERP Is Not What You Think

Most companies don’t need another ERP.

They need a way to build their own.

For years, tools like Odoo have dominated the SME ERP space.

They’re flexible, modular, and relatively affordable.

But there’s a catch.

They were designed for a world before AI-assisted engineering.

And that changes everything.

TL;DR

Odoo = configurable ERP product
Open Mercato = AI-native ERP framework
One helps you adapt to software
The other lets you build software around your business

What is Odoo?

Odoo is one of the most popular open-source ERP systems in the world.

It offers:

CRM
Accounting
Inventory
HR
eCommerce

All in one platform.

Why companies choose Odoo

Huge ecosystem
Ready-made modules
Faster time-to-start
Large partner network

It’s a solid choice if your business fits into existing patterns.

Where Odoo Starts to Break

Here’s the uncomfortable truth:

The moment your business becomes unique… Odoo becomes expensive.

Common problems teams hit:

Customization hell

You start simple → end up rewriting core modules
Upgrade pain

Customizations break with every major release
Vendor / partner dependency

You don’t own your system — your integrator does
Rigid data model

Extending core entities is harder than it should be
Not AI-native

AI is an add-on, not a foundation

Enter Open Mercato

Open Mercato is not an ERP.

It’s a framework to build your own ERP/CRM systems using:

TypeScript
Next.js
Modular architecture
AI-assisted development

Think: “Laravel for ERP” instead of “another SaaS tool”

Product vs Framework

Feature	Odoo	Open Mercato
Type	Product	Framework
Customization	Limited / fragile	Native
AI integration	Add-on	Built-in mindset
Data model	Predefined	Fully flexible
Ownership	Partial	Full
Upgrade risk	High with customizations	Controlled
Dev experience	Mixed	Modern (TS/Next.js)

Why This Matters in the AI Era

AI is compressing software development.

What used to take:

weeks → days
days → hours

So the real question is:

Why adapt your business to software…

when you can adapt software to your business?

Open Mercato Philosophy

1. 80% Done Core

You don’t start from zero.

You get:

auth
entities
workflows
permissions
UI patterns Then extend the remaining 20%.

2. Modular Everything

entities
modules
workflows
extensions No hacks. No core rewrites.

3. AI-Assisted Engineering First

Open Mercato assumes:

Every developer works with AI.

So:

architecture is predictable
code is composable
patterns are repeatable

This is critical for scaling teams.

4. Self-Hosting by Default

Your data. Your infra. Your rules.
No lock-in.

Real Strategic Difference

Odoo mindset:

“How do we fit our business into this system?”

Open Mercato mindset:

“How do we build a system around our business?”

When Odoo Makes Sense

Choose Odoo if:

You need something fast and standard
Your processes are typical
You don’t have strong dev capabilities
You’re okay with partner dependency

When Open Mercato Wins

Open Mercato shines when:

Your business is non-standard
You want full control
You build internal tools as a competitive advantage
You believe in AI-assisted engineering
You want to productize your operations

Especially relevant for:

software consultancies
marketplaces
logistics
healthtech
B2B platforms

The Bigger Shift

We’re moving from:

Software as a Product → Software as a Capability

ERP is no longer something you buy.

It’s something you build and evolve continuously.

Try Open Mercato

If you’re:

tired of ERP limitations
building internal tools anyway
experimenting with AI coding

Then Open Mercato is worth testing.

Final Thought

Odoo was built for the last generation of software.

Open Mercato is built for the next one.

The companies that win won’t be the ones with the best tools…

but the ones that can build their own fastest.

Bonus: A Simple Heuristic

If your ERP roadmap looks like this:

“We need to customize this module…”
“We need another integration…”
“We need a workaround…”

You’re fighting the system.

If it looks like this:

“Let’s build a module”
“Let’s extend the model”
“Let’s automate this workflow with AI”

You’re building leverage.

Get Started with Open Mercato

https://github.com/open-mercato/open-mercato

Building Resilient Business Logic: A Deep Dive into the Open Mercato Workflow Engine

Tomasz Karwatka — Thu, 05 Feb 2026 11:10:11 +0000

Streamlining Business Processes: An Overview of the Open Mercato Workflow Engine

In the world of enterprise software, managing complex, long-running processes—like multi-stage approvals, manufacturing cycles, or intricate checkouts—is a notorious challenge. Hard-coding these paths leads to "spaghetti code" that is difficult to maintain and even harder to audit.

A recent technical walkthrough by Patrick from Open Mercato showcases their Workflow Engine, a robust solution designed to act as a "recipe" for these business processes.

Core Components of the Engine

The engine is built on four fundamental pillars that provide a balance between high-level orchestration and granular control:

Steps: The distinct stages of a process (e.g., "Draft," "Pending Approval," "Completed").
Transitions: The logic paths connecting one step to another.
Activities: Actions triggered during a transition. Think of these as the "heavy lifters"—sending emails, calling external APIs, or triggering webhooks.
Conditions: The "gatekeepers" of your logic. These are business rules that evaluate whether a transition is allowed to happen (e.g., "Is the order total above $500?").

Architecture: Blueprint vs. Instance

One of the most important concepts highlighted in the demo is the separation of concerns between Definitions and Instances:

The Blueprint Analogy: A Workflow Definition is the architectural plan. A Workflow Instance is the actual building.

Every time a process starts, a unique instance is spawned. This allows administrators to track the specific state, context data, and execution history of every single transaction in real-time.

Developer & Admin Experience

Open Mercato leans heavily into usability without sacrificing power:

1. Visual Editor & Live Validation

The platform features a drag-and-drop canvas. To prevent broken logic, the Live Validator provides real-time feedback, ensuring that every workflow has a valid start, an end, and reachable nodes before it is ever published.

2. Event-Driven Execution

Workflows aren't just manual; they can be hooked into the system's event bus. For example, a "New Order Created" event can automatically trigger the start of a fulfillment workflow.

3. Dynamic User Tasks

The engine can render dynamic forms. If a workflow hits a "User Task" step, it can present a specific UI to the operator—like a shipping details form—and wait for that input before moving to the next stage.

Auditability via Event Sourcing

For enterprise compliance, knowing why something happened is as important as knowing what happened. The engine uses an execution timeline backed by event logs. This provides a transparent trail of every activity success, failure, or condition check, making debugging and auditing straightforward.

The Roadmap: AI-Assisted Workflows

The demonstration concludes with a look at the future: an AI Agent currently in development. This tool will allow users to describe a business process in plain language and have the engine automatically generate the visual nodes and logic.

Conclusion

The Open Mercato Workflow Engine represents a shift toward "Low-Code" for the enterprise, where business logic is visible, editable, and auditable without losing the power of a traditional backend.

What are you using for workflow orchestration in your current stack? Let's discuss in the comments!

Live Coding with AI

Tomasz Karwatka — Tue, 27 Jan 2026 12:13:22 +0000

Live Coding an Actionable Notifications System with AI-Assisted Engineering

Modern business apps live or die by their notifications.

Not the annoying kind — but the ones that:

reflect real system state
support long-running processes
allow users to take action immediately
and don’t collapse under complexity as the app grows

In this post, I’ll walk you through how we’re building exactly that in Open Mercato using a live-coding workflow powered by AI-assisted engineering.

Live Coding an Actionable Notifications System with AI-Assisted Engineering

Modern business apps live or die by their notifications.

Not the annoying kind — but the ones that:

reflect real system state
support long-running processes
allow users to take action immediately
and don’t collapse under complexity as the app grows

In this post, I’ll walk you through how we’re building exactly that in Open Mercato, using a live-coding workflow powered by AI-assisted engineering.

This is not a demo of “magic AI”.

It’s a very practical look at how AI fits into real software development — bugs, reviews, refactors included.

Why Notifications Matter More Than You Think

In most systems, notifications are treated as an afterthought:

a toast
a badge
maybe an email

But in real business software, notifications are the coordination layer between people and processes.

They need to:

show progress of background jobs
signal events that require attention
enable decisions and approvals
adapt to different delivery channels

So we built notifications as a first-class module, not UI sugar.

Actionable Notifications (Not Just “FYI”)

A key design decision in Open Mercato:

Notifications are executable.

Example: Leave request approval

An employee submits a leave request
A notification is created for users with approval rights
The notification contains embedded actions
The approver clicks Approve
The state updates immediately — no extra screens, no context switching

This is not a hack.

It’s part of the notification contract.

Notifications can:

run commands
trigger workflows
update domain state

Custom Renderers: One Notification ≠ One UI

Different notifications need different representations.

So instead of a single generic component, we support custom renderers per notification type.

That allows us to:

show domain-specific data
embed contextual actions
evolve the UI independently of the backend

Example:

Leave request → approval buttons
Sales order created → totals, items, status
Background job → progress + logs

The notification system is extensible by design.

Shipping Code, Then Letting AI Review It

After implementing the notifications module, I opened a pull request and immediately did two things:

requested review from a core team member
requested review from GitHub Copilot

The AI review surfaced:

missing i18n keys
duplicated DTOs
outdated documentation
unused React refs
inconsistent imports

Nothing dramatic — but all real issues.

This is where AI shines:

👉 fast, boring correctness checks

Fixing Issues with AI (Without Losing Control)

I didn’t blindly auto-apply fixes.

Instead:

I fed Copilot’s comments into Codex / Claude
fixed issues one by one
validated changes locally
kept PR history clean and readable

Important observation:

AI is excellent at spec changes and refactors

It’s less reliable at deep architectural decisions

So I use it as a force multiplier, not an architect.

When CI Fails: Let AI Run the Build

After merging fixes — CI broke. Typings.

Instead of hunting logs manually:

I asked the AI to run the full build
identify type errors
fix them safely

This included:

Next.js build
type-checking
linting

Result:

✅ green CI

✅ mergeable PR

✅ no broken deploys

Improving Notifications: Making Them Dynamic

One thing bothered me.

Sales order notifications showed static data:

item count
totals at creation time

But sales orders change.

So the plan:

move from serialized snapshot data
to dynamic rendering
fetch current order state when rendering the notification

Same notification.

Live data.

This is where custom renderers really pay off.

The Bigger Idea: Multi-Channel Delivery Strategies

Here’s the real extension.

Today:

notifications are stored in the database
rendered in the UI

Tomorrow:

database notifications
email
SMS
push
multiple strategies at once

Inspired by how Open Mercato handles search strategies, we’re extending notifications with:

pluggable delivery strategies
multiple active channels simultaneously
configuration via the existing config module

Key rules:

UI notifications = interactive
email / SMS = read-only
all links deep-link back to the admin panel

Emails will use React-based templates, same mental model as the UI.

This Is How We Actually Work with AI

No hype.

No “AI replaces developers”.

Just:

faster reviews
safer refactors
less context switching
more time thinking about architecture

AI doesn’t write the system.

It helps us ship it better.

What’s Next

This extension is bigger, so it won’t land in a single video.

But:

a PR is coming
links will be shared
feedback is welcome

And yes — if this kind of real, imperfect, live engineering is useful, I’ll keep recording it.

Open Mercato is open-source.

If you want to build serious business apps without reinventing the boring 80% — you’re invited.

Let me know what you’d like to see next.

Open Mercato Vision: A New Era of Enterprise Software

Tomasz Karwatka — Mon, 12 Jan 2026 11:54:24 +0000

Mission: The end of the era of adapting to systems

In a world driven by AI, traditional "out-of-the-box" SaaS solutions are no longer enough, and classic custom development is too slow and expensive. Clients no longer want to pay for developer "billable hours"—they want immediate results and software that perfectly adapts to their unique business processes.

Open Mercato is an AI-native CRM/ERP foundation framework that combines the speed of SaaS with the infinite flexibility of tailor-made solutions.

Built for AI: Open Mercato was built using AI Assisted Engineering techniques and is designed so that its users can leverage these techniques optimally to create new dedicated functions and modify existing ones.
Ready-to-use Context: Contexts, documentation, guardrails, specifications, and prompts—everything is prepared and available in the package, ready to start your work with Claude, Codex, or GitHub Copilot (or any other agent).

Our USP: Why do we win?

Flexibility: Open Mercato can address processes unique to every company—that is our focus. We provide flexibility without the need to rewrite "commodity" features. We take responsibility for their maintenance and security, freeing the client's developers from creating and maintaining them.
Speed: We deliver unique business functions faster than anyone on the market by utilizing ready-made, maintained core components.
Open-Closed (OCP): The system is delivered as npm packages, and a dedicated implementation is created as an app that can overwrite and change all components, pages, and modules.
Extensibility: A very extensive event system is available, and most elements, such as the queue system, cache, and others, are replaceable based on Strategy and Dependency Injection (DI) patterns. This allows you to build a 100% dedicated application using, for example, 80% of Open Mercato's functionality without modifying the core system, maintaining the ability for very fast updates.
Modern Tech Stack: Few systems of this class are built on Next/React and TypeScript, which is currently the most popular tech stack for applications. Consequently, AI coding agents perform best on it (as React/shadcn and next.js apps form the largest codebase for their training). We also utilize functional programming and modern React design patterns.
Enterprise-Grade Security: Unlike many systems on the market, we offer SOTA (state-of-the-art) data encryption, where you can configure which database fields are encrypted with an individual key. Every data access is monitored (logs), and operations can be reversed from within the application (undo/redo). This opens doors to demanding sectors like HealthTech or Finance. Our standard security gives developers and agents freedom to create and administrators peace of mind.
Enterprise Design Patterns: AI is good at fast coding but often takes shortcuts. Not in Open Mercato—we ensured the use of enterprise-class design patterns, including replaceable strategies, SAGA, SOLID principles, and sensitive data storage rules. This provides a solid framework for AI agents to create dedicated functions while maintaining the quality expected by business and security departments.

Scalability and Value

We are moving away from selling people's time and toward selling ready-made business solutions based on our proprietary framework. This allows us to drastically increase margins and business scalability. We deliver immense value to clients, priced—where it makes sense—in a fixed price model.

AI-Native from the Foundations: Open Mercato doesn't just "bolt on" AI. Data, workflows, and the permission system are designed from the start for AI agents. When adding new functionalities with AI agents, you use the exact same context and tools we used to create Open Mercato.
Spec-Driven Development: We encourage this approach to improve team communication and ensure the logging of design decisions (ADR - Architecture Decision Records).

ICP (Ideal Customer Profile)

Our ideal clients are large companies launching new projects, testing new business processes, or introducing innovations that need a secure backend/framework. They don't want to rely on old, slow-to-develop systems. They want a project delivered on time and within budget, with the option to pay for additional feature requests at high hourly rates. Former ReTool users are also potential clients—they get similar base functionality but with AI-powered function creation and full ownership of data and code (IP).

Business Model: A Hybrid of Product and Expertise

Open Mercato is more than a tool - it is infrastructure for a new generation of applications built directly for real problems. From 2026, we are committing to this direction fully, creating an organization that defines modern corporate software: as secure as enterprise, as flexible as custom dev. Our structure is based on a model where a proprietary product serves as the backbone for high-specialty implementation services.

Product (Core): The foundation that handles the heavy lifting of infrastructure (login, billing, permissions, security). Thanks to the Open-Closed (OCP) principle, the system is open for extensions but closed for core modifications, eliminating technical debt.
Consulting (Delivery): We are moving from a classic software house to a "McKinsey with code" model. Our team consists of elite, highly technical consultants who can enter an organization, understand its unique business value, and deliver a finished application in a week—not months.

Future: The New Era of Enterprise Software - Manifesto

AI is killing the logic behind rigid, "one-size-fits-all" SaaS. Today, thanks to AI, software perfectly matched to a specific company can be built in a short time. Clients no longer want to pay for "man-hours"; they want results. Fast.

Software will be manufactured completely differently. That is why we are creating Open Mercato.

Companies want four things simultaneously:

SaaS-like speed of launch.
Custom dev-like flexibility.
Enterprise-grade security.
Reasonable costs.

The Problem: This cannot be delivered with classic tools. It can only be achieved by leveraging AI rather than fighting it. One must lead this wave by developing AI Assisted Engineering capabilities that can increase team productivity by 3x to 10x.

The Solution: Open Mercato is an AI-supportive CRM/ERP foundation framework for building proprietary corporate software.

Why this changes the game for software-creating firms?

Build the product, not the infrastructure: Login, roles, permissions, design system, multi-tenancy, billing, audit, security, encryption, and GDPR compliance are all ready. The team focuses only on what generates value.
Open-source "SaaS" with no ceiling: Following OCP principles, you can create extensions without forking or messing with the core. No maintenance nightmare.
AI-native from the foundations: Everything is designed for AI agents. Your team will learn new skills that increase efficiency tenfold without raising costs.
Enterprise-grade security out of the box: SOTA encryption with individual keys per field and tenant-scoped encryption. You can sell to HealthTech, Finance, and large corporations without fear of security audits.

Open Mercato is the infrastructure for the next wave of applications built directly for real business problems.

Next steps

Check the project: Open Mercato ERP/CRM od GitHub
See the demo: Demo Open Mercato
Visit our Discord: Open Mercato Discord

What is Open Mercato? Is this the future of Enterprise Software?

Tomasz Karwatka — Thu, 08 Jan 2026 10:39:07 +0000

Open Mercato gives you a ready-to-use business engine.
It already has about 80% of what most companies need, so you can focus on what makes your business different.
Instead of building everything from scratch, you start with a solid core and add only what makes you special.

What’s inside Open Mercato?

1. CRM Modules

Everything you need to run sales and customer relationships:

Companies & People – One place for all customers and contacts, with custom fields and relationships
Deals (Opportunities) – Track sales and negotiations
Sales Pipeline – Visual stages: Lead → Qualified → Closed
Timeline & Activities – Emails, notes, calls and events linked to every customer and deal

2. ERP & Operations

Tools to run the day-to-day business:

Orders – From order received to delivery and status tracking
Production – Manage manufacturing and internal workflows
Resource Scheduling – Plan teams, machines and availability

3. Commerce & B2B

Everything needed to sell:

Catalog – Products, services, variants and price lists
Quotes (CPQ) – Configure, Price and Quote
Sales Channels – Online store, partners, direct sales
Self-service Portals – Customers and partners place orders, download invoices, see their data

4. Enterprise Foundation

This is what makes Open Mercato “enterprise-grade”:

Organizations & Users – Multi-company, multi-team support
Data Designer – Design your own data models; UI and APIs are generated automatically
Business Rules & Workflows – Automate processes
Security & Encryption – Each client has their own encryption key
Vector Search – AI can search your data semantically
Audit Logs – Every change is tracked (compliance ready)

The big architectural advantage: Open–Closed Principle (OCP)
All modules are open for extensions, closed for modification.

That means:

You extend the system
You never touch the core

Example:

You use the Orders module
You add medical-industry validation rules as a plugin
When Open Mercato is updated, your custom logic still works

No forks. No broken upgrades. No drama.

Industry Blueprints

Healthcare (patients, clinics, labs)

What matters: security, compliance, full patient history

Used modules:

Data Designer – Medical records, lab results
Encryption – Each client has their own data key
Audit Logs – Who accessed which patient and when

With OCP:
You add HL7 / FHIR integration as a plugin.
The core keeps data safe and compliant. Your extension handles healthcare logic.

B2B Retail & Wholesale

What matters: price lists, discounts, partner portals

Used modules:

Catalog & Sales Channels– Different prices for different partners
CPQ (Quotes) – Automated quoting
Self-service Portals – Partners order and download invoices
Business Rules – Loyalty discounts

With OCP:
You add Dynamic Pricing as a plugin.
Upgrades won’t break your pricing logic.

Logistics & Warehouses

What matters: orders, vehicles, locations, status updates

Used modules:

Orders – Shipment lifecycle
Resource Scheduling – Trucks and drivers
Workflows – Warehouse → In Transit → Delivered
Vector Search – AI search across addresses and shipments

With OCP:
You plug in GPS & telematics.
Core handles users and security. Your plugin handles vehicle data.

Why this works

Because Open Mercato follows OCP:
You build a product, not infrastructure.
Login, security, roles, billing, audit logs, multi-tenancy — it’s already done.

The money part

In every blueprint you save 600–800 developer hours just at the start:

No database bootstrapping
No permission system
No encryption
No basic UI

That means:

MVP in weeks, not months.
And yes — that’s the difference between a startup that ships and one that dies in Jira. 🚀

See the demo

Open Mercato Demo

Open Mercato FAQ

Tomasz Karwatka — Wed, 07 Jan 2026 14:43:48 +0000

Short intro: Open Mercato is the AI-Supportive Foundation for Enterprise Software

Open Mercato is an open-source foundation framework designed to accelerate the development of advanced CRM, ERP, and e-commerce platforms. It bridges the gap between rigid, "one-size-fits-all" SaaS solutions and the high cost/risk of building custom software from scratch.

Why it’s a Game-Changer:

Focus on Value, Not Infrastructure: We handle the "80% of repetitive code"- multi-tenancy, RBAC (Role-Based Access Control), billing, and audit logs - so your team can focus on the 20% that actually drives business value.
Compliant with the Open–Closed Principle (OCP) - open for extension, closed for modification, so you can build custom changes without forking or touching the core system.
AI-Native & Security-First: Engineered for the AI era, Open Mercato includes tenant-scoped encryption by default. Each client has their own encryption key, making it safe for Healthtech, Finance, and Enterprise deployments.
Modern Tech Stack: Built for developers by developers using Next.js, TypeScript, PostgreSQL, and MikroORM.

"Software Houses using Open Mercato stop selling 'dev hours' and start selling 'business transformation' with higher margins and zero technical debt."

Vision & Strategy

Does "fast" mean "low quality"? How do you avoid the "spaghetti code" often associated with AI generation?

The fear that speed equals poor quality is justified when talking about raw AI-generated snippets. However, Open Mercato is not a "code generator"; it is a foundation framework.

Guardrails: We provide a production-ready stack (Next.js, TypeScript, MikroORM) with built-in patterns for multi-tenancy and security.
Predictability: Instead of letting AI hallucinate an entire architecture, developers use Open Mercato’s structured modules, entities, and workflows. AI is used to accelerate the population of this proven structure, not to reinvent the wheel every time.

If AI can build software, why do I need Open Mercato? Why not just prompt a full app?

Prompting a full enterprise application from scratch often leads to a "dead end" where the lack of architectural consistency makes maintenance impossible.

The "Engine" Advantage: Open Mercato provides the "plumbing"—auth, multi-tenancy, RBAC, and encrypted data layers—which are notoriously difficult to prompt correctly and securely.
Focus on Value: We allow your team (or the AI) to focus 100% on unique business logic rather than rebuilding login screens and API wrappers for the thousandth time.

Is this just another "Boilerplate" or "Starter Kit"?

No. A boilerplate is a one-time copy-paste that becomes a maintenance nightmare as it diverges.

Open–Closed Principle (OCP) - open for extension, closed for modification, so you can build custom changes without forking or touching the core system
Seamless Updates: Because you aren't forking the code, you can update the Open Mercato base to the latest version while keeping your custom business logic intact.

Security & Enterprise Compliance

Is "Tenant-Scoped Encryption" just a marketing buzzword?

Actually, it is a sophisticated technical implementation rare in standard frameworks.

How it works: We use field-level encryption where each tenant (client) has their own unique encryption key. Even if the database is compromised, data from Client A cannot be decrypted with Client B’s key.
Performance: We use AES-GCM wrappers within the ORM lifecycle, ensuring that while data is encrypted at rest, CRUD operations remain fast.

Can this really pass a heavy Enterprise or Healthtech audit?

Yes. Open Mercato was designed specifically for high-stakes industries.

RBAC & Feature Flags: We offer feature-based Role-Based Access Control that can be scoped down to the individual user or organization level.
Auditability: Every entity and query is automatically isolated by tenant_id and organization_id, preventing cross-tenant data leaks by design.

Architecture

Why TypeScript and not a "classic" ERP language?

We chose a modern stack (Next.js App Router, TypeScript, zod, Awilix DI) to maximize developer productivity and AI compatibility.

Type Safety: TypeScript ensures that as you scale and customize, the system remains self-documenting and less prone to the runtime errors that plague large-scale ERPs.
Web-Native: Modern businesses demand real-time, responsive interfaces and "Headless" API capabilities, which the TypeScript ecosystem excels at.

How do you handle complex local accounting requirements?

Open Mercato is a foundation, not a finished ERP.

Module-Based: You can build or plug in for "Accounting" or "KSeF" module.
The Ecosystem: Our goal is for the community to contribute these specialized modules, which can then be shared or sold, similar to how specialized plugins work in other ecosystems but with enterprise-grade stability.

How to Prevent Technical Debt using Open Mercato

In traditional software development, when a developer needs to customize a framework for a client, they often fork the repository. This creates an immediate and permanent divergence:

Security Debt: You can no longer easily pull upstream security patches because your custom code has "mutated" the core.
Update Paralysis: Over time, the cost of merging the original framework's updates becomes so high that the project is "frozen" on an old, vulnerable version.
Vendor Lock-in: The client becomes a hostage to whoever wrote the custom modifications, as no one else can untangle the "spaghetti" of core vs. custom logic. Open Mercato solves this by treating the core framework and your custom business logic as two distinct, non-destructive layers.

Architectural Separation

Instead of modifying the source code of a core module, you create an Overlay.

Non-Destructive: You can overwrite any fragment of the system - from a single UI button to a complex backend validation logic -without touching the core files.
Auto-Discovery: The framework is designed to automatically detect these overrides at runtime, prioritizing your custom logic over the default "out-of-the-box" behavior.

Dependency Injection (DI) as a Power Tool

We use the Awilix DI container to manage how services are loaded.

Service Overriding: Every module has a di.ts file. If you need a different calculation for "Tax" than what the core ERP provides, you simply register your new service in the DI container.
Request-Scoped: The container is constructed per request, allowing for different logic to be injected based on the specific tenant or user context.

Modular "Lego" Structure

The system is divided into self-contained modules located in src/modules/.

Encapsulation: Each module contains its own APIs, database entities, and frontend pages.
No Global Schema: Database migrations are generated and applied per module, preventing a "monolithic" database that is impossible to change.

By using Feature-based RBAC and Feature Flags, you can roll out these "Overlays" to specific clients or users without affecting the rest of the system.

Safe Testing: You can enable a new custom module for a single organization to test it in production safely.
Clean Slate: If a custom experiment fails, you simply delete the overlay, and the system instantly reverts to its stable core behavior.

Business & Software Houses

Will this "kill" developer jobs?

On the contrary, it evolves them. The era of billing for "basic CRUD" is ending because AI makes it a commodity.

From "Hours" to "Solutions": Software Houses using Open Mercato stop selling "dev hours" and start selling "business transformation".
Higher Margins: By reducing the time spent on infrastructure (the 80% of code that is the same in every app), you can deliver projects faster with higher margins while focusing on the complex 20% that actually solves the client's problem.

What about "Vendor Lock-in"? What if I want to leave Open Mercato?

Open Mercato is Open Source (GitHub: open-mercato).

No "Black Box": You have full access to the source code.
Standard Tech: We use industry-standard tools like PostgreSQL, Redis, and MikroORM. Your data and your custom logic are yours to move if you ever decide to deviate from the framework.

Getting Started & Support

Who takes responsibility when something breaks?

When an agency builds on Open Mercato, they remain the "service provider" for their client.
However:

Community & Backing: The project is supported by Catch The Tornado, an organization focused on building global tech companies.
Testing: We maintain growing unit and integration test coverage to ensure that the core remains stable even as you extend it. = Vibrant, Fast-Growing Community: Connect with the team and other builders in our Discord community.

How can I test this today?

You can spin up a full environment in minutes
Browse the full documentation at docs.openmercato.com