In this article
I walk into a company and the first thing I see is spreadsheets. Not one. Several. And a moment later the interesting part shows up: very often it is the same file in several versions.
Why several versions? Because we want one person to see this column, another to see those two, and nobody from outside to see our calculations. So we make a copy. And a second one. And a third. That is not sloppiness — it is the only way a spreadsheet can handle what a real system calls permissions.
Then I ask who enters the data. It turns out several people do. And I rarely see a spreadsheet that is resistant to human error: with locks, with sensible formulas, with guards against a slip. On top of that, as the number of rows grows, performance problems start.
This post is about the moment that sentence stops being a metaphor and turns into a decision: does your process deserve its own system — and, just as importantly, when it does not.
In short
- 1
The symptom is always the same
Several copies of one spreadsheet, several people entering data, zero resistance to a slip. The copies do not come from chaos — they come from missing permissions.
- 2
Two sentences are enough to start
Centralise the data and settle who has access to what. You do not need to know anything more about technology to get moving.
- 3
You are not buying a finished system
You are buying a tool that speeds up building a system shaped around your company. What comes with it is ownership of the code and independence from a vendor.
- 4
Half of an honest answer is “who should not do this”
Nobody technical in the company, maintenance and infrastructure on your side, a project still before version one. Three reasons not to do it.
The episode this post came from
I recorded the opening episode of my Open Mercato series about exactly this. If you would rather listen: in a bit over ten minutes I answer one question — can your process be moved out of Excel quickly and cheaply, or not. The text below is the same material, written out for reading.
The episode is on my channel Mateusz Kozłowski — the rest of the series lands there too. It is recorded in Polish.
What I tell the owner, standing over that spreadsheet
I do not talk to him about frameworks. I say two sentences: this data has to be centralised and you have to settle who has access to what. That is enough to start — everything else in the conversation is implementation detail.
Those two sentences dismantle the whole gallery of copies. If the data sits in one place and each person's view is limited by their role, there is no reason to keep a second file for sales and a third for production. The copies were never the problem — they were the symptom.
The reframe: you are not buying a system, you are buying a tool to build one
This is the most important thing in the whole episode and the most commonly misread. People think they are buying a finished system. They think they are buying a platform. What they are actually buying is a tool that speeds up building a system tailored to their company.
It sounds like a nuance until you ask what happens when you need a change the vendor did not anticipate. In an off-the-shelf system that is the end of the conversation, or a custom job for serious money. Here it is simply your code, in your repository.
What this is not — and where losing access is an advantage
Let me say what people confuse it with, because that is half the answer. This is not Make. This is not n8n. This is not Zapier. It is not that class of tool — those wire together systems you already have, and this is about the place where the process lives in the first place.
It is not a no-code platform either, the kind where you have access neither to the code nor to the infrastructure underneath.
If you are sitting in an internal tool like Retool today and wondering where its ceiling is, I have a separate comparison for that.
Where this came from: two dead ends
For years I built on low-code and no-code. They gave you ready-made pieces and you could move fast. They were just expensive. And always not quite on target — because they were still platforms, and you still had to accept the limits they imposed. I wrote that out at length once in the post on low-code versus CRM and ERP.
The other side was ERP and CRM systems which — honestly — often look like they are from the nineties. Where adding one field, the specific field you happen to need, means paying for a custom build. For serious money. And something still does not quite fit.
I once had a project with Symfonia where a dozen-odd API versions were in play. In one place we had to use one version, in another a different one. A nightmare. Simply a nightmare.
So when I saw Open Mercato, I thought one thing: finally. Finally we are at this point.
What you get ready-made — and the one word that ties it together
Every business process needs more or less the same things. It needs roles. It needs permissions. It needs data scoped to a role — because there is a specific human standing in that process, and they may do some things and not others.
And here is what a developer appreciates and an owner rarely sees: in terms of craft, these are the hardest things in the entire job. Permissions. Roles. The mechanics of logging. Recording every action. Change history. All of it is already written.
On top of that, modules that most likely fit your company:
- orders,
- quoting,
- the sales pipeline,
- business partners,
- users and roles,
- a customer portal.
If you want to see these things up close, I took them apart one by one in a separate post on the five things that settle a demo. The platform itself is described from scratch in the introduction to Open Mercato.
Three objections I hear
All three are reasonable and all three come up regularly. Here they are in order.
1. If AI can build software, why do I need a framework at all
The mechanics I described above are already written and behave the same way in every module you add. Without that, the agent invents them from scratch. Differently every time.
I heard exactly this from a friend in the industry, a technical person: “Claude goes into that code anyway, so what is the wow here?”. The answer is the same — it is not about who writes the code, it is about how many decisions have to be made from zero along the way.
2. It is just another boilerplate
You copy a boilerplate into your project and after the first update it drifts away from the original. Here the core stays the core and you add alongside it. That is the difference between a template and a foundation.
3. Who takes responsibility when it breaks
This is the most honest of the three and — tellingly — it is the client who asks it, not the developer. The answer starts in the section below: part of that responsibility stays on your side, and it is better to know that before you start than after.
Who I tell not to do this
An honest answer has two halves. The first one is everything above. This is the second.
One more word on the last point: to me “before version one” means it is early, not that it is risky. But that is my judgement, not a fact — and I would rather you made the decision knowing it is a judgement.
Tuesday before and Tuesday after
What does the Tuesday before look like? Chaos. Not knowing. No control over what is going on. Firefighting, nerves, and hunting through different places for who did this, when, and why I did not see it.
And after? You simply know. Who, what, when and on whose instruction. That is the whole sentence — there is nothing more to it, and that is the best part.
Four industries, one shape
I only saw this after the fourth rollout. A technical data sheet at a packaging manufacturer. A visit at a clinic. An order in make-to-order production. That looks like three different worlds.
Underneath it is the same shape: one record that passes through several people's hands, changes status and leaves a document at the end. Four industries. One foundation.
I have written up two of those rollouts separately: a sewing workshop making bags and a manufacturer of children's orthoses. From the outside they have nothing in common. Inside they share the same skeleton.
How to check this yourself, without talking to me
If you want to see it with your own eyes, go to demo.openmercato.com. Click through it, log in, walk around.
And one piece of advice: do not look at how many big modules are in there. That is overwhelming and it is meant to be. Look at the details. Open the change history. Check who has the right to edit and who has the right to create. Because those are the things Excel does not have — and the things you will not write for yourself in a week.
The full episode is on YouTube, the rest of the series lands on my channel, and I write more about the platform itself on the Open Mercato page.
Mateusz Kozłowski
Founder of flowbiz · Process automation expert
I implement automations, integrations and AI in mid-sized companies across Pomerania and Kuyavia-Pomerania.
