BlazeApp turns your instructions into a working web application, then refines it with you through conversation. Describe what you want in plain language and get a live, working app in minutes.
Sign up with your email or connect via GitHub or Google. Every new account comes with free AI credits so you can start building right away.
From the Dashboard, click New Project and give it a name — something like my-landing-page or expense-tracker. That's all you need to get started.
Open your project and describe the app you want in the build text area. Write in plain language — for example: "Build a personal finance dashboard with monthly spending charts, a transaction list, and a dark color scheme." Click Submit Build and BlazeApp's AI generates the code, runs the build pipeline, and gives you a live preview.
Each build is a new version of your app. Submit follow-up builds to refine the layout, add features, fix bugs, or change the design. BlazeApp keeps your full build history so you can always see what changed.
Your prompt is the only instruction BlazeApp's AI receives. The clearer and more specific it is, the closer the first build will be to what you have in mind. This guide covers how to write prompts that produce great results — and how to avoid the common mistakes that lead to generic or incorrect output.
Describe your app the way a real user would experience it — what they can see, what they can do, and what happens when they do it. Do not describe the technical implementation. BlazeApp handles architecture, databases, APIs, and deployment automatically. Mentioning those details rarely improves the result and can mislead the AI into making incorrect assumptions.
Good: "I want an app where I can track my daily tasks. I can add a task with a title and due date, mark it done, and see all my incomplete tasks at the top."
Avoid: "Build a task manager with a specific server framework, a specific database, named tables, and a frontend that fetches a hardcoded endpoint."
The second prompt sounds more precise but it constrains the AI to specific implementation choices that may conflict with how BlazeApp works internally — resulting in bugs or build failures.
Cover these four things and you'll give the AI everything it needs:
1. What the app is for — One sentence on the purpose. "Track game scores for a group of friends" or "Manage client invoices for a freelance business."
2. Who the users are — Is this a single-user personal tool? A shared space for a group? A multi-user product where each person has a private account? This determines whether the AI adds authentication.
3. The core features — List the main things users can do. Be specific about data: "add a player with a name", "log a score for a session", "see a leaderboard ranked by total points."
4. How data should behave — If it needs to persist between page refreshes or across users, say so: "scores should persist when I refresh" or "each user should only see their own entries."
Avoid mentioning implementation details — the AI knows how to build apps on this platform and these details can cause conflicts:
Don't mention: exact frameworks, named endpoints, database schemas, table names, component-level styling, package choices, or deployment configuration.
Don't say: "use localStorage" unless you explicitly want a lightweight preview-only experience. If you need durable live data, describe the product behavior instead: "bookings should persist" or "customers should keep their saved orders."
BlazeApp automatically decides whether to add user accounts based on what your prompt implies. You don't need to configure anything — just describe your app naturally:
Auth is added when your prompt includes signals like:
"sign up", "log in", "my account", "each user only sees their own", "personal history", "private data"
Auth is skipped for shared or public apps:
"anyone can add data", "shared leaderboard for a group of friends", "public scoreboard"
For example: "I want to track game scores for a group of friends. Anyone can add a player and log scores — no login needed. Show a leaderboard of overall winners." — This builds a public, shared app with no login.
Compare with: "I want to track my personal game scores. I need to sign up and log in — each user should only see their own scores and history." — This builds a fully authenticated app where every route is protected and data is private per user.
❌ Too vague:
"Build a leaderboard app."
The AI doesn't know what game, what data to track, who can add scores, or how winners are ranked. You'll get a generic result that probably needs several follow-up builds to get right.
✅ Clear and specific:
"I want an app to track game scores for a group of friends. We can add players by name, log scores for each game session, and see a leaderboard showing who's winning overall. Scores should persist when I refresh the page."
This tells the AI exactly what data exists (players, sessions, scores), what actions are available, and what the output looks like (a ranked leaderboard). The result will be much closer to what you want on the first build.
❌ Over-specified with technical details:
"Build a task manager with a specific backend framework, ORM, database schema, auth implementation, and frontend state library."
The platform already chooses the implementation path for each app. Locking the build to specific packages usually makes the result slower to generate and more brittle to maintain.
✅ Same app described from the user's perspective:
"I want a personal task manager. I need to sign up and log in. I can add tasks with a title, priority, and due date. I can mark tasks complete and filter by status. Only I can see my own tasks."
You don't need to describe everything in the first prompt. Start with the core functionality and iterate:
First build: "A score tracker for a group of friends — add players, log scores per session, view a leaderboard."
Follow-up: "Add a chart on the leaderboard page showing each player's score trend over the last 10 sessions."
Follow-up: "On the session detail page, show the winner highlighted in gold and add a confetti animation when the page loads."
Follow-up builds read the existing code and layer changes on top. Each build is versioned so you can always see what changed and roll back if needed.
The build system is the core of BlazeApp. You describe what you want, and the AI turns your words into a working application — no code required.
When you submit a build, BlazeApp's AI reads your instructions along with the project's current code. It generates or modifies files, validates the result, and produces a versioned snapshot you can preview immediately.
Describe what your app does from a user's perspective — what they can see and do — rather than how it should be built technically. The more specific you are about features and user flows, the better the output. See the Writing Prompts section for detailed guidance, examples, and auth patterns.
Builds progress through stages such as submitted, building, and ready or failed. Preview builds finish faster for iteration. Publish builds can take longer because they prepare the live app and any durable infrastructure it needs.
Every build is saved. You can search and filter your build history by status, browse past instructions, and see how your app evolved over time. If a build fails, the error details are shown so you know what to adjust in your next prompt.
BlazeApp supports both Preview and Publish workflows for hosted apps, plus a Self-managed mode if you want to deploy the code on your own infrastructure.
Preview builds are optimized for speed. BlazeApp gives you a working version quickly so you can validate the design, flows, and overall behavior before you commit to the live app.
When you click Publish, BlazeApp promotes the latest ready preview into the live app. That includes assigning a subdomain such as your-app.blazeapp.dev, and starting the managed runtime for your app.
In self-managed mode, BlazeApp generates the code and pushes it to your GitHub repository. You handle deployment on your own infrastructure using your existing CI/CD pipeline. Connect your repo URL and default branch when creating the project.
You can keep iterating in preview as long as you want and publish again when the app is ready. For hosted apps, you can also roll back to a previous deployment from the app's Deployments tab if something goes wrong.
Hosted apps come with built-in management: configure memory and region, set environment variables (secrets), manage domains, and view application logs — all from the app detail page.
Every BlazeApp application gets a fully managed Neon Postgres database automatically — no setup, no upgrade steps, and no configuration required. Postgres is the default and only database for all apps on the platform.
When you create a project, BlazeApp provisions a Neon-managed Postgres instance for it. Your app's code is automatically configured with the connection credentials. There is nothing to install or connect manually.
Preview builds connect to your Postgres database so you can test with real data flows. When you publish, the same database backs your live app — there is no migration or data-source switch between preview and production.
You can inspect and manage your Postgres data from the Database tab on your app's detail page. This includes browsing tables, running queries, and monitoring connection usage.
Hosted apps get a free .blazeapp.dev subdomain by default. You can also connect your own custom domain for a branded experience.
Navigate to your app's Domains tab and add your domain name (e.g. app.yoursite.com). BlazeApp provides a DNS target — typically a CNAME record — that you need to add at your domain registrar.
After adding the DNS records, BlazeApp checks for propagation automatically. This usually takes a few minutes but can take up to 48 hours depending on your DNS provider. The domain status updates from pending to verifying to active as verification completes.
BlazeApp provisions a free SSL certificate automatically. HTTPS is enforced for all custom domains. No manual certificate management is needed.
BlazeApp uses a credit-based billing model. Every plan includes a monthly allocation of AI credits that are consumed when you submit builds.
Free — 5 credits/month. Great for trying things out.
Starter — 25 credits/month. For solo builders shipping real projects.
Pro — 75 credits/month. For power users and freelancers.
Team — 200 credits/month. For teams with shared billing and collaboration features.
Each build that involves AI code generation costs credits. The exact amount depends on the complexity of the prompt and the size of the generated output. Simple refinements cost less than full-app scaffolding. Your balance also tracks daily and weekly limits to prevent accidental overuse.
Track your credit balance and usage from Settings > Billing. You'll see your current balance, daily/weekly/monthly limits, and a summary of total builds, credits used, and AI tokens consumed.
You can upgrade your plan at any time from Settings. The new credit allocation takes effect immediately. Unused credits from the current billing cycle do not roll over.