Lookup-field improvement on a low-code platform broke a warehouse app untouched for eight months

The post states the constraint in five words: "the application model is data." ^[6] A customer's app on the platform is tables, fields, validation rules, workflow steps and permission trees, stored as rows that users wrote and other rows reference ^[9]. Every release is deployed to every one of those apps, including, in the post's example, one a contractor assembled in 2022 and abandoned ^[9]. So every change to the model is a data migration on someone else's production data, typically with no rollback path ^[7].

That changes what a rename costs. In a codebase, the compiler finds every reference that broke. On the platform, the references sit in customer rows. "Rename a field on someone else's application: nothing tells you anything, and the workflow that referenced it fails silently at 2 a.m. on a Saturday," the author wrote ^[8].

The warehouse case was harder to catch than a rename. Of the three changes in the release, the permission check moved earlier in the write path looks like the risky one on paper ^[1]. The break came from the lookup field, whose new behavior was better in every case the team had tested ^[4]. The customer's app had been written against the old behavior, "deliberately or not," and had run correctly for eight months ^[5]. A green suite is a claim about the vendor's own cases. For it to cover this one, the suite would have to contain the customer's usage, and on this platform that usage exists only as the customer's metadata ^[9]. The post puts it as a blast radius measured in somebody's business process, with no test suite for it ^[14].

The post compares rollout strategies by who absorbs the cost. Shipping everything at once is fast for the platform and brutal for customers, and a bad fix cannot be un-shipped ^[10]. "The velocity you gain is borrowed against trust you will need later," the author wrote ^[10]. A flag day lets each customer choose when to take new behavior. The platform then supports the old path for as long as the slowest customer delays ^[11]. The post adds that "the customers who delay longest are, almost by definition, the ones whose applications are the most fragile and least understood." ^[11]

I think the author lands on the right tradeoff for a platform whose customers run operations on it. "That was the week I stopped thinking about upgrades as a release-engineering problem, and started thinking about them as the hardest product decision a low-code platform makes," the author wrote ^[13]. The post now calls backward compatibility "the primary surface of the product" ^[12]. In my view, the incident supports treating a changed default on an existing field type as a breaking change, even when the new behavior tests better.

The evidence is one incident, told by the vendor two weeks after the release ^[15]. The post does not name the platform or say how many applications took the release. It establishes that a tested, accurately documented release can break a stable app, with no measure of how often that happens.