A year and a half ago, a manufacturing customer sent us a screenshot instead of a bug report.
It was a phone. The screen showed one of our detail forms, rendered exactly as it renders on a 27-inch monitor, shrunk until the labels were unreadable. On top of it, someone had used a thumb to cross out half the fields. Below the screenshot, one sentence: our warehouse people use this all day, and they hate it.
They did not ask for a mobile app. They assumed they already had one.
That screenshot is still the most useful product feedback we have ever received, and it was never really about a phone.
Every demo is a laptop
Nobody ships a low-code platform demo on a phone. That is not laziness; it is that the phone is a terrible stage. A form designer, a workflow canvas, a permission tree, a dashboard — these are instruments that need a wide surface, and they are exactly what you show when you are explaining what the product is.
So the mental model of the platform, from the earliest architecture conversation, is built around a person sitting down. A person with a keyboard, a mouse, ideally two monitors, and thirty uninterrupted minutes to configure a screen.
Then the application gets deployed, and the person who actually uses it is standing in an aisle with a box in one hand.
The gap between those two people is not a breakpoint. It is a different product.
Mobile is not a rendering target. It is a second view of the same metadata.
The mistake we made — and the mistake I see in almost every platform — is treating mobile as a layout problem. Something CSS can fix. Add a media query, stack the columns, collapse the sidebar, ship it.
That fails because a desktop screen and a phone screen are not the same information architecture at two scales. They are two different answers to the question: which of these forty fields does this person, in this moment, actually need?
Look at a real detail view in an enterprise app. Identity fields, classification fields, financial fields, attachments, status, owner, related records, history. On a desktop, showing all of it is a courtesy. On a phone, showing all of it is an act of hostility. The person on the shop floor needs three of those. The person in finance needs a different three.
Which means the platform has to answer something it has never had to answer: who is looking, and where are they standing? That is not styling. That is metadata — a per-view, per-role, per-context statement of what matters.
And once you accept that, the honest conclusion arrives quickly: the desktop layout you shipped for years was never designed either. It just had enough room to hide the fact that you never decided.
The table is where everything collides
Forms are the easy part. The data table is where low-code platforms actually live — a grid of rows and columns is the most-used screen in every enterprise system ever built, and it is the one thing a phone genuinely cannot do.
Forty columns. Frozen headers. Inline editing. Cross-page batch selection. Column-level permissions. Every one of those is a promise made to someone on a laptop.
There are three ways out, and I have watched all three get chosen.
You can reduce. Pick the five columns that matter for the mobile context, name that as a mobile view, and let the rest be reachable through the detail screen. This works, and it forces an admission: most grids are used as three columns and a search box.
You can rotate. Tell the user to hold the phone sideways. That is a real answer for a real minority of cases and a terrible default, and it is a tell that you have not decided anything.
Or you can pan. Let the grid scroll sideways and watch people lose track of which row they are on within the first three columns. I have never met a user who liked it.
We ended on the first option, and it cost us something real: someone has to decide, per application, which five columns. That decision cannot be automated away, because it encodes business judgment about a job we do not do.
The permission question hiding inside the layout question
This is the part that took me too long to see.
When you strip a mobile screen down to three fields, you are not only choosing what to show. You are deciding what the platform believes the client needs to hold.
If the reduction happens in the browser — the field is fetched and then hidden with CSS — you have reduced nothing. You have shipped every confidential column in the salary table to a phone that someone left in a taxi. Responsive design has quietly become a data exfiltration path, and no security review catches it, because from the API's point of view nothing changed at all.
The only safe version of this is the version where the mobile context is declared at the metadata layer, resolved on the server, and reflected in the query the platform actually runs. Which means mobile support cannot be a front-end project. It has to reach the same layer permissions reach.
We learned that one the expensive way. I would rather you learned it from this paragraph.
Most of your mobile users will never open your app
The other thing we underestimated: enterprise mobile use does not look like consumer mobile use.
Very few of our customers' field users browse to an application. They open WeCom, DingTalk, or Feishu, they see a message, they tap it. The notification is the interface. The form and the grid are what happens after the tap, and they have to survive being embedded inside someone else's webview, with someone else's navigation bar, someone else's font scaling, and someone else's back button.
That reframes the whole story. Mobile is not primarily about screens. It is about whether your platform can create a task that arrives as a message, opens in one tap, gets completed in ninety seconds by someone wearing gloves, and pushes its result back into a workflow that has been waiting since six in the morning.
Which is a workflow question wearing a mobile costume.
What we changed
Not much of it was glamorous. We stopped pretending the phone was a smaller laptop: the mobile context became a first-class piece of view metadata that a builder defines on purpose and the server resolves before it runs anything. The reduction moved server-side, and we deleted the responsive hacks that had been quietly leaking columns to clients that never needed them.
We made every form and grid openable through a tokenized link, so it can live inside a chat message instead of behind a navigation tree. We measured cold start on real hardware, because a phone on factory Wi-Fi is not a laptop on fiber, and a two-second desktop load is a ten-second one in the aisle.
And we stopped letting the builder decide alone. The mobile view gets previewed on an actual phone, inside the actual app the customer already uses. Not a device emulator in a desktop browser. That distinction has caught more mistakes than any review meeting we have ever held.
The uncomfortable conclusion
Here is what I actually believe after eighteen months of this.
Low-code platforms sell speed, and speed is measured in how fast you can build a screen. But the screen was never the thing that mattered. What mattered was that the screen got used — by a specific person, in a specific place, with whatever was already in their hands.
We spent years compressing the distance between an idea and a working application, and almost no time on the distance between a working application and a person who is not sitting down.
The desktop was never the default. It was just the only context we had bothered to model — and for most of our customers' users, it is not where the work happens. It is where the work gets reviewed.
The person holding the box is who your platform is actually for. If your metadata has no way to describe them, you did not build an enterprise platform.
You built a very good demo.
Top comments (0)