How the AI Builds and Writes Your App Code

What the AI Generates

The AI produces four distinct components that together form a complete application. Each component serves a different role, and the AI generates all of them from your description of what the app should do.

PHP Functions

The core of your app is one or more PHP functions that contain the actual business logic. These functions handle API commands (processing incoming requests), background jobs (scheduled tasks), webhook handlers (receiving data from external services), and any internal helper logic your app needs. The AI writes these functions using the same coding patterns and platform utilities that every built-in app uses, so they have full access to database operations, AI model queries, email sending, SMS messaging, and everything else the platform offers.

Admin Page Configurations (Slugs)

The admin interface for your app is defined by JSON configuration objects called slugs. Each slug describes one admin page: what fields to show on the edit form, what columns to display in the list view, how to filter and sort records, and what actions are available. The AI generates these slug configurations based on your description of what data the app manages and how you want to interact with it. The admin system reads these configurations and renders the pages automatically, so no HTML or frontend code is needed.

App Configuration

The app configuration ties everything together. It maps command names to PHP functions, defines which background jobs exist and when they run, registers webhook handlers, and lists the admin pages in the order they should appear in the menu. The AI generates this configuration to match the functions and slugs it creates, ensuring that every feature is properly connected and accessible.

Design Context

The AI also stores a design context document that describes the app's purpose, data model, and feature set in plain language. This context is used in future conversations so the AI remembers what your app does and why specific design decisions were made. When you come back later to add features or make changes, the AI reads this context and picks up exactly where you left off.

How the Code Generation Works

The AI builder uses Claude, a large language model, to generate your app's code. Claude has been given detailed documentation about the entire platform architecture, including every database table, every utility function, every integration point, and the exact patterns that built-in apps follow. This means the AI does not guess at how things work. It writes code that uses the correct function signatures, the correct database table names, the correct field structures, and the correct error handling patterns.

When you describe a feature, the AI translates your description into a technical plan, then generates the code that implements it. For example, if you say "I want a field that tracks the customer's preferred contact method," the AI adds that field to the database structure, adds it to the admin page edit form, and if relevant, writes logic that checks that field when deciding whether to send an email or an SMS.

The AI follows several important coding principles:

• Same patterns as built-in apps so your custom code works exactly like native platform features
• Proper database access using the platform's standard read, write, query, and delete functions with correct table names and key structures
• Standard function signatures where every command function accepts an account ID and JSON data parameter, matching the platform's dispatch system
• Integration awareness where the AI knows which platform features exist and how to call them, so it uses existing capabilities instead of reinventing them
• Error handling with appropriate checks for missing data, failed operations, and edge cases

Persistent Conversation and Context

The conversation you have with the AI builder is not a one-time interaction. Every message you send and every response the AI generates is stored in a persistent conversation record tied to your app. When you come back to the builder later, the AI loads the full conversation history and picks up exactly where you left off.

This persistence is important for several reasons. The AI remembers why it made certain design choices, what alternatives were discussed, and what requirements you specified. If you ask for a change three weeks after the initial build, the AI does not need to re-learn what your app does. It reads the conversation history, understands the current state of the code, and makes the modification in context.

The persistent conversation also means you can work incrementally. You do not need to describe your entire app in one session. You can start with the core features, test them, come back the next day to add more, and continue building over time. Each session builds on the previous ones, and the AI maintains a coherent understanding of the complete application throughout the process.

How the Code Is Stored

Your custom app's code is stored in DynamoDB, the same database that stores all platform data. The entire app lives in a single database row that contains the PHP functions, the slug configurations, the app configuration, and the design context. This storage approach has several advantages.

Before being stored, the PHP code goes through two encoding steps. First, it is processed with HTML entity encoding, which converts special characters into safe representations. Then it is base64 encoded, which converts the result into a plain text string that can be stored safely in any database field. These encoding steps are a security measure that prevents the code from being interpreted or executed during storage and retrieval. The code is only decoded and executed through the platform's controlled runtime environment.

Because the entire app is a single database row, there are no files to manage, no deployment steps, and no version conflicts. The app is always in a consistent state. When the AI updates your code, it writes the new version to the same database row, and the change takes effect immediately on the next request. There is no build process, no compilation, and no server restart needed.

How the Code Runs

When a request comes in for your custom app, the platform loads your app's database row, decodes the PHP functions, and executes them through a controlled runtime environment called safe_eval. This runtime provides the same execution context as built-in apps, with access to all platform functions, but adds security protections that prevent the code from performing unauthorized operations.

The execution flow works the same way for all three entry points:

• API requests come through the main router, which loads your app's functions and calls the one mapped to the requested command
• Background jobs are spawned by the cron system, which loads your app's functions and calls the one mapped to the scheduled job
• Webhook requests come through the mode handler, which loads your app's functions and calls the one mapped to the incoming webhook path

In every case, your custom app code has the same capabilities as a built-in app. It can read and write to any database table, call AI models, send emails and SMS messages, make HTTP requests to external services, and use every other platform feature. The only difference is that your code is loaded from the database instead of from a file on the server.