In my last post about release processes, I made a claim that felt like a conclusion: a low-code platform that cannot safely change is not enterprise software.
This week I realized that claim was missing half the picture.
A platform that cannot safely change will lose enterprise customers eventually. But a platform that cannot safely connect will lose them immediately.
Here is the pattern I have now seen enough times to call it a law: every low-code platform eventually becomes an integration platform. No exceptions. The only question is whether you admit it early or discover it in a panic.
The conversation that repeats with every customer
Month one with a new enterprise customer is wonderful. We build their data model, their forms, their approval workflows. Everything lives inside the platform. It is clean, fast, and entirely ours.
Month two always starts with the same sentence:
"This is great. Now can it talk to our existing system?"
Their existing ERP. Their HR system. Their email server. Their legacy order database from 2011 that nobody wants to touch but everybody depends on.
The first time, I thought this was one customer's unusual situation. The third time, I saw the shape of it. The fifth time, I stopped being surprised and started rebuilding the platform around it.
Inside a low-code platform, everything is connected by design. A field on a form is bound to a column in a table. A workflow step reads a field. A dashboard aggregates a table. The connections are internal, typed, and always available.
The moment a customer's data lives partly in your platform and partly somewhere else, all of that elegance meets the outside world. And the outside world does not have your field IDs, your permission model, or your transaction guarantees.
The trap: point-to-point integrations
The natural first response is to build each requested connection by hand.
Customer needs order data in their ERP? Write a script that pushes orders to the ERP. Customer wants employee data from HR? Write another script that pulls from HR. Customer wants a notification in their messaging tool? One more script.
This works. For a while.
Then you count. Five external systems, each needing data from two or three others. That is not five integrations. That is a graph, and the edges multiply. Someone changes a field name in the HR system and three of your scripts break silently, and the only person who notices is the HR manager whose monthly report now has empty columns.
The problem is not the number of scripts. It is that each script is a private agreement between two systems, with no shared vocabulary, no shared error handling, and no shared place to look when something goes wrong.
What integration actually breaks down into
Once I stopped counting integrations and started studying them, four distinct jobs appeared.
Inbound: getting data in. An external system creates or updates records in the platform. This needs a real API surface — not an internal endpoint repurposed, but a public one with the platform's own permission system attached. If the API does not respect the same rules as the UI, you now have two security models and one of them is wrong.
Outbound: getting data out. The platform pushes changes to external systems. This is where two engineering problems hide that nobody warns you about.
The first is retries. External systems fail. Networks fail. Your push happens at the exact moment their system restarts. Without automatic retry with backoff, that record is simply gone, and nobody knows.
The second is idempotency. The retry succeeds — but the first attempt had actually landed. Now the customer has two orders in their ERP for one order in your platform. An integration layer without idempotency keys is a machine for manufacturing duplicates at scale.
Events: letting the outside world subscribe. This is the one I resisted longest.
For a long time I thought events were an advanced feature. Then I watched a customer build a "sync job" that polled our API every five minutes, compared timestamps, and pulled anything new. It worked. It was also fragile, slow, and completely blind to deletions.
The platform already knows when a record is created, updated, or deleted. It already knows when a workflow step completes. It knows these things at the moment they happen. Emitting an event — record created, workflow finished, status changed — costs almost nothing, and it turns every polling script into a subscription.
Secrets: where the credentials live. An integration needs an API key, a token, a password. Where does it go?
Not in a script. Not in a form field. Not in a configuration value visible to anyone with designer access.
I learned this one embarrassingly late. Credentials belong in a dedicated, encrypted, access-controlled store that the integration layer reads but no script or page can dump. The first time a customer's auditor asks "who can see the ERP credentials," the answer must be a role, not "whoever can open the settings page."
The quiet problem: knowing when it broke
The hardest part of integration is not sending data. It is knowing that sending data failed.
An internal workflow fails, and the approver sees it. A form breaks, and users complain immediately. The feedback loop is built in.
An outbound sync fails at 2 a.m. on a Saturday, and everything looks fine in the platform. The dashboard shows clean numbers. The workflows run green. Meanwhile, three days of orders never reached the ERP, and the finance team finds out during month-end reconciliation.
So the integration layer needs its own observability. Every connection needs a visible run history, an error state that surfaces in the platform instead of in someone's inbox a week later, and a dead-letter state for events that could not be delivered — with a replay button. Not logs buried in a server. A screen that an operations person can check in ten seconds.
The uncomfortable conclusion
I used to describe our platform as a place to build business systems. Tables, forms, workflows, dashboards. A self-contained world.
That description was accurate and useless, because no enterprise lives in a self-contained world.
The real promise of a low-code platform is not that it replaces the customer's existing systems. It usually cannot, and the customer does not actually want it to. The promise is that it becomes the fastest place to build the connective tissue between the systems they already have — with permissions, audit, and rollback included.
Which means the integration layer is not a feature on the roadmap.
It is the reason the platform gets adopted, and the reason it gets trusted. The platforms that treat it as a checklist item spend their second year doing archaeology on broken scripts. The ones that treat it as core architecture spend their second year onboarding customers who already have five systems and no patience for another island.
I know which second year I want.
