In this article
Adam asked me a question that left me quiet for longer than is polite: “I don't get the wow here. Claude goes into that code anyway and has to analyse it. So what exactly did this platform do?” It is the best question I have been asked while demoing Open Mercato — and the most uncomfortable, because it targets something I treat as obvious. It is not obvious at all.
This post is Adam's answer, taken apart. It is not a list of the prettiest features but five things that most often decide the conversation — plus a sixth, the warehouse module, which landed while I was literally recording material about the platform. I say “things” rather than “modules” on purpose: one of the five is not a module at all, and it is the one that answers Adam. For each I also say what it does not do, because a demo without that part is not a demo, it is an advert.
What a demo looks like
One rule I have kept for years: I never show an empty system. Before the meeting I load in a handful of real names from the company — their products, their statuses, their departments. Twenty minutes of work, and the difference is that instead of judging a tool, people start working in it and spot for themselves what is missing.
Second rule: I show a sequence, not a set of icons. First the data, then who sees what, then what happens on its own, and only at the end the pretty parts. In that order the first five modules line up almost by themselves — and so does the rollout that follows.
The third rule came out of stumbles: I never ask anyone to look at the big modules, only at the details inside them. A large system on the first screen overwhelms people — “my word, look at all these options” is a sentence I have heard more than once. But show the change history on a product's technical card and ask who in their company should be allowed to edit it and who only to view it, and the conversation shifts from judging an interface to designing their own company. That is when the sentence I wait for arrives: “I want that board and that history in mine”.
1. Your own fields and entities without waiting for a developer
The module that usually ends the “can this be adapted to us” debate. From the admin panel you add your own field to an existing object — an order, a customer, a job — or an entire custom entity, with no new release of the system and no ticket to anyone. To anyone who has lived inside a closed ERP that sounds suspicious: there, one extra field can be a separate order for a “custom solution”, quoted and pushed a quarter down the road.
Underneath, field definitions and their values live in separate tables, and the query layer can filter and project them. In practice that means a field added from the panel is a first-class citizen: it shows up in lists, filters, the column chooser, exports and the API. That is the whole difference between „an extra field” and „a field you can actually report on”.
- 1
Dictionaries instead of lists hard-coded in the app
Product types, materials, departments, complaint reasons — everything that in low-code tools ends up frozen inside a dropdown. Here, changing the offer stops being a developer ticket and becomes the job of the person who actually knows the offer.
- 2
Forms that guard meaning
Each field carries a validator and a way of being displayed. „Width in centimetres” stays a number instead of a free-text box where a year later you find „approx. 25” and „25-27”. A report is only ever worth as much as the worst entry in the column.
- 3
The same mechanism for every rollout
Client-specific tailoring is configuration, not a fork of the codebase. That sounds like a technical detail right up until the first platform upgrade — at which point it turns out to have been the most important architectural decision in the project.
And now the honest observation no platform vendor will make: the moment the word “entity” is said, a non-technical user hits a wall. Technical people know what it means; everyone else only sees that something is powerful and incomprehensible. Power and comprehensibility pull in opposite directions — the more a platform lets you configure, the easier it is to lose the person you are building it for. That is the implementer's job: translate “entity” into the client's language and set it up for them, instead of handing over a raw, powerful panel. The flip side of the same trap: being able to add a field is not the same as deciding which field to add. I have seen forms with forty fields of which eight were used, while the other thirty-two efficiently discouraged everyone from filling in anything at all.
2. Permissions, organisations and audit — what nobody asks for and everybody needs
Nobody books a meeting to look at a permission system. But when I showed a manufacturer of children's orthoses that a workshop technician sees the technical card and the measurements yet does not see the medical history or the parent's phone number, the meeting changed topic for twenty minutes. From my side it looked like this: I switched on roles and teams, did not fiddle with the configuration, and it simply worked — worth roughly a fourfold speed-up on people management compared with what the same company had before, a hand-built employee panel with no team structure. Four things sit behind that:
- Every record knows its organisation and tenant. This is not a filter bolted onto a list, it is a layer every query and every API call passes through. A company with branches gets an organisation tree, not a copy of the system per branch.
- Permissions per role and per person. One person who is an exception to the rule does not force you to invent a new role — and every company has such exceptions, usually going by a first name and surname.
- Who changed what, and when. In companies before a rollout I hear the same set of sentences every time: “why did that go out”, “I never saw that”, “who changed it”. The question lands at the worst possible moment, and a system that cannot answer it is useless in an internal dispute.
- Encryption of sensitive fields at rest. With medical data this is not an option, it is the entry ticket. It is also the only module in this five that a client sometimes asks for outright: „that one I needed yesterday”.
How this plays out with real personal data — roles, data minimisation and a tablet on the shop floor — is described in the case study of the system for an orthosis manufacturer. One detail from that rollout: it was the owner who narrowed the technicians' access, not us. You can tell a good permission model by whether it lets the business owner make that call themselves.
And now the part that changes the money conversation. Permissions and an audit trail are, from a developer's seat, the hardest and dullest part of any system — which is why in the tools our clients migrate from, advanced permissions and audit logs sit in the most expensive tier. You open the pricing page, scroll to the “Enterprise” column, and there they are. Here they are the foundation rather than an upsell — and that difference only shows up in the second year's bill.
3. Workflows and business rules — the moment the system starts working on its own
Up to this point I have been showing screens. Here I show that after a status change something happens without a human: a notification goes out, a task appears, an order reserves stock, a planner gets a new row on the board. Underneath these are domain events and subscribers that process them durably, through a queue — not „on the side” while a form is being saved.
The difference from a Make or n8n scenario is purely practical: the rule lives where the data lives. You do not pay per operation, you do not maintain glue on the outside, and you do not spend the morning working out why a scenario stalled at three in the night. That does not make Make bad — for wiring different systems together it is often the best possible choice. It only means a process inside one system is not its layer.
And the honest boundary the click-it-together crowd leaves out: pile on too many blocks and the flow becomes unreadable and hard to maintain. Simple things you click, and that is real value, because a non-technical person can see the logic and rearrange it. Complex things drop a floor down into code — but without switching tools, inside the same system and on the same data. On top of that comes something you only appreciate after a year: the platform pushes you to write tests. In a low-code tool you cannot break the tests, because there are none — you find out something broke from a user.
4. AI lives in two places here — and only one of them is a module
Here we come back to Adam's question — and here I have to separate two things that are easy to fuse into one, because both go by the name “AI in Open Mercato”. The first is not a module and appears in no menu: it is how the platform steers a developer and their assistant while the system is being built. The second is an ordinary module a user sees and clicks. I will start with the first, because that is what answers “what exactly did this platform do”.
The mechanism is simple. Point a plain AI assistant at a large project and it starts wandering everywhere, opening every file, losing the thread and doing things nobody asked for. Here it does not, because the platform ships its own directory of instructions, specifications and specialised agents. I put it the same way every time: I do not let it in there — it knows to go in, because that is how the platform was built. In practice, before any code exists the idea goes through a sieve: split into the business problem, the business rules and only then the technical specification, questions about actors, states and transitions, the cost of the problem in numbers, a glossary — and finally the checklists: security, performance, permissions, risk. That is what a developer used to have to hold in their head.
The effect of that scaffolding is measurable: with a properly written specification I would put the first version of a module at 70–90% on target, rather than “something roughly like what I meant”. And that is the real answer to Adam's question: the platform did not hand me a better model, it gave the model a place where it cannot get lost.
The other half of the same story is an ordinary module, something a user actually sees and clicks. The assistant runs inside the system, on the same data as the logged-in person and — more importantly — with their permissions. It will not answer a salesperson's question about data that salesperson cannot access, and it is not a separate chat on the side that you have to paste records into.
It can also act rather than merely summarise: create a record, assign a job, fill in a missing field, pull data out of an email and put it where it belongs. In demos I show this on something mundane — asking for a breakdown that exists in no report — because that is when it becomes obvious the assistant walks the system's structure rather than its screenshots.
And honestly: this is the module that impresses most in a demo and disappoints most often in month three. The reason never lies with the model — the assistant simply has nothing solid to walk on. If one status means two different things and half the company's knowledge lives in a spreadsheet on somebody's desktop, the AI inherits exactly that mess and hands it back in a confident tone. That is why in this list it sits fourth rather than first.
5. Customer and partner portal — the simplest thing with the biggest effect
At a wellness equipment manufacturer it looked like this: distributors phoned to ask „what stage is my order at”, and one of the two co-owners answered, from anywhere in the world and at any hour. The portal is the same system and the same data with a different view and different permissions — the customer logs in and sees their orders, documents and statuses. No synchronisation, no second source of truth.
It is also the easiest module to cost out in advance: ten calls a day times a quarter of an hour is half a job nobody ever planned for. And it shifts the company's position — a manufacturer that gives partners visibility into their jobs stops being an anonymous subcontractor and becomes a supplier with a system. With my clients that argument carried more weight in sales conversations than any saving ever did.
The same mechanism rescues rollouts in the other direction, inside the company. The most common reason people avoid a system is not missing features but too many of them: somebody does one repetitive task and gets a screen with forty fields on which they have to find one button. Our shop-floor technician gets a view with their jobs, their calendar and the two actions they use nine times out of ten. That is why I say the same thing at every workshop: bring that person along and show me what they actually do — we will build the screen around them, not around the system's own diagram.
The sixth thing, which landed mid-writing: the WMS module
This paragraph was written under odd circumstances. I was recording material about the platform, had the demo ready — and while editing it turned out that another module had landed underneath: WMS. I had been waiting on it for months, because until then the warehouse was the point in the demo where I had to say “we will build that part”. And at a manufacturer or a wholesaler the warehouse is not an add-on to the process — it is the process. The rate at which this platform adds modules is a story of its own: a demo recorded on Monday can be out of date by Friday.
- 1
The warehouse gets a map
Zones, racks, location addresses and stock counted per location rather than as one number for the whole building. Where it matters — food, cosmetics, chemicals — lots and expiry dates come with it, along with a view of what is about to run out.
- 2
Sales can see the warehouse
The order shows availability broken down per warehouse, a reservation is created on confirmation and released on cancellation. A shortfall is not reported by the customer over the phone — it is visible on the order card before anyone calls.
- 3
Receive, put away, correct
Receiving with a document and discrepancy handling, putaway to the destination location, and a simple three-step count: count, see the variance, post it. Plus stock corrections done from the panel rather than through a CSV file and an IT person.
And now the part you will not hear in a vendor presentation: this is a young module. The plan for the coming quarter targets a closed loop — „receive, put away, the stock is right” — plus a minimal but real sales integration. Deliberately outside that slice: full wave picking with route optimisation, packing with production-grade carrier integration, lot and serial traceability at compliance depth, and rich warehouse allocation rules.
What none of these things will fix
This part usually falls out of the presentation, and it holds most of the truth about what a rollout is really like. Three things you do not get bundled with a module:
- They will not replace understanding the process. In the last large rollout discovery took longer than building the first three modules: a six-hour workshop, around sixty questions and walking an order's entire path on paper — from the salesperson, through admin and production, to the person who packs, ships and issues the documents. Not because something went wrong, but because in a year of working in a low-code tool nobody in the company had ever had to name that process. That convenience comes back with interest at moving time.
- They will not pull people into the process for you. The conclusion Adam and I said out loud after one rollout was blunt: you cannot rely one hundred per cent on the business owner. A materials model built on the owner's knowledge had to be redesigned a week after shop-floor technicians got into the system and showed that the key dimension is only known at a completely different point in the process. Bring the next people into the conversation earlier than feels necessary.
- They will not remove the cost of running it. The core is MIT licensed and there is no per-seat fee, but the system has to live somewhere, somebody has to run the upgrades and know what not to touch. A subscription is precisely you paying the vendor to do that. Without at least one technical person this will not work — and the good news is that one is enough: this is not a platform that demands a team, but it is not something a business owner runs alone from an admin panel either.
- They will not forgive modifying the core. The code is yours and you can change anything in it — but overwrite a core module instead of extending it the intended way and you pay for it at the first upgrade. The irony is that you usually upgrade in order to pick up a new module (the warehouse one, say) — and that is when you find out your own change from six months ago has stopped working.
There is a fourth, less obvious one: a module you never switch on costs nothing and gives nothing. I have seen rollouts where an excellent permission model sat unused for six months, because nobody found the time to sit down and write out who should actually see what. An hour of that conversation pays back faster than any feature on this list.
What follows from this
The order in this list is not accidental — it matches the order in which these things land during a rollout. Data first, then visibility, then movement, and only at the end the parts that photograph well: the assistant and the portal. The warehouse comes in where a company genuinely has a warehouse, and not a moment sooner. The reverse order is possible too — it ends in a system that impresses in a demo and goes unused by March. And if I have to sum up these five things in one sentence, it is this: this is not “less code”, it is fewer decisions made from scratch. In a system carrying patient data or customers' money, fewer decisions from scratch means fewer places where something can go wrong.
If you do not know the platform yet, start with the introduction to Open Mercato, or simply open the public demo and click around — with one caveat: at first glance it will feel overwhelming, so look at the details inside rather than the number of modules. If you are sitting in an internal tool today and wondering whether you have hit the ceiling, there is a separate comparison with Retool. And if you would rather see this at one specific company, I described a rollout at a sewing workshop whose starting point was six months of low-code.
Mateusz Kozłowski
Founder of flowbiz · Process automation expert
I implement automations, integrations and AI in mid-sized companies across Pomerania and Kuyavia-Pomerania.
