How to Choose a Backend for an AI-Generated App

Step 1: inventory the backend jobs

List every capability the frontend expects:

• persistent records and relationships;
• account registration and recovery;
• authorization by owner, role or organization;
• file uploads and downloads;
• server-side validation and privileged actions;
• scheduled or event-driven functions;
• transactional email;
• payments and webhooks;
• search or vector retrieval;
• audit logs, analytics and deletion.

An AI generator may silently choose different providers for these jobs. Create one architecture record showing which service owns each responsibility.

Step 2: draw the data model

Use a relational model when constraints, joins, transactions and reporting are central. Use a document model when data is naturally retrieved as independent aggregates and known client query paths dominate. Use a reactive backend when live query updates and backend functions are first-class requirements.

For a client portal, write the entities before code: users, organizations, memberships, projects, messages and files. Mark ownership and deletion behavior. If the schema cannot express who owns a record, authorization will be fragile.

Step 3: write the access matrix

Authentication answers “who is this?” Authorization answers “what can this identity do?” Write the policy as a table before selecting syntax.

Translate the matrix into RLS policies, Security Rules or backend functions. Test every denied cell, not only allowed actions.

Step 4: decide where trusted code runs

Public client keys are not the same as privileged secrets. Some platforms intentionally expose a project URL and limited client key because row or document rules enforce access. Service-role, admin and cloud credentials bypass those protections and must remain in a trusted server or function.

Inspect the built frontend bundle and repository history for secrets. If a privileged key was pasted into an AI chat, public variable, screenshot or commit, revoke and rotate it rather than merely deleting the visible line.

Step 5: evaluate files, email and external APIs

Files need content-type validation, size limits, authorization, malware policy, retention and signed-download behavior. Email needs an authenticated sending domain, consent for marketing messages, transactional templates, bounce handling and secret protection. External APIs need server-side secrets, rate limits, webhook verification and retry design.

Do not reuse a marketing-consent checkbox to justify transactional or unrelated messages. Our consent-based Brevo newsletter guide covers the marketing side separately.

Step 6: define recovery and portability

Set measurable requirements:

• acceptable data loss after failure;
• acceptable time to restore;
• backup frequency and retention;
• who can initiate and verify recovery;
• data, auth-user and file export formats;
• destination used for a migration rehearsal;
• behavior after subscription or hosting expiry.

Run a restore with synthetic data. Check record counts, relationships, timestamps, files and permissions. A ZIP containing source code is not a database backup.

This is especially important in integrated builders. Hostinger's current Horizons documentation, for example, says its integrated backend has no direct data-export tool even though project code can be exported separately.

Step 7: model costs and failure thresholds

Estimate at least three scenarios:

1. prototype: developers and test data;
2. expected: normal users and average activity;
3. stress: traffic spike, loop or compromised key.

Include database operations, compute, storage, history, egress, functions, authentication method, email and logs. Determine whether the vendor offers an alert, soft cap or hard disable threshold. They are not equivalent.

Convex documents per-deployment warning and disable limits. Neon documents maximum autoscaling and scale-to-zero controls. Firebase and other cloud platforms provide budgets and alerts, but a budget alert may not stop spend automatically. Know the exact behavior.

Step 8: compare the operating model

Use the shortlist deliberately:

• Supabase: Postgres plus integrated auth/storage; requires tested RLS.
• Firebase: document/realtime ecosystem and Google services; requires Security Rules and Cloud billing discipline.
• Appwrite: packaged backend with cloud and self-hosting choices; requires either cloud-limit planning or infrastructure ownership.
• Neon: focused serverless Postgres; pair with suitable auth, files and functions.
• Convex: reactive database and TypeScript functions; understand platform-specific data and resource metering.
• Integrated builder backend: lowest initial setup, but verify export, control and lifecycle before storing important data.

Read the backend platform comparison for current official plan references.

Step 9: build one vertical slice

Build a complete, narrow feature: sign up, create one record, view only the correct user's record, update it and delete it. Add logging and recovery. Then test:

• direct API calls without the UI;
• modified user and record identifiers;
• two simultaneous accounts;
• expired credentials;
• invalid and oversized input;
• network retry and duplicate submission;
• provider limit reached;
• backup restoration.

Only after the slice passes should the data model expand.

Step 10: document ownership

Record who owns the provider account, billing, domain, email sender, backups, security updates and incident response. Keep credentials in an approved password manager and secrets system. A client project should not depend permanently on a freelancer's personal account.

Common mistakes

• accepting public read/write rules to make a demo work;
• shipping a service-role key in the browser;
• using one user role for every account;
• collecting fields without a retention purpose;
• assuming an AI-generated database migration is reversible;
• enabling pay-as-you-go without alerts or limits;
• calling a source-code export a complete backup;
• launching without deletion and recovery tests.

Frequently asked questions

Official sources reviewed

The framework references official Supabase Auth, Firestore Security Rules, Appwrite Auth, Neon pricing controls, Convex usage limits and Hostinger Horizons integrated-backend guidance. Last checked 2026-08-01.