Low-code has become a familiar phrase.
Drag-and-drop forms. Generated pages. Approval flows. Dashboards. Internal tools. We have all seen the demos, and many of them are genuinely useful.
But after spending years around enterprise digitization projects, I became less interested in how quickly a page can be assembled, and more interested in a harder question:
Can the system still be understood, maintained, governed, and extended after the business changes?
That is the question behind INFORMAT, the international version of the enterprise low-code platform I have been building.
This post is the first entry in a development log. It is not a polished product announcement. It is a record of why I think enterprise low-code needs to be rebuilt as a durable digital foundation, especially now that AI is becoming part of how software is designed, configured, and operated.
The problem was not "no software"
When I first worked with enterprise digital transformation, the problem I saw most often was not that companies had no tools.
Usually, they had too many.
Customer information lived in spreadsheets. Approvals happened in chat groups. Contracts were stored in cloud drives. Tasks lived in project management tools. Finance had a separate system. Each tool made sense on its own, but once the real business process crossed those boundaries, things began to break.
Data did not match.
Nobody knew where a process was stuck.
Permissions were unclear.
Renaming one field could affect pages, reports, import templates, APIs, and approval conditions.
Business users felt the system was hard to use. Developers felt requirements never stopped changing. Managers no longer trusted the data. Eventually, people quietly moved back to manual spreadsheets and offline communication.
That pattern shaped my view of enterprise software:
A company does not just need another app. It needs the ability to continuously model, run, and govern its business.
Low-code is the entry point, not the destination
Low-code is valuable because it shortens the path from business idea to working system.
If the goal is a customer registration form, a leave request flow, or a task list, low-code can help build it quickly.
But enterprise work rarely stops at one form.
A customer record leads to contacts, follow-ups, contracts, orders, payments, support tickets, and renewal risk.
A leave request connects to organization structure, attendance rules, payroll, and permission boundaries.
A project task connects to members, workload, cost, timeline, risk, and reporting.
If a platform only answers "how do we generate this page?", then relationships, workflow, permissions, analytics, and integrations will eventually become isolated again.
This is why I do not want to define INFORMAT as only a low-code tool.
I think of it as an enterprise digital foundation.
Low-code is the entry point because it helps teams create business systems faster. The foundation is the real goal because companies need those systems to keep running, keep changing, and stay internally consistent over time.
A platform is different from an application
When you build a fixed business application, many decisions can be hard-coded.
In a CRM, you can define the objects, fields, flows, roles, and reports ahead of time.
A low-code platform is different.
Users create their own applications. They define tables, add fields, configure views, design workflows, set permissions, and connect automations. Today the app may be customer management. Tomorrow it may be procurement approval, equipment inspection, or project delivery.
That means the platform cannot only know how to render the current page.
It has to understand:
- what the business object represents
- what each field means
- how objects relate to each other
- who can see or change which data
- how a workflow moves under different conditions
- which tools automation and AI are allowed to call
In other words, the platform must store business data and also the metadata that describes the business.
This idea drives many design decisions in INFORMAT:
- A form is not just a page.
- A field is not just an input control.
- Permission is not just a menu setting.
- A workflow is not just a diagram.
- AI is not just a chatbot attached to the side of the product.
Why AI makes this worth rebuilding
AI coding tools are already very good at producing screens, APIs, scripts, and small features.
But an enterprise system is not just a collection of generated code snippets.
Enterprise systems need to answer precise operational questions:
- What is the relationship between a customer and a contract?
- Who is allowed to view this record?
- Which fields can be edited during approval?
- How do we trace a failed automation?
- Can AI-generated changes be audited?
If that knowledge is scattered across code, prompts, documents, and people's memory, the system becomes harder to govern as it grows.
Low-code platforms have an important advantage here: they can make business objects, fields, relationships, permissions, workflows, and operation logs explicit.
Once those structures are explicit, AI can work inside a real business context instead of guessing from thin air.
To me, AI plus low-code should not mean placing a chat box next to a traditional builder. It should mean allowing AI to understand the platform's models, rules, and tools, then participate in modeling, configuration, analysis, and execution within authorized boundaries.
That is the direction I want INFORMAT to move toward.
What matters in the first stage
From an engineering perspective, the first stage is not about piling up as many features as possible.
It is about getting the foundation right.
There are five things I care about most:
- Business objects must be clear. Applications, tables, fields, views, and actions need a coherent model.
- Fields must carry semantics. Text, numbers, dates, users, departments, related records, attachments, and statuses should support querying, analytics, permissions, workflows, and AI understanding.
- Permissions must be modeled early. Retrofitting permissions after data, workflows, and reports are already running is painful and risky.
- Workflows and automation should happen around data. A workflow is not an isolated approval chart; it changes the state of a business object.
- The system must be traceable. Who changed what, where a workflow is, whether an automation succeeded, and which tools AI used should all leave records.
These capabilities are less visually impressive than a drag-and-drop page builder.
But they decide whether the platform can support real enterprise operations.
Why I am writing this log
Writing development logs is also a way to force myself to review the design.
Platform products easily become complex. If the motivation behind a design is not written down, even the builder can forget why certain trade-offs were made.
So this series will try to stay close to the engineering process:
- what the feature is
- why it exists
- where the boundary is
- what turned out harder than expected
- what still needs to be improved
In the next posts, I plan to write about:
- why the form engine is not just a page generator
- how the data model of a low-code platform should be designed
- why permissions are more complicated than they look
- how workflow, automation, reporting, integration, and AI connect to the same foundation
INFORMAT is not trying to be another tool that only makes page creation faster.
It is my attempt to build a system foundation where enterprise business can be continuously modeled, continuously operated, and continuously evolved.
You can learn more about the overseas version here: https://www.ainformat.com/
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.