Building Real‑Time Multi‑Window Ext JS Apps with AI Prompts: A Deep Dive into Indie Engine AI

Our recent webinar spotlighted a product that aims to remove one of the biggest friction points in enterprise UI development: translating requirements into a working, data-heavy application that behaves correctly under real-world concurrency. Pavel Perminov – solo founder and developer of Indie Engine AI – presented a “zero-code” workflow that uses generative AI to produce full-stack Ext JS applications from natural-language prompts, complete with database schema, relationships, roles, sample data, and a distinctive real-time, desktop-like multi-window experience.

Indie Engine AI didn’t appear in a vacuum. Perminov’s background—more than a decade building content management systems and accounting platforms—shows in the tool’s emphasis on fundamentals that usually consume the most time in custom software development: data modeling, referential integrity, live synchronization, deployment automation, and backup/restore that supports real operational use.

What follows is an in-depth look at the key capabilities demonstrated, why they matter, and what they imply for the future of Ext JS-style “thick client” business applications.

From prompt to full-stack application: requirements become running software

The headline feature of Indie Engine AI is simple to state and hard to do well: describe the app you want, and get a working system. In the demo, the workflow starts with a prompt such as “Zoo Management App” or “Real Estate App,” then optionally enriches it with documents that convey domain constraints and UI expectations.

Context-aware generation (prompts plus files)

Instead of relying on prompts alone, Indie Engine AI accepts context files – functional specifications, UI mockups, spreadsheets, and similar artifacts. This matters because most business apps fail not on “what is a customer?” but on edge cases: required fields, enumerations, real naming, role boundaries, and relationships that are implicit in existing documents.

By allowing a user to attach an Excel spreadsheet (often the true “source of truth” in early-stage ops), the model has a concrete basis for:

• field names and types (dates, currency, IDs)
• normalization signals (repeated columns that suggest a separate table)
• lookups (status fields, categories, regions)
• operational flows (“assigned to,” “approved by,” “payment status”)

Automated architecture: schema, entities, roles, and sample data

Indie Engine AI analyzes the input and generates:

• Database schema: tables, columns, indexes
• Entities and relationships: one-to-many, many-to-one, hierarchies
• User roles and permissions: who can see/edit what
• A runnable UI: Ext JS grids/forms aligned with the schema
• Sample data: enough to explore the system immediately

Sample data seems like a minor convenience, but it’s crucial for zero-code experiences: users can validate the model quickly (“Is this the workflow we meant?”) without manually seeding records.

Foreign key logic that behaves like “real software,” not a mock

A common weakness in many rapid app generators is that relationships are “visual only” – a lookup field in the UI with no true integrity in the database. Indie Engine AI explicitly handles foreign key constraints, generating “real columns with foreign key logic” so that:

• hierarchical data is enforced
• joins are reliable
• deletion/update behaviors can be controlled
• reporting and downstream integrations don’t break because of orphaned rows

This is a foundational difference between a prototype generator and an application engine that can plausibly move toward production.

The defining UX: real-time, multi-window Ext JS – like a desktop app in the browser

Where Indie Engine AI differentiates itself most strongly is not just “it generates CRUD.” It’s the desktop-style multi-window UI paired with real-time synchronization across views and sessions.

In many business operations, users keep multiple screens open: a customer record, an orders grid, a payments window, and a dashboard – often across multiple browser tabs or monitors. The costliest category of bugs in these environments is “stale UI”: a user acts on data that has already changed elsewhere.

Indie Engine AI’s design explicitly targets that problem.

Instant updates across views, tabs, and data consumers

In the demo, a record update – whether performed by:

• another user in the application,
• an automated script,
• or even a direct SQL query

is reflected immediately in all relevant open views and browser tabs.

That last point is significant. Many “real-time” apps are only real-time for updates that pass through their own API. If direct database writes don’t propagate, then operations teams using scripts, ETL, or admin SQL end up creating inconsistencies that the UI won’t see until refresh.

Under the hood: binlog streaming + session/view tracking + sockets

The architecture described in the webinar centers on a pipeline designed for low-latency change propagation:

1. MySQL binary log consumptionThe system reads the database’s change stream via the MySQL binlog, using Zendesk Maxwell (as presented). This captures inserts/updates/deletes at the database level.
2. Event adaptation for UI componentsRaw binlog events are not automatically usable by UI grids/forms. The platform transforms these changes into messages that match what Ext JS components expect (record updates, store reload triggers, row-level diffs, etc.).
3. Session and active-view awarenessIndie Engine AI tracks which users are connected and which data views they have open. That allows targeted updates – only push changes to clients that care – rather than brute-force “broadcast everything.”
4. Socket deliveryUpdates are delivered to the browser via socket connections, enabling the “instant reflection” behavior demonstrated.

From an Ext JS perspective, this effectively turns the application into a living system of synchronized stores, closer to collaborative desktop software than to traditional stateless web CRUD.

Interactive schema management: UI changes that rewrite the database

One of the more eye-catching moments in the demo was the claim that you can reorder grid columns via drag-and-drop UI component and have that action automatically update the underlying database table definition.

This implies Indie Engine AI treats schema not as a static artifact generated once, but as a living structure that can be modified through UI-driven operations.

Why this matters

In typical systems, you have at least two sources of truth:

• database migrations (DDL history)
• front-end presentation logic (column order, field visibility, labels)

Keeping them aligned is tedious and error-prone. If the platform can safely synchronize “presentation schema” and “storage schema,” it eliminates a category of drift.

The caution

Schema mutation is powerful, but it also raises governance questions:

• What changes are safe to apply automatically in production?
• How are migrations tracked and audited?
• What happens when multiple environments (dev/stage/prod) diverge?

Indie Engine AI’s inclusion of restore-to-commit backup (discussed later) suggests the developer is thinking in terms of reversible changes, not just convenience.

Simplified deployment and maintenance: “five minutes to running” via Docker

Indie Engine AI aims to make the operational side of app hosting feel like “installing software,” not provisioning a platform team.

Fast setup with containers

In the webinar, the platform can be brought up in roughly five minutes by cloning the repository and running an installation script. It runs as a set of Docker containers, including:

• MySQL
• RabbitMQ
• Apache
• a wrapper container for DevOps orchestration tasks

The key here is that the tool doesn’t stop at code generation; it packages the runtime environment so a generated app is actually deployable without bespoke infrastructure work.

One-click updates: migrations and rebuilds without SSH

Updates are automated through a UI flow:

• check for package updates
• pull changes
• run migrations
• rebuild Docker images when needed

This is aimed at a common operational pain: app platforms that require manual SSH sessions, careful command ordering, and institutional knowledge to keep environments current. If Indie Engine AI can reliably perform updates with proper rollback/restore support, it becomes much more feasible for small teams (or solo developers) to maintain long-lived systems.

The GitHub backup strategy: using releases as a “versioned vault”

One of the most unusual – and arguably most “indie-hacker clever” – features is the backup mechanism using GitHub releases as a storage layer.

How it works (as described)

• Backups are uploaded as assets attached to GitHub releases.
• GitHub allows up to 1,000 assets per release.
• The presentation framed this as enabling up to ~1.9 TB of backup data for free (based on asset size limits and aggregation).

Rotation policies and restore-to-commit

Indie Engine AI performs periodic backups by default:

• hourly
• daily
• weekly
• monthly

It also supports:

• custom backups
• “restore to commit” behavior, letting users revert application state changes in a tracked, reversible way

Why this is interesting for business apps

Traditional backups are often treated as purely operational. Indie Engine AI is closer to treating backups as part of the application lifecycle – a state history you can navigate, similar in spirit to version control.

That matters when your platform enables schema changes and rapid evolution. If you’re going to let users modify systems quickly, you need equally quick and reliable “undo” paths.

Practical considerations

Using GitHub releases as backup storage raises important questions teams will need to evaluate:

• compliance requirements (data residency, retention rules)
• sensitive data handling (encryption at rest, access control)
• GitHub account governance and permissions
• cost/limits over time if usage scales

Still, as a built-in mechanism for small deployments, it’s a notable attempt to make serious backup practices accessible without extra infrastructure.

Roadmap: evolving apps via follow-up prompts, more databases, more models

The Q&A outlined a roadmap that, if delivered, would move Indie Engine AI from “generator” to “continuous app evolution platform.”

App evolution with follow-up prompts

A future capability would allow users to evolve an existing app by prompting against the current schema – for example:

• “Add a maintenance schedule module for animals”
• “Introduce lease renewal workflow and notifications”
• “Add audit logging to payment status changes”

The hard part here is not generating new tables – it’s maintaining consistency:

• migrations without breaking existing data
• UI updates that preserve user customizations
• permission model updates that don’t create security holes
• backward-compatible API behavior

If Indie Engine AI can reliably do “prompt-driven refactoring,” it will address the real need: business apps rarely get built once; they evolve constantly.

Expanded database support via Debezium

Today the system is tied to MySQL, which aligns with the binlog streaming approach used in the real-time pipeline. The plan to integrate Debezium suggests a path toward:

• PostgreSQL
• Oracle
• Microsoft SQL Server

Debezium is a standard choice for change data capture (CDC) across multiple databases, and it would allow Indie Engine AI’s real-time synchronization model to generalize beyond MySQL + Maxwell.

New AI models (Claude and others)

Support for Anthropic Claude was estimated at four to six weeks (from the time of the webinar), with other models to follow.

Model plurality matters because different teams prioritize different tradeoffs:

• cost and latency
• code/schema accuracy
• context window size (large specs)
• governance and deployment options

What Indie Engine AI suggests about the future of Ext JS-style enterprise apps

Indie Engine AI is notable because it pushes in a direction that many teams still want, even as trends cycle: rich, data-first, multi-window applications with a strong client experience and robust server-side integrity.

Three themes stand out:

1. Schema-first applications are not going away Especially for accounting, inventory, asset management, and admin workflows, relational integrity and structured data are the product.
2. Real-time correctness is becoming a baseline expectation Users don’t want refresh buttons; they want live views that mirror operational reality, even when changes come from outside the UI.
3. The developer bottleneck is shifting from coding to governance When generation is fast, the hard problems become: permissions, auditability, migrations, backups, compliance, and safe evolution. Indie Engine AI’s focus on deployment automation and restore options suggests an awareness of this shift.

Documentation and getting deeper

For those evaluating the platform seriously, the Indie Engine AI website reportedly includes a detailed guide covering current functionality – an important signal that this is intended to be more than a demo generator.

Conclusion

Indie Engine AI, as presented by Pavel Perminov in Sencha’s webinar, is an ambitious attempt to enable true Rapid application development by compressing the time from “requirements” to a “working Ext JS system,” while preserving features that usually only appear after months of engineering: foreign keys, real-time multi-view synchronization via CDC, rapid deployment, automated updates, and robust backup/restore.

If the roadmap lands—especially app evolution via follow-up prompts and broader database support—the platform could represent a new category: not just “AI that scaffolds an app,” but AI-guided operations software that stays live, consistent, and evolvable over time.