A friend who runs a construction company asked me a few weeks ago whether we couldn't "finally make the communication and the organisation simpler". Not a client, not a proposal — a conversation between friends. But it is the most honest version of a question I hear constantly in this job, and the answer has occupied me more than most paid analyses.
Because my first instinct was the wrong one.
I have spent years building automations with n8n, Make and Zapier. When somebody describes a process problem, I automatically break it into trigger, steps and result. With him that worked for about two minutes — and then it fell apart. Not because the tools are weak. Because he described a problem for which a workflow is the wrong shape.
This article is about that boundary: where automation stops, why it stops exactly there, and what comes after — without turning into a six-figure software project.
The conversation that prompted this article
His company: mid-sized, several sites running in parallel, a core group of subcontractors plus crews that rotate. What he described sounded like this:
- Tenders and bills of quantities go out as PDFs by email
- Responses come back by email, by WhatsApp, by phone, occasionally as a voice message
- Who does which trade in which time slot lives in a spreadsheet on an office computer
- Progress photos live on the site manager's phone
- Some of the crews speak no German. Translation happens verbally, by whoever can manage it
- And several times a day somebody calls to ask where things stand
His sentence was: "I just want everyone to know what's going on."
That sounds like a communication problem. It is a state problem.
Nobody in that company knows what is going on, because there is no place where "what's going on" is written down. There are six half-truths in six channels, and the reconciliation happens inside the heads of two or three people who therefore never finish work.
What automation is genuinely excellent at
Before the limits, the fair side. Workflow automation is unbeatable inside a clearly defined range — and cheaper than anything else.
Typical cases we build exactly that way:
- An invoice arrives by email, gets read, validated and posted to accounting
- A form is submitted, the lead lands in the CRM, sales gets a notification
- Every Monday at seven the weekly report sits in the management inbox
- An order is confirmed and three systems are brought in line
These are not small effects. In the documented examples on this site such runs carry hours per day. Anyone still doing these by hand should not be thinking about custom software — they should build a workflow, because the maths works faster and the risk is small.
But it pays to be precise about what a workflow actually is:
A workflow is a pipe. Not a place.
Model Schematic illustration — not measured customer data.
A pipe carries something from A to B and is then done. It holds nothing. It shows nothing. It never asks a follow-up question. As long as the problem is "something has to get from A to B", it is perfect. The moment the problem is "we don't know where we stand", it is the wrong shape — and every attempt to make it fit anyway produces exactly the wobbly construction nobody wants to touch a year later.
Four limits where every workflow tips over
These four points are not tool weaknesses. They apply to n8n exactly as they apply to Make or Zapier, and they apply to the hand-written Python cron job too. They are properties of the shape.
1. A workflow has no interface
The subcontractor is supposed to see the work package, confirm it, document progress later, attach a photo, raise a question. That requires a screen with something on it — with states, history and permissions.
A workflow has no screen. It has triggers. The usual workaround is a form tool in front and a chat channel behind, and now the process is spread across three tools, none of which knows the complete state.
2. A workflow has no memory
"Who bid on which lot, at what price, when was it awarded, what has been signed off?" — those are questions to a body of data, not to a pipe.
In practice that memory gets pushed somewhere: Google Sheets, Airtable, Notion. What emerges is a shadow database: no permissions, no required fields, no history, no owner — and within a few months it is the single most important file in the company.
3. A workflow knows nothing about roles
The subcontractor may see their own lot. Not the competitors' prices. Not the costing. The site manager may report progress but not award contracts. Accounting sees amounts but not site photos with people in them.
Permissions are not a feature you bolt onto a flow. They have to sit on the data to hold. A workflow that dutifully sends only the right rows is safe exactly until somebody adds a branch — and nobody notices.
4. Edge cases grow faster than the flow
This is the point that makes workflows "wobbly" in scenarios like this one, to use my friend's word.
Version one is elegant: mail in, parse the PDF, message out. Then reality arrives. What if the subcontractor only partially accepts? Quotes an alternative price? Replies by voice message? What if a date moves and three other trades depend on it? What if somebody drops out at short notice?
Every one of those becomes a branch. Six months later the flow has thirty branches, no human knows all of them, and a change to branch seven breaks branch twenty-two. In application development this is a known problem with a known answer: you model states, you do not branch them.
Model Schematic illustration — not measured customer data.
The test: pipe or place?
Before you start the next automation project, five questions. Every "yes" argues for a place rather than a pipe.
Model Schematic illustration — not measured customer data.
If you are unsure where your case sits, the bottleneck assessment asks exactly this kind of question and takes about five minutes.
What the construction example looks like as a "place"
Now the concrete part. This is how I would build my friend's case — played through, not delivered:
Model Schematic illustration — not measured customer data.
1. Create the tender. Project, lots, line items, dates, attachments. One record with states: draft → published → under review → awarded. Not a PDF sent into the void, but an object that knows its own status.
2. Subcontractors get access to their lot. Not to the tender, not to anyone else's prices. Access hangs off the assignment, not off the discipline of whoever sends the email.
3. Language. The interface appears in the crew's language — menus, fields, status names, help text. Not as a translation layer bolted on afterwards, but because every module carries its text as keys and those keys get translated in one batch. Translating the content (specifications, comments, questions) is the next step and is not in there today — more on that below.
4. A work package instead of a message. The award produces an order with line items, dates, contact and documents. The subcontractor sees it on their phone without a single phone call.
5. Documentation on site. Report progress, attach a photo, tick off a checklist, record hours, raise a question. All on the same record, with a timestamp and an author. Which also gives the later sign-off a basis that does not have to be reconstructed from memory.
6. Flow back. The site manager sees every lot on one screen. Who has reported, where it is stuck, what is signed off, what is open.
And this is where automation comes back in: reminders for outstanding responses, handover to accounting, connections to the costing software, weather or delivery data. Those are pipes — and pipes need ends to connect to.
Why this does not have to become a software project
This is where most mid-sized companies get off, and rightly so. Because the three usual routes are all bad:
| Route | What goes wrong |
|---|---|
| Standard ERP | The company adapts to the software, not the other way round. Rollout runs for months; consulting days are the real price. |
| Custom development | Six figures, nine months, and afterwards maintenance depends on one person or agency. |
| DIY stack | Sheets plus chat plus forms plus automations. Cheap in month one, unmaintainable in month twelve. |
The fourth route, which I have been working on for a while, looks different: ready-made business modules you rent, assemble, and run on your own server.
That is usable.software. Not an AI-generated app builder, but hand-built modules — projects, tasks, documents, contacts, suppliers, checklists, time tracking, chat and more — coupled through shared data objects. You pick what you need and get a system that feels like a tool rather than a folder of forms.
The three points that matter to me:
- Data on your own server. The same logic as self-hosted n8n. If you keep control of where it runs, you do not have to argue about data leaving — and with site photos that have people in them, that is not an academic concern.
- A monthly fee instead of a project budget. No rollout project, no consulting days, cancellable monthly, data exportable.
- No sales talk. Try it, configure it, see what it costs. If you want to talk, you talk to the developer, not to a sales team.
12
modules across two industries: the currently public state of usable.software
Source usable.software, retrieved July 2026
What Usable is today — and what it is not
The honest part, without which the rest would be an advert.
Usable is not live yet. The site says so itself. There is a configurator, there are modules, there is a roadmap — what there is not is self-service signup. We are looking for pilot companies right now, not customers in the classical sense.
Construction is not one of the finished industries. Two are public: logistics and retail. The scenario above would be assembled from shared modules that exist — not from a finished construction package that does not. Anyone looking today for a certified construction ERP with standardised tender import and formal measurement is better served by a specialist vendor, and I would rather say that now than after the first invoice.
Translation is staged. The interface is translated through a key pipeline into many languages; the rollout across all modules is still running. Automatic translation of the content people type in is the planned next step, not today's state.
It does not replace n8n. And that is not a shortcoming.
What I told my friend
Not "we'll automate that". Instead: "You don't have an automation problem. You have no place."
The difference is not academic. Had I built him a flow, it would have worked for three months, then suffocated on edge cases, and he would have learned what a lot of mid-sized companies learn at exactly this point: that digitisation is expensive and delivers little. When in fact only the shape was wrong.
If you are standing in the same spot — several channels, one irreplaceable spreadsheet, somebody asking daily where things stand — those are not loose ends to be automated away. That is a system that does not exist yet.
Next steps, depending on where you are:
- You have clear runs between systems: n8n vs. Make compared and the five-step method
- You run a trades or construction business and want to tidy up first: Automation for trades businesses
- You do not know which of the two problems you have: bottleneck assessment in five minutes
- You recognise yourself in the construction example and want to be a pilot: usable.software
Frequently asked questions
How do I recognise that a workflow is reaching its limit?
By three symptoms: the number of edge-case branches grows faster than the benefit, there is a spreadsheet alongside that holds the actual state, and people still phone to ask where things stand. As soon as two of those apply, what is missing is an application, not another automation step.
Can't n8n build interfaces too?
There are forms and simple input masks, and for an approval click that is enough. What is missing is everything that makes an application: filtered lists, detail views, history, roles and permissions at the data level, offline use on a phone. Rebuilding those costs more than renting them.
Isn't this just an ERP under a different name?
The difference is in rollout and lock-in. A classical ERP arrives with an implementation project, consulting days and an annual contract. The approach here is: pick modules, run them on your own server, pay monthly, cancel monthly, export your data whenever you want.
What happens to my existing automations?
They stay. They actually get better connection points, because they read clean data objects instead of a spreadsheet whose column order can change at any moment.
Where does the data live?
On a server you choose. Same reasoning as self-hosted n8n, and with personal data in site photos it is the decisive point.