CRM projects come apart on the day somebody asks for a field.
A sales director wants to record which distributor introduced the lead. Over in service, the machine serial number belongs on the account, because that is how support conversations start. Both requests are small and both are obviously right, and in a licensed CRM both turn into a conversation about editions, admin rights and whether the integration you paid for will survive the change. Six weeks later the field lives in a spreadsheet somebody maintains by hand.
Open Mercato ships a CRM module in its core. This article is a walk through what is in it, what you can change without asking anyone, and what you end up owning. We are the.good.code;, a certified Open Mercato agency at the Agency tier and a contributor to the core, building AI-native CRM/ERP and CPQ systems for manufacturers and enterprise teams from Gdansk.
What is in the box on day one
The customers module describes itself in its own metadata as core CRM capabilities for people, companies, deals and activities. In the admin it appears as three workspaces under a single Customers section: Companies, People and Deals. Navigation is not hand-built. Pages auto-discover from module metadata, so once the customers.* features are assigned to a role, the section renders itself in the sidebar.
The unit of access there is a feature rather than a menu item, so the answer to "who can see the pipeline" is a permission you grant instead of a screen you hide. Anyone who has tried to lock down a CRM by removing links from a navigation bar knows why that distinction is worth having.
The Companies workspace, with lifecycle and next-interaction badges on the grid. Screen from the Open Mercato demo instance.
One thing first, because we have written about CRM before and we are not going to quietly change our position. In July we published an engineer's read of the AI-native CRM category and said plainly that we do not implement AI-native CRMs and had nothing to sell on that platform choice. That still holds. This is a different question. That article was about buying a finished CRM product. This one is about running CRM on a foundation you own outright, which is the layer we do work on.
The pipeline: list and board
Deals live under Customers → Deals with two views of the same records.
The list view is a sortable table carrying stage, probability, expected close, linked people and companies, and last update, with filters for narrowing by segment or owner. Export produces a CSV of whatever slice is on screen, and every column maps to the deal entity exposed at /api/customers/deals. Inline actions open the deal, duplicate it, or jump straight into logging an activity.
Stage, probability, expected close and linked people and companies sit in one sortable table. Screen from the Open Mercato demo instance.
The kanban board presents stages as draggable columns. Dragging a deal between stages updates it immediately, and an undo prompt appears after each change, which is the difference between a board people trust and a board people are frightened of. Lane metrics show deal counts per stage. The stages themselves are not hardcoded: they come from a dictionary under Customers → Configuration → Deal stages, each with its own colour coding.
The kanban board. Stages come from a dictionary, so renaming or reordering them is configuration. Screen from the Open Mercato demo instance.
The deal form captures title, status, pipeline stage, value, currency, probability and expected close date, with dictionary-driven dropdowns and custom fields in a panel on the right. Linking people and companies happens during creation or editing, and the search surfaces lifecycle badges so a seller can confirm they picked the right contact and not the one with a near-identical name.
Creating a deal. Dictionaries drive the dropdowns and custom fields sit in the right-hand panel. Screen from the Open Mercato demo instance.
The contact record, where the work happens
People sit under Customers → People with filters, saved searches and typeahead. Quick create opens a full-screen form honouring dictionaries for job titles, lifecycle and currency, with Cmd/Ctrl + Enter to save. Company assignment can happen during creation or later from either side of the relationship.
Quick create for a person, with dictionaries behind job title, lifecycle and currency. Screen from the Open Mercato demo instance.
Open a person and you get one timeline rather than two. Notes carry unstructured updates. Activities log calls, emails and meetings with icons, timestamps, authors and dictionary-driven types. A Deals tab lists every opportunity linked to the contact, and a Tasks tab syncs with the customer todos widget so follow-ups stay one click away.
Notes and activities share a single timeline per contact instead of splitting into two histories. Screen from the Open Mercato demo instance.
The piece we would point a sales manager at first is next interaction. It is a small block on the person record where you set the follow-up with a label, icon and highlight colour, and it then surfaces on the list view. It turns "who have we not spoken to" from a report somebody has to build into something visible on the screen everyone already looks at.
Setting the next interaction, with a label, icon and highlight colour that carry through to the list view. Screen from the Open Mercato demo instance.
Logged activities, each carrying author, dictionary-driven type and timestamp. Screen from the Open Mercato demo instance.
Companies mirror the same shape at account level: a tabbed layout holding people, activities, deals, addresses and tasks, with header badges showing how many associations exist before you open anything. Logging an interaction on the account attributes it to the company and to any selected contacts or deals, so the account timeline and the contact timeline stay the same set of facts rather than two versions of it.
The People tab on a company: link, unlink and open contacts without leaving the account. Screen from the Open Mercato demo instance.
Email on the contact record
Open Mercato's CRM email integration sends outbound email from a Person record and attaches inbound email from a connected mailbox to the right person's timeline. Supported providers are Gmail, including Google Workspace, and generic IMAP with SMTP, which covers Fastmail, Proton Bridge and Microsoft 365 through an app password.
The default runs the opposite way to most CRMs. The mailbox you connect stays yours alone: Open Mercato does not read another user's mailbox, and your emails reach teammates only when you explicitly flip an individual email to shared. Privacy is the default, and sharing is the deliberate act.
What you can change without asking anyone
This is the part that separates a CRM you own from a CRM you rent, and it is worth being concrete about which lever is which.
Dictionaries. Statuses, sources, lifecycle stages, job titles, deal stages and address types all live under Customers → Configuration. Each entry carries a label, icon and highlight colour so the badges stay consistent across the UI. Dictionaries respect the organisation hierarchy: entries marked inherited are read-only in child organisations and edited at the source, which cascades. Currency management sits in the same interface, with the customers CLI seeding the list from Intl.supportedValuesOf('currency').
Dictionaries under Customers → Configuration. Entries carry a label, an icon and a highlight colour. Screen from the Open Mercato demo instance.
Custom fields and custom entities. Fields introduced through the entity designer appear automatically on the company form and detail view. Records that have no home in the standard model get defined as custom entities, with their forms generated from the definition, without touching core code.
Permissions. View and manage rights are separate features per workspace: customers.people.view against customers.people.manage, and the same split for companies, deals and activities. Configuration is gated separately behind customers.settings.manage. Feature grants pair with organisation scope, so a multi-tenant deployment stays isolated by construction rather than by convention.
The audit trail. Creates, updates and deletes are recorded with the actor and the scope, and each entry carries a before and after snapshot with a field-level diff. "The close date changed" becomes "who changed it, from what, and when". Undo is command-based and its coverage grows with the platform, working today across tenants and organisations, users and roles, and sample records, with further modules joining as they ship their own undo handlers.
The API. Every workspace has a matching endpoint. /api/customers/people, /api/customers/companies, /api/customers/deals and /api/customers/dictionaries/{kind} carry the same operations as the UI, validated with the same schemas. Nothing in the interface is doing something the API cannot.
What you own at the end of it
The core is MIT licensed permanently, so the code you build on stays yours. If every vendor in this story disappeared tomorrow, the system would still run and somebody else could still maintain it, because it is TypeScript and Next.js rather than a proprietary runtime with a support contract attached to it.
That matters most in the boring case, which is also the common one. Two years in, somebody wants a field, a stage, an entity and a rule that nobody imagined at kickoff. On a licensed platform that is a procurement conversation. Here it is Tuesday.
The commercial shape is straightforward: MIT core, with the Enterprise Edition as a separate subscription covering certification, review and operational support. On the project's own published numbers, Open Mercato runs with more than a hundred contributors and upwards of 200 merged pull requests a week.
We have a measurement of what that foundation covers, from a different domain. The senior care operations build we published as one of three case studies on Open Mercato's own site came out at roughly 97% reusable core and around 3% domain logic: dashboards, care orders, weekly schedules and a signed service-confirmation workflow, with the team's time going almost entirely into the care domain rather than into platform plumbing. That was one hackathon build of an operations app, so treat the exact split as a data point from next door rather than a forecast for your CRM. The shape is what transfers. The pipeline, the timelines, the permissions and the audit trail arrive with the platform, and your effort goes into whatever your business does that nobody else's does.
Is this your next CRM?
Three questions decide it, and you can answer all three without talking to anybody.
Ask your team for the five things they wish the current CRM recorded and cannot. If all five are fields, dictionaries or a tab, this shape fits, because all five are configuration here rather than a licence conversation. If instead they are about quotes and orders, the seam between CRM and quoting is where we would look first, and we wrote that up in CRM and quoting integration for manufacturers.
Ask who needs to see what. If the answer involves one team seeing a subset of records another team owns, write that down as a requirement and design it early. Isolation runs on organisation scoping, which is the right tool when teams map to organisations; where the line runs inside a single organisation, that is a rule you build.
Ask what happens to your history. If the answer is "it lives in a system we are keeping anyway", the migration question shrinks to a CSV. If it is "we are switching off the old CRM", price the extraction as its own piece of work.
Frequently Asked Questions
Does Open Mercato have a CRM, or do I have to build one?
It ships one. The customers module covers companies, people, deals and activities, with a kanban pipeline, shared timelines, dictionaries, custom fields, per-feature permissions and an audit log. What you build is the part specific to your business, on top of that.
Can I add my own fields without a developer?
Dictionaries and custom fields are configuration and appear on forms automatically. New entities, meaning record types the standard model has no place for, are defined through the entity designer and generate their own forms without touching core code.
Who can read my emails if I connect my mailbox?
Only you. The connected mailbox is per user, Open Mercato does not read another user's mailbox, and emails are not shared with teammates unless an individual email is explicitly flipped to shared.
How is this different from an open-source CRM I could self-host?
The difference is what sits underneath. This is a CRM module on a platform that also carries workflows, business rules, an audit log with field-level diffs, multi-tenancy, an integration registry and an event layer, all under one permission model. You are not choosing a CRM application, you are choosing a foundation that happens to ship CRM as one of its modules. We went through that difference row by row in our Open Mercato and Salesforce comparison.
If you want a straight answer on whether this fits your sales process, bring the list of five things your current CRM cannot record to a welcome coffee. We will tell you which of them are configuration, which are a build, and which are a process decision somebody has been avoiding.
A note on the screens
Every screenshot above comes from the Open Mercato demo instance, published by the vendor in its own documentation. They show the product as it ships rather than any client deployment of ours.
Sources
- Open Mercato project documentation: Customers overview, People workspace, Companies workspace, Deals workspace, CRM email integration, audit logs
- Open Mercato, Senior Care Operations case study
- Open Mercato, The third path: buy, build, own the foundation and Open Mercato for agencies after 27 partners
- the.good.code;, AI-Native CRM Systems: What the Data Says and How the Options Compare