1. Live preview
Live preview boots your in-progress project against the same runtime that ships in production.
There is no separate dev server to start, no npm install to wait for, no rebuild to
trigger. You change a field; the preview re-renders. You share the URL; anyone with the link sees
what you are building. Generated programs go through preview as a smoke test before they are saved,
so a bad agent output never lands in your project tree.
What you get
Inline preview pane
The studio shows the live runtime next to the editor. Edit a field, see the result instantly.
Shareable preview URL
Promote the draft to a temporary public link. Anyone with the link sees the in-progress app, no credentials required.
Per-program preview
Boot directly into one component, not the whole app. Useful for designing a single screen.
Headless smoke test
Run the preview in a headless browser. Confirms the draft mounts without errors before you save.
Agent validation
AI-generated components are auto-previewed; if they throw on first render, the agent reports failure instead of saving.
Session expiry
Preview links expire on schedule, with explicit revocation. No accidental indefinite public access.
Compared to other approaches
The usual workflow
Local dev server plus deploy previews.
Vite, Webpack, or similar HMR. Requires a local Node.js, an npm install, and framework knowledge.
A teammate cannot see your draft without checking out the branch and running it locally.
Vercel and Netlify deploy previews trigger per git commit. Fast for them (about a minute), but still a build step. Needs a connected repo.
Storybook covers components only. No app-level routing, no real data, no globals.
Xuda live preview
The runtime is the preview.
No local dev server to start, no install, no build.
Edit-to-visible loop is one tick of the runtime.
Share-to-teammate is one click; the link works from any browser.
Same engine validates AI agent output before save, with a real headless render.
2. Online & offline development
Authoring is online by default: the studio talks to a server. The platform ships features that
soften that constraint: scheduled backups, project transfer between accounts, and peer-to-peer sync
for two studios on the same project. The combination handles handoffs, recovers from mistakes, and
survives short network blips without losing work.
What you get
Auto-backup schedule
Pick the time per weekday, set how many copies to retain. Snapshots happen even if you forget.
Manual snapshot
One-click backup before a risky edit. Restore in a click if it goes wrong.
Project transfer
Move an entire project (schemas, programs, data, settings, plugin choices) from one account to another. Atomic.
Peer-to-peer sync
Two studios on the same project sync directly over WebRTC. Useful for short outages and live collaboration.
Restore from any snapshot
Roll back the whole project to any retained backup point.
Plan-aware validation
Transfer flows verify the recipient account can host the project before the move.
Compared to other approaches
The usual workflow
Local-first SDKs and git branches.
Local-first frameworks (Replicache, RxDB, PowerSync) require you to write conflict resolution.
Git branches work for code, but a UI tree is hard to merge as text.
Manual exports are lossy and easy to forget. Most platforms ship export, few ship a schedule.
Xuda's approach
Atomic project, scheduled snapshots, peer fallback.
A project is one structured document. Backup and transfer are atomic.
No conflict-resolution code to write or maintain.
Scheduled backups by default; you do not have to remember.
3. Deployments
A deployment promotes a saved release of your app to a running environment. There is no Dockerfile,
no CI config, no environment variables to wire. You pick a region, pick a server size, pick the
release; the platform provisions the box and brings the runtime up. Multiple deployments of the
same project can coexist for preview, staging, and production.
What you get
Managed datacenter deploy
Spin up a fresh managed instance in your chosen region. Provisioning is part of the workflow.
Reuse an existing server
Deploy onto a server you already own that runs the runtime. Useful for shared environments and self-hosted setups.
Region selection
Pick the geographic region for data residency, compliance, or latency.
Server-size tier
Pick CPU and memory per deployment. Resize without redeploying the application.
Multiple environments
Run preview, staging, and production from the same project. Each one is its own deployment off a chosen release.
One-click rollback
Re-deploy a previous release to revert in seconds. No "git revert" dance, no broken pipeline.
Archive deployment
Take an instance offline without deleting its data. Re-activate later if needed.
Lifecycle status
Each deployment carries a status (created, starting, live, archived) so you always know which environment is in which state.
Compared to other approaches
The usual workflow
Git push, build, deploy, debug.
Heroku, Vercel, Netlify, Render: still need a git repo, a build pipeline, and environment variables to manage. Build minutes are billed.
Kubernetes or docker-compose: maximum control, maximum ops burden.
Firebase or Supabase: easier deploys, but tighter lock-in (their auth, their DB, their security rules).
Manual VPS: cheapest in dollars, most expensive in your time.
Xuda's approach
Pick a release, pick a region, click deploy.
No Dockerfile, no CI config, no env file.
Multiple environments off one project, no extra git branches.
Per-region data residency for compliance work.
Rollback is "deploy the previous release," not a recovery procedure.
4. Version control
Every saved build creates a release. A release is a complete snapshot of the project at that moment:
schemas, programs, routes, settings, plugin choices. A deployment points at a release; rollback
means redeploying the previous release. There is no branching to learn, no merge conflict to
resolve, no .gitignore to maintain. Backups handle the data side of the equation.
What you get
Automatic release per build
Every build records a release. Nothing extra to remember.
Named releases
Tag a release with a meaningful label (the feature, the customer, the date).
Deploy from release
Pick which release runs in which environment. Promote a release without rebuilding.
Rollback by release
Revert the entire app, atomically, in one click.
Restore from snapshot
Roll back the data, not just the structure. Backup-driven.
Release listing
See every release for the app, who built it, when, and which deployments use it.
Compared to other approaches
The usual workflow
Git plus a deploy platform.
Git is industry standard and infinitely powerful, but the unit of versioning is a text file. Diffing or merging a UI tree edit in git is painful.
Database snapshot tools cover data only, not application structure.
Cloud platform "rollbacks" (Vercel, Netlify) revert one build at a time. Fine for static sites, awkward for stateful apps where data and schema move together.
Xuda's approach
Releases as full project snapshots.
Whole project rolls forward and back atomically: schemas, programs, routes, plugins.
No merge conflicts on visual layouts.
Same release format for prod, staging, and AI-generated drafts.
Data has its own snapshot lane (backups), so structure and data can be rolled separately.
5. Table editing
A table in Xuda is a typed schema that points at a backend. The schema is what the studio shows you;
the backend is whichever dbs plugin you pick: Xuda's native store (real-time, hosted),
CouchDB, MySQL, or anything you write a plugin for. Switching the backend does not change the
schema; the runtime translates the same query against whichever driver is selected.
What you get
Native real-time store
The bundled backend pushes updates to subscribed clients with sub-second latency. No setup.
Per-table backend choice
One project can have tables on Xuda native, on CouchDB, on MySQL, or on a custom adapter. Mix as needed.
Visual schema editor
Add fields, pick types (string, number, boolean, date, json), set defaults, mark required, restrict to enum values.
Computed and joined fields
Virtual fields evaluate on read; datasource fields pull from another table; plugin fields call out to a service.
Composite indexes
Multi-key indexes for compound queries. The studio renders them; the backend translates them.
Inline data viewer
Browse, filter, and edit rows in the same UI you used to design the schema.
Real-time as a flag
Subscribe to a query with one toggle. The runtime opens a live channel on the chosen backend.
Bring your own backend
Write a dbs plugin to back any table on any storage you can talk to.
Compared to other approaches
The usual workflow
SQL plus an admin layer.
Postgres + Prisma/ORM + Retool/Hasura: powerful, but you write migrations and you maintain the admin UI.
Airtable / Notion DB: friendly editor, expensive at scale, your data lives in their cloud.
Firebase / Supabase: real-time and an admin UI, but you accept their auth, their security rules, their pricing model.
Code-first schema files: requires build steps, no inline data viewer, friction to evolve.
Xuda's approach
One schema, swappable backend, real-time toggle.
Real-time is a checkbox, not a project of its own.
Migrate backends without rewriting the schema definition.
Edit data in the same UI you design the schema in.
Self-host with a custom adapter; no platform-side rewrite when you do.
6. Plugins
Plugins are how Xuda grows. Anything reusable (a database driver, a UI framework, a charting widget,
a Twilio integration) ships as a plugin. The contract is narrow on purpose: each plugin is an npm
package with a fixed layout and a small set of named exports. The studio reads the schema, generates
the configuration form, and the runtime invokes the plugin with validated inputs.
What you get
Six categories
dbs, framework, graphics, library, ui, widget. Each has its own contract and extension seam.
Marketplace browse
Listed by category, with screenshots, version history, and likes.
Per-app install
Adopt a plugin into one project without affecting others. Installation is reversible.
Per-app credential isolation
API keys and connection strings are scoped to the app that installed the plugin. Plugin A cannot read Plugin B's setup.
Versioned upgrades
Bumping a plugin version is an explicit action, not a silent npm update.
Custom plugin authoring
Build your own. Keep it private to your team, or publish to the marketplace.
Sandboxed execution
Plugin server code runs in an isolated context. No install scripts, no process.env snooping, no global pollution.
Validated inputs
Field values are coerced and validated before the plugin runs. Plugin authors do not have to defensively re-parse strings.
Compared to other approaches
The usual workflow
Open dependency surface.
npm + bundler: a regular package can run install scripts, monkey-patch globals, and pull in transitive dependencies you never reviewed.
WordPress plugins: huge ecosystem, but PHP, broad sandbox, and abandonment is common.
Browser extensions: limited APIs, slow review pipelines.
Pre-built integration platforms (Zapier and similar): great for connectors, but you cannot author a native widget that lives inside the app.
Xuda's approach
Narrow, scoped, sandboxed.
No install scripts. No supply-chain attack at adoption time.
Every plugin exports five names; the rest is dead weight to the runtime.
Per-plugin credential scoping by construction.
Reviewable by humans and AI in seconds because the surface is small.
Full plugin authoring guide:
developer-plugins.
7. Checker
The checker is a project-wide validator that runs before a build is allowed to ship. It walks the
routes, programs, tables, plugins, and event workflows and reports broken references, missing
required setup, type mismatches, dead programs, and unsatisfied dependencies. It is the same engine
that AI agents use to verify a generated program before saving it.
What you get
Manual run
Trigger validation on demand from the studio. Useful before sharing a preview or handing off a project.
Build-time gate
The build pipeline blocks if validation fails. No broken release ever ships.
Agent verification
Generated components are checker-validated and live-preview smoke-tested before save.
Cross-reference checks
Catches routes pointing at deleted programs, fields referenced by removed columns, panels embedding missing components.
Required-setup checks
Flags installed plugins that have not been configured (missing API keys, empty connection strings).
Pass/fail with diagnostics
Returns the failing rules with locations so you can jump straight to the issue.
Compared to other approaches
The usual workflow
Linters, types, hand-written tests.
ESLint and TypeScript are excellent for code, but a Xuda project is mostly structured data, so they do not see most issues.
Unit tests catch what you wrote tests for. Most apps do not have tests for cross-screen references.
Manual QA is slow and easy to miss. It does not scale to AI-generated changes.
Schema validators (zod, joi, etc.) check data shape; they do not check that one program's fields actually exist.
Xuda's approach
Project-graph validation as a first-class step.
Catches errors that linters and unit tests cannot: broken cross-references between programs, tables, routes, and plugins.
Same validator runs in the studio, in the build, and inside the AI agent loop.
Zero test code to write or maintain.
Build is gated; an invalid project cannot ship.
8. Find
Find searches across the loaded project (schemas, programs, routes, fields, events) and returns
matches as you type. It understands the structure: searching for a field id finds every place that
field is referenced; searching for a program id finds every route, panel, and workflow step that
points at it. Refactoring a name becomes a confident operation, not a grep gamble.
What you get
By id
Find the canonical document for a field, table, program, or route by its identifier.
By name
Search labels and titles in any language. Case-insensitive by default.
By usage
"Find every place this field is read." "Find every panel that embeds this program." Surface dead references.
Filter by kind
Restrict results to schemas, programs, routes, plugins, or globals.
Result jump
Click a result to open the entity in its native editor (table editor, program editor, route editor).
Cross-app find for operators
Admin-tier search across every app on your account by name, owner, domain, or db name.
Compared to other approaches
The usual workflow
Text grep over a code tree.
IDE search and grep work on filenames and substrings. They do not understand structured references.
Database queries are powerful, but you write the selector each time.
Most low-code tools search by visible label only. They miss every place a field id is bound through an expression.
Xuda's approach
Semantic search over the project graph.
Knows what is a field, a program, a route, a global. Returns matches by role.
"Find references" surfaces every binding, not just every label.
Surfaces orphans and dead references the checker can then act on.
9. Control panel utilities
The control panel is the operations dashboard for a live runtime. It shows server health, streams
live events from running apps, provides per-app log access, and (on enterprise plans) surfaces a
terminal directly into the running instance. It is scoped to your apps; there is no risk of straying
into another customer's environment.
What you get
Live event feed
Account, team, and app changes streamed in real time. See sign-ins, plan changes, and configuration updates as they happen.
Server health
Which datacenters are up, which application servers are reachable, which deployments are in which state.
Queryable logs
Per-app log history, searchable and filterable. Not flat files on disk; structured records you can interrogate.
Account & team management
Add members, set roles, manage plan and billing. The same panel that operates the apps owns the people who use them.
Terminal access (enterprise)
SSH-style shell into the deployed instance. Useful for one-off forensics. Audit-trailed.
Audit trail
Every administrative action lands in the log database. Replay the timeline of any incident.
Compared to other approaches
The usual workflow
Five different consoles.
Cloud provider consoles (AWS, GCP, DigitalOcean) are broad-scope. You map your app to the underlying infrastructure yourself.
APM tools (DataDog, New Relic) are great for metrics, but require integration code and configuration.
Logging tools (CloudWatch, Logtail) are separate from the app dashboard, separate from billing, separate from team management.
A self-built admin UI is one more thing to maintain.
Xuda's approach
One scoped operations surface.
App, logs, server health, team, billing in one place.
Logs are queryable from day one, no agent to install.
Per-app scope is enforced; no accidental cross-tenant access.
Audit-trailed terminal access for the rare moments you need it.
Why this shape
Each section above takes one piece of the work that an app team would otherwise do themselves and
moves it into the platform. None of these features are unique on their own; what is uncommon is
that they share one project document and one runtime, so they compose without glue. A live preview
is the same engine as a deployment. A checker is the same engine as agent verification. A backup
feeds a rollback feeds a transfer. The benefit per feature is "you do not have to build this." The
benefit in aggregate is that the things you do build are smaller, because the platform did the
surrounding work for you.
