AppWithAI produces fully functional applications with production-grade features out of the box — without writing a single line of code.
Every example on this page is taken from one real model: the seventeen-entity CRM the hands-on guide builds. Nothing here is illustrative — you can run that application in your browser and check any claim against it. For why these features belong in a platform at all, see why AppWithAI exists.
Describe your business domain in plain English. The Domain Analysis Agent, powered by Claude, OpenAI, or a local Ollama model, analyzes your description and automatically extracts entities, attributes, and relationships with confidence scoring.
Seventeen entities in all, in seven dashboard groups. Chapter 01 →
The built-in visual ERD designer gives you full control over your data model before code generation. Edit Mermaid syntax directly, see changes reflected instantly in the graph visualization, and preview the exact SQL and migration scripts that will be produced.
All AI-generated ERDs flow through the designer, giving you a clear review and edit experience before any application is generated.
AppWithAI uses the Mermaid ERD format with Crow's Foot notation — an industry-standard, human-readable, and version-control-friendly representation of your data model.
Generate data-driven forms that faithfully mirror real-world business documents — quotes with priced line items, contracts, support cases, purchase orders, invoices, expense claims, and any other document your business uses.
The AI understands the semantic meaning of document fields and automatically selects the appropriate input control for each field type, producing forms that reflect how your team actually works.
Administrators can reorder form fields by dragging and dropping, hide or make fields mandatory, set display logic, and configure field groups — all through the admin interface without touching code.
Nothing below was designed by hand. Every control comes from the column's type and its dictionary row — this is the form as the CRM actually renders it.
campaign_id and owner_id become lookups that resolve to names, not identifiersannual_revenue is an Amount, converted_at a date-time picker — from the column type aloneEncode your organization's business logic using visual decision flowcharts. The GoRules Zen Engine executes DMN-based rules with high performance at runtime. The CRM model declares eight; the generated application ships twenty-five, because every entity also gets a validation rule of its own.
Required fields, ranges, formats, uniqueness, conditional requirements and cross-field checks — one validation rule generated per entity. In the CRM that is seventeen of the twenty-five, and they are why account_number, quote_number and case_number stay unique without anyone writing a check.
Thresholds an operations person owns, not a developer. The CRM's discount policy auto-approves up to 15%, holds 15–25% for a sales manager, 25–40% for a VP, and refuses anything above 40% outright — as a decision table, editable in the running app.
Referential rules prevent orphaned records and control deletion — enforced at the API and in the database. In the CRM, blockDeleteWithOpenBusiness refuses to delete an account that still has open opportunities, and it runs before the delete, not after.
Draw a decision as a flowchart and bind it to an event. AppWithAI generates executable TypeScript organised by lifecycle event — the CRM binds thirty-eight hooks this way, and each one names the field it guards.
Every handler named below is in the model. None of them is a placeholder.
leadScoring grades a lead on firmographics, source and revenue before the row exists; normalizeAccountName and assignAccountNumber mint an account's identity
leadRouting sends the scored lead to the partner desk, strategic accounts, enterprise, mid-market or the SMB queue; seedAccountTeam populates the selling team
leadQualification gates conversion; opportunityCloseGate refuses a closed-won deal that has no accepted quote; quoteDiscountApproval applies the discount policy
syncToMarketingPlatform fires when a contact's email_opt_out changes — consent propagates without anyone remembering to propagate it
blockDeleteWithOpenBusiness refuses to delete an account that still has open opportunities or live contracts
ensureAccountNumberUnique and ensureUniqueEmail — the cross-record checks a column constraint cannot express on its own
Thirty-eight hooks across the CRM. Chapter 02 →
A state-machine engine routes documents through your organization for review, approval, escalation and action — with full audit trails. The CRM declares ten processes: five state machines and five multi-step sagas.
Approval paths adapt to document content. The CRM's discount policy, exactly as the model states it:
Lead routing branches the same way, on partner source, revenue above $50M, headcount above 500, then rating.
Nothing stalls because nobody looked. The CRM's scheduled triggers, from the model:
checkSlaBreaches on support cases — every 15 minutesexpireStaleQuotes daily at 06:00; nudgeStalledOpportunities at 07:00openRenewalWindows on contracts daily at 08:00recycleStaleLeads every Monday at 07:00A critical case escalates to an executive bridge with a 15-minute response target; high goes to a support manager at 60 minutes.
Sagas write across entities in one transaction, with compensation if a step fails. The CRM declares five:
The Quote entity carries its own approval record, and the audit log carries the rest:
approved_by_id, approved_at and approval_notes — who, when, and on what termsversion_number — a renegotiated quote is a new version, not an overwritesys_workflow_runsEach one is a stateDiagram-v2 in the model. The generated application applies the states, guards every transition by role, and refuses a move the diagram does not draw.
new → working → nurturing → qualified → converted, with disqualification from three of them
prospecting → qualification → needs_analysis → proposal → negotiation → closed_won, and closed_lost from four stages
draft → in_review → approved → presented → accepted, with reject, revise, renegotiate and lapse
new → assigned → in_progress → resolved → closed, with waiting_on_customer, escalate and reopen
draft → in_approval → active → expiring → renewed, with terminate and lapse
Only a sales manager may close_won; only an administrator may terminate a contract
Generated applications include a comprehensive, layered security model — from authentication through to individual field visibility per user role.
Better Auth, configured for email and password with server-side sessions. That is the whole of it — no social sign-in, no second factor, nothing else configured on your behalf. Better Auth supports more; the generated application enables what it needs, and you add the rest
Users are assigned to one or more roles. Roles aggregate granular permissions for table, field, and row access
Roles are granted Read, Create, Update, and Delete permissions at the table level via sys_access_role
Individual columns can be marked visible, editable, or hidden per role — enforced at the API level via sys_access_field
Users see only records belonging to their department, region, or organizational unit — enforced via sys_access_record policies
Approved or completed documents are locked from editing, preserving the integrity of the audit trail
Fifteen %%rbac restrictions in the model. They restrict — an operation no directive names stays open, which is why the ones that matter are named explicitly.
Seven roles across the model — sales_rep, account_executive, sales_manager, sales_ops, support_agent, support_manager, administrator — seeded into the Role screen and enforced on every request. Contact records also run enforceFieldLevelSecurity on read and maskPersonalData on phone and mobile, so a role without the permission never receives the value in the first place.
Authentication is Better Auth — email and password, server-side sessions. Everything else on this page is authorization: roles, table and field permissions, row policies and the audit trail, all derived from your model and enforced in the generated API.
This page used to claim SOX readiness, GDPR compliance and ISO 27001 alignment. It no longer does, because none of them had been assessed. A compliance programme is an audit of an organization and its operations, not a property a code generator can hand you — the access control and the audit trail here are evidence you would bring to one, not a substitute for it. The security assessment is on the list of things outstanding before 1.0.0.
Every generated application includes an embedded AI assistant powered by CopilotKit. End users get a conversational interface for natural language data queries, in-context guidance, and intelligent suggestions — directly within their application.
The AI Copilot query interface honors the same security model as the rest of the application:
Application behavior is driven by metadata, not hardcoded logic — enabling runtime customization without developer involvement.
When form layout, validation, and routing are driven by metadata tables, your application administrators can change application behavior directly — no code change, no deployment, no regression risk.
| Change | Traditional | AppWithAI |
|---|---|---|
| Add a field to a form | Hours of development | Minutes in admin |
| Reorder form fields | Code + deploy | Drag and drop |
| Change validation rule | Code + test + deploy | Update in admin |
| Change the discount approval threshold | Code change + redeploy | Update workflow config |
| Add a user role | Code + config | Create role + assign |
The Application Dictionary defines not just individual forms, but how forms relate to each other. This is the CRM's Opportunity window as the generated application stores it.
id · seq 10 · displayed: Noaccount_id · seq 20 · lookupamount · seq 70stage · seq 90id exists as a field but is never displayedEvery feature on this page is on one page of the guide, and the whole CRM runs in your browser — no install, no signup, nothing sent anywhere.