Natural-language app building for non-developers (vibe coding / AI low-code)

Departments and small firms wait months for IT to build simple tools: a quote calculator, an inspection checklist, a customer portal. AI app builders turn a plain-language description into a running application with interface, database, login and hosting, and refine it through conversation. Prototypes take hours instead of weeks. The price is a new class of risk: generated apps often go live without security review, ownership or maintenance, so governance matters more than prompting.

Problem & value

• Today: business users use spreadsheets, forms and email chains, or queue for IT. Classic low-code platforms (Power Apps, Mendix, OutSystems) still require training, and agencies are expensive for small tools.
• AI value: the term vibe coding (coined by Andrej Karpathy in early 2025) describes accepting AI-written code by describing intent rather than reading code [1]. Builders such as Lovable, Bolt, v0 and Replit Agent add hosting, databases and one-click deploy. Value: fast prototypes for validating ideas, replacing spreadsheet-based processes, internal tools, and shadow-IT that becomes visible and governable.
• Evidence is mixed: vendor-run scans and security consultancies report recurring weaknesses in generated apps, notably missing database access rules and leaked secrets [5][6]. These figures come from non-peer-reviewed sources with differing methods, so treat exact percentages as indicative only. No independent productivity study should be assumed for non-developers; measure in your own pilot.

Variants

• Prototype / MVP for founders and product teams: throwaway or investor-demo apps; later rebuilt by developers.
• Internal tools for departments: dashboards, approval apps, data-entry forms on top of company data (the main enterprise use, usually inside Power Platform, Retool, Appsmith or similar).
• AI-extended low-code: classic low-code platforms with a copilot that builds screens, tables and flows from a prompt (Microsoft Power Apps with Copilot, Mendix, OutSystems) [3].
• Public sector: citizen-facing forms and case tools; strong procurement, accessibility and data-protection constraints.
• Private use: hobby apps, family organisers, small websites; low risk, but still no personal data of others without care.
• Professional "vibe coding" by developers: see CODE-001/CODE-002; here the user does not read the code.

How it works

1. prompt / sketch / spec
2. planning agent (breaks the request into pages, data model, auth, integrations)
3. code generation (frontend + backend + database schema, typically React/Next.js + Supabase/Postgres)
4. sandboxed build & live preview (browser container)
5. user feedback loop ("make the table sortable", "add an approval step")
6. automated checks (type check, tests, security scan, secret scan)
7. human review gate (IT/security for anything with real data)
8. deploy (managed hosting or own cloud) + Git sync + monitoring

• Core AI components: a code-specialised or reasoning LLM running as an agent that edits files, runs commands and reads errors; a vision model for screenshots and design input; tool access to databases, auth providers, payments and email through connectors (often MCP).
• Typical stack choices made by the tool: React frontend, Postgres backend (often Supabase), serverless functions. Security therefore depends on correct database policies such as Postgres row-level security [4].
• Human-in-the-loop: the owner approves behaviour in the preview; a technical reviewer must approve data model, authentication, access rules, secrets and production deployment. Never skip the last step.

Data preparation

Data needed: a clear description of the process, sample data (CSV, Excel), screenshots or sketches, and the data sources the app should connect to. In an SMB these live in Excel files on shares, e-mail attachments, ERP/CRM exports and paper forms. This use case is often the front end for data that still sits in spreadsheets.

Typical gaps: Excel sheets with merged cells and free text, duplicate customer records, no unique keys, missing field definitions, personal data in test samples, and unclear access rights for who may see which records.

Preparation steps: - Describe the process and the fields in plain words; agree what the app replaces (PREP-003 for Excel shadow systems). - Restructure the spreadsheet into tidy tables with one row per record (PREP-011). - Mask or replace personal data in sample files (PREP-022). - Define a data classification rule: which data may go into an AI builder (PREP-024). - Set up roles and rights in the target database (PREP-023). - Tools: Excel/Power Query, CSV export, Supabase or similar database.

Rough share of effort: low, about 10-20 percent; most effort goes into testing and ownership. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: A. Mature AI app builders (EU-hostable options exist) at SMB prices cover standard internal tools; check data location and exit options first.
• Enterprise: B. Apps must integrate with internal identity, data and governance, so an own builder on cloud APIs with guardrails and review fits better than free-form SaaS.
• Developer: C. Open-source agents with local or self-hosted models give control over code, data and cost.
• Private: A. Hosted builders or local apps are simple and cheap for personal projects.
• Public sector: C. Sovereign EU/German cloud or self-hosting; A only for certified products.

Path A — Buy (recommended for most SMBs)

• Prompt-to-app builders: Lovable (Sweden, EU company), Bolt.new (StackBlitz), Vercel v0, Replit Agent, Base44 (Wix), Google AI Studio build mode (Firebase Studio is being shut down, final date reported as 22 March 2027), plus agentic IDEs (Cursor, Windsurf/Devin Desktop, Claude Code) for semi-technical users. Check each vendor's hosting region, data processing agreement and training-data policy.
• AI low-code platforms: Microsoft Power Apps (Copilot, EU data boundary available), Mendix (Siemens), OutSystems (Agent Workbench), Retool AI, Appsmith, Bubble. Better governance, roles, audit and connectors than pure prompt tools, which suits internal tools with company data.
• Choose A when: the app is a prototype or low-risk internal tool, nobody wants to operate infrastructure, and an IT owner approves data access before go-live.

Path B — Build on cloud APIs

• Use an agent SDK with a frontier coding model (Claude, GPT, Gemini, Mistral Codestral/Devstral, EU provider) behind your own front end, generating into a company template (approved design system, auth, logging) instead of a blank project.
• Run generation in sandboxes (E2B, Daytona, containers), commit to Git, trigger CI with SAST and secret scanning, deploy through your pipeline. Models in EU regions via Azure OpenAI, Google Vertex AI, AWS Bedrock or Mistral.
• Choose B when: you want an internal "app factory" with guardrails and branded templates.

Path C — Self-host (open source)

• Tools: bolt.diy (open-source Bolt, bring-your-own model) [7], Dyad (local app builder), OpenHands, Cline/Roo Code, Open WebUI artifacts; low-code: Appsmith, Budibase, NocoBase, ToolJet, n8n for workflow apps.
• Models: open-weight code models such as Qwen3-Coder, Devstral, DeepSeek-Coder family, GLM and Kimi coding models, served with vLLM or Ollama. Quality for multi-file agent tasks is clearly below frontier APIs; expect more manual correction.
• Hardware: HW3 for 30B-class coder models; HW4 for the largest open models. For a quality-first setup most organisations combine EU-hosted APIs with self-hosted runtime and data.

Path D — Custom training

Rarely sensible. Better results come from curated templates, rules files and component libraries. Fine-tuning is only relevant for vendors building their own builder or for very specific internal DSLs.

State of the art (2026)

• Agentic builders plan, write, run, test and fix in a loop, with integrated database, auth and deploy; most also offer Git sync, visual editing, design import and built-in security scanning (for example Replit's security scanning agent and vendor security scans in Lovable) [5].
• Typical failure modes: missing or wrong row-level security (data readable by any visitor), secrets in client bundles, server actions without authorisation checks, hallucinated or outdated packages, fragile logic after many prompt iterations, and agent actions with too many rights. Documented incidents include an agent deleting a production database during a code freeze in 2025 [6].
• Maintenance gap: apps that nobody understands are hard to patch; "prompt debt" replaces technical debt.
• Standards: OWASP Top 10 and the OWASP guidance for LLM applications give the checklist that scanners use [8].
• Convergence: classic low-code vendors add prompt interfaces while prompt builders add governance (SSO, roles, audit logs, private deployments).

Shared resources & combinations

• Same stack (llm-code + agent-framework): CODE-001 IDE assistants and CODE-002 coding agents share models and sandboxes; CODE-008 (UI from designs) is often the first step; CODE-012 and CODE-013 supply connectors and schema design.
• Quality net: CODE-003 (AI code review) and CODE-004 (test generation) should run on every generated app before production.
• Workflow side: AGENT-002 (back-office automation with n8n/Power Automate) overlaps strongly; many "apps" are better solved as flows.

Effort, cost & KPIs

• Path A: hours to days for a prototype; subscription per seat or credit-based usage, which can grow unpredictably with many prompt iterations. Add effort for review and hosting.
• Path B: 1-3 months to build a governed app factory with templates, CI checks and deployment.
• Path C: 1-3 months plus GPU operations; lower data-protection risk, lower generation quality.
• KPIs: time from idea to working prototype, share of prototypes that reach production, security findings per app before release, number of apps without named owner, ratio of rework prompts, shadow-IT tools replaced.

People & change

Start with the department lead and the future end-users, because they define the process and test the result. Involve IT and IT security before the first deployment: hosting, login, backups, secrets and security scans for generated code (GUIDE-013). Management decides on scope and the AI policy (GUIDE-007) so that "shadow apps" are avoided. DPO and legal/compliance check the data flows and vendor terms (GUIDE-005, GUIDE-010).

Works council: depends. Apps for internal processes may log user actions or evaluate work, which is objectively suited to monitoring under §87(1) no. 6 BetrVG; §90(1) no. 3 requires timely information when work processes are designed with AI. Plan an early talk and an agreement on logging. Public sector: staff council.

Data protection: personal data in apps (customers, employees) needs a legal basis, an AVV (Art. 28 GDPR) with the builder vendor, and a DPIA if employee or sensitive data is evaluated.

AI literacy: support citizen developers with training on testing, security basics and limits of generated code (GUIDE-006). Typical concerns: IT fears unmaintainable apps, staff fear replacement. Address with an app register, a named owner per app and IT review before productive use. Pilot with one small tool and a motivated team (GUIDE-009, GUIDE-008); humans approve what goes live.

Risks, regulation & compliance

• EU AI Act: the builder itself is normally minimal risk, with AI literacy duties (Art. 4) for staff using it [9]. The classification follows the generated app: an app that screens applicants, scores credit or manages critical infrastructure can be high-risk (Annex III), and one with chat or generated content has transparency duties (Art. 50).
• GDPR: do not paste personal data into prompts without a DPA; generated apps that store personal data need records of processing, privacy by design (Art. 25), security of processing (Art. 32) and a DPIA where required. Missing access rules can constitute a reportable personal-data breach (Art. 33).
• Cyber Resilience Act and product liability: apps sold or distributed as products can fall under the CRA; the new Product Liability Directive covers software.
• Licensing and IP: generated code may resemble open-source code; use licence scanning and clarify IP terms in vendor contracts.
• Mitigations: register every AI-built app with owner and data class; allow only synthetic data in prototypes; mandatory security review, RLS/authorisation tests and secret scanning before production; least-privilege agent credentials; no agent access to production databases; backups and rollback; SSO through the company identity provider.

Getting started

1. Write a short policy: what may be built (internal, no personal data in prototypes) and what needs IT review.
2. Pick one tool class from Path A and run a 2-week pilot with 3 real use cases, using synthetic or anonymised data.
3. Create a company template (design system, auth, logging) and a pre-release checklist covering RLS, secrets and dependencies.
4. Connect Git, CI, SAST and secret scanning; make deployment to production go through IT.
5. Track KPIs and decide per app: keep as low-code, hand over to developers (CODE-001/002), or retire.

Sources

1. Wikipedia: Vibe coding (term origin, Karpathy 2025) - https://en.wikipedia.org/wiki/Vibe_coding
2. Lovable documentation and security overview - https://docs.lovable.dev
3. Microsoft Learn: Overview of Copilot in Power Apps - https://learn.microsoft.com/power-apps/maker/canvas-apps/ai-overview
4. Supabase docs: Row Level Security - https://supabase.com/docs/guides/database/postgres/row-level-security
5. State of Vibe-Coded Security Q2 2026 (vendor scanner report, indicative) - https://securityscanner.dev/reports/2026-q2
6. Vibe-coded app data exposure patterns tracker (secondary) - https://pranava0x0.github.io/vibe-coding-security/advisories/ongoing-vibe-platform-exposure.html
7. bolt.diy open-source project - https://github.com/stackblitz-labs/bolt.diy
8. OWASP Top 10 - https://owasp.org/www-project-top-ten/
9. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj