AI-Built Applications. Enterprise-Ready from Day One.
We engineered an AI application builder on top of an established enterprise-grade platform. Users describe what they need, and AI builds working application screens connected to real business data. Authentication, security, navigation and core application services are already in place—not reinvented for every new application. The result is AI-generated software that starts with an enterprise foundation, rather than having to acquire one later.
The situation
Our first version was exactly the demo: a chat on one side, a live preview on the other, and a model writing React code in between. It looked impressive. It also fell apart as soon as two people used it at once.
The platform it ran on was already an enterprise-grade one, with authentication, permissions, security, navigation and data access in place. Asking AI to recreate those for every application made no sense. The opportunity was a builder that generated the application-specific functionality on top of them.
The goal was an app builder that business users could rely on. Screens had to read and write real business data and look like part of the same platform. Many organizations share it, so one user’s AI could never touch another’s work, and nobody should be able to talk the AI into doing something dangerous. Users needed to see an app take shape within seconds, and a session that runs for hours had to stay affordable.
What made it hard
The first version shared everything.
Two users on the same model shared one agent, so the second could see, and overwrite, the first’s half-built app. Conversation memory leaked between users and disappeared on restart. Refreshing the page created a new project and left the old preview server running. The preview server also installed packages from a file the user could influence, which was a real security hole.
We were also maintaining hundreds of lines of agent-loop code that did what mature coding agents already did better. We had to decide whether to patch the prototype or rebuild around something stronger.
Almost right isn’t good enough for an app.
Generated code is often almost right: a reference to a file that doesn’t exist, a misspelled field, a report that was never defined. In a demo that is a blank screen. For someone relying on the app it is a failure they can’t diagnose. Those mistakes had to be caught, or better, made impossible, before a user saw them.
The preview had to feel instant, from anywhere.
A live preview is what makes the product feel real, and we went through several. In-browser bundling couldn’t run a real application with real data connections and authentication. A preview server per app, launched directly on the machine, worked but had no isolation, and installing packages took 30 to 90 seconds. Each preview server used 150 to 700 MB of memory, and long sessions ran out without a limit. Refreshing after every file the AI wrote showed a broken page halfway through.
Distance made it worse. For users on the other side of the world from our servers, a refresh took about 15 seconds, because a full reload fetched 143 files in a chain where each level of imports waited for the one before it.
Copying a design and connecting it to data are different jobs.
When users attached a screenshot or a design, asking the AI to copy it and connect it to data in one go made it compromise the design to fit the data. Splitting the work gave each step the model’s full attention: first a faithful static copy, then data binding once the user confirms.
Turns cost more than tokens.
Every chat turn costs tokens, and an app-building session can run for hours. After a model upgrade, the library we use stopped requesting prompt caching for the new model, so every turn was billed at full price. One long production session was paying roughly ten times what it should have per turn.
Once caching worked again, the cached part was cheap. What cost money was the number of turns, and the growing conversation history re-sent on each one.
What was built
We built the AI application builder on the existing enterprise platform, and every generated application inherits it. The AI generates what is specific to each application. The platform provides the rest, and the AI can’t change it.
Gold arrows show what the generated application inherits from the platform. Solid navy arrows are the main path, and the dashed arrow returns the checks’ notes to the same agent session.
Authentication and permissions, security, navigation and layouts, error handling, the design system and typed building blocks for reading and writing business data already exist in the platform. Every new application begins as a copy of a complete working application built on them, so the AI never writes or rewrites any of it. It adds only the screens that make the application unique, by composing building blocks that already exist. The first version asked the AI to write every app from scratch, and each one came out a little different and reinvented login and data access, sometimes badly.
The foundation is read-only to the AI, which can write only in its own screen folders. It has no general command line. Everything else it needs, such as creating data, deleting a file or running checks, is a specific, limited tool, and automatic loading of extensions is disabled so code placed in a workspace can’t be loaded into the backend. At setup we read the organization’s data definitions, reports and workflows and generate typed building blocks and a searchable catalog, so a misspelled field is a compile error and not a blank screen.
We compared keeping our own agent, a general agent framework, other coding agents and an open-source coding-agent SDK designed to be embedded in a product’s backend. We chose the SDK. It is built for many concurrent, isolated sessions, and it comes with a solid agent loop, forgiving file-edit matching, session history saved to disk, model switching and image input. Hundreds of lines of our own agent code became well-tested library code.
After each turn the backend checks that every reference points to a real file, that the code is well-formed and that types match. Failures go back to the same session as specific automated notes, and the agent fixes them, usually before the preview refreshes. A separate reviewer, a fresh session with no access to the original conversation, checks the app against what the user asked for. It isn’t biased by the reasoning that produced the code, so it catches things the builder misses.
Previews run in isolated containers from pre-built images with all dependencies installed, so startup drops from tens of seconds to a second or two. A pool of ready environments starts generic. When a user opens an app, one is assigned to that organization, app and user and loads that app’s code and data catalog. We limit concurrent previews per environment, refresh once after the AI finishes a batch of changes, and, because the backend knows which files changed, update only those modules, falling back to a full reload when necessary.
A page, from request to preview
A user attaches a design and asks for the page. The agent builds a faithful static copy from the platform’s building blocks, writing only in its screen folders, and the preview refreshes once. The user looks at it and confirms. Only then does the agent bind the page to the organization’s data, using the typed catalog.
The backend checks references, syntax and types, and anything it finds goes back to the same session to fix. A fresh reviewer then checks the app against the request. The preview updates once, with only the changed modules, and the user sees a working page.
Simplified from a typical session in which a user attaches a design. The dashed steps show the fix loop. The application screen is an illustration.
What changed
- One agent shared between users, with memory that leaked.
- Every app written from scratch, each reinventing login and data access.
- Preview servers installing packages for 30 to 90 seconds.
- An isolated session for every user and app.
- Enterprise capabilities inherited from the first screen, with typed access to business data.
- Automated checks, an independent review and a preview that starts in a second or two.
The difference from a generic AI coding tool is where the application starts. What the AI produces is application-specific functionality on an established foundation.
The engineering decision that mattered
We built the AI builder on the platform instead of beside it, and made sure the AI couldn’t change what it inherited. We also didn’t build another agent loop, because the agent loop wasn’t our product. We embedded a mature coding agent and put our effort into what makes it safe and useful here: a limited toolset, typed data access and isolated previews. Where a rule mattered, we built it into the structure instead of asking the AI to follow it.
We also changed one big thing at a time. We swapped the engine first, with behavior kept identical, and only then changed the product around it. And once caching worked, the cost was in the number of turns, so most of our later effort went into avoiding unnecessary work: fewer round trips, skipped checks and targeted refreshes.