Guides, templates, and example blueprints for planning AI apps before building with Cursor or Claude Code. Free resources for vibe coders and founders.
How to describe your app idea so blueprint generation captures every integration, scheduler, and AI step.
Read: Writing a Good Bluemoonkey Prompt → Free guidePlain-English picks for frontend, backend, database, auth, AI, and common vendors — when to choose what.
Read: Tools & Frameworks Explained → Free guideStep-by-step: define the problem, map user flows, design architecture, choose your stack, and set checkpoints.
Read: How to Plan an App Before Coding → Free guideA reusable visual template for mapping pages, APIs, databases, AI prompts, and checkpoints before you code.
Read: AI App Blueprint Template → Free guideTurn your blueprint into a structured, build-ready prompt for Cursor Agent mode — then let it build the app.
Read: Cursor App Prompt Template → Free guideThe same structured export for Claude Code’s CLI agent — paste once and let it generate the project files.
Read: Claude Code Prompt Template → Free guideMap architecture on a canvas first, then prompt Cursor or Claude Code with a build-ready blueprint.
Read: Vibe Coding Workflow → Free guideA practical checklist for founders: define the MVP, map architecture, then build with AI coding tools.
Read: MVP App Planning Checklist → Free guidePlain-English tour of frontend, backend, database, APIs, and AI prompts — the five pieces every app needs.
Read: App Architecture for Beginners → Free guideWalk a review-reply app node by node: pages, APIs, database, AI prompts, and human checkpoints.
Read: AI App Architecture Example → Free guideWhat .md, .env, .json, robots.txt, llms.txt, and sitemap.xml are for — and when to add each as a File node.
Read: File Types Guide →Concrete tips from real blueprint generation — name what you mean, and the AI will build the right nodes.
| Vague prompt | Better prompt | Why it works |
|---|---|---|
| “Handle payments” | “Subscribe via Stripe” | Produces a real payment node with webhook verification. Same rule for any third-party service — Gmail, SendGrid, Twilio — name it by name. |
| “Keep users updated” | “Send a summary every morning” | Produces a scheduler node connected to what it triggers. The blueprint has no way to know you need a daily cron job unless you say it. |
| “Use AI to help” | “Summarize unread emails into 3 bullet points” | Produces a real AI prompt node with substance. Mention the task, the input, and the output you expect. |
| Single sentence describing the whole app | “Sign up → connect account → configure → use” | Spelling out the steps helps the blueprint capture the right frontend screens and checkpoint nodes between them — not just a single generic app node. |
| Technical jargon | “When someone leaves a bad review, have AI draft a polite reply for me to approve before it posts” | You don't need technical terms. Plain description is exactly the right level of detail — informal tone, concrete behavior. |
Before generation, Bluemoonkey may also ask who the app is for — that one answer changes how much login and account scaffolding shows up on the canvas.
Stage 0 sometimes asks: Is this app for personal/single-user use, or will other people use it (multi-user product)? It appears when your idea doesn't already make the answer obvious — for example, you haven't mentioned accounts, login, customers, or a SaaS-style product. The point is to stop the generator from quietly turning a solo tool into a full multi-user product (auth gates, OAuth, settings pages, schedulers) when you never asked for that.
| Pick this | When it fits | What the blueprint does |
|---|---|---|
| Just for me (personal tool) | Just for you — no logins, no accounts for other people, simplest possible build. | Skips Auth Gate / login, per-user credential isolation, Settings/account pages, and scheduling unless you explicitly asked for them. Keeps the nodes you named. |
| Other people will use it (multi-user product) | Other people will sign up or log in, need their own data kept separate, or you want to scale it as a real product. | Keeps the fuller shape: auth/login, per-user isolation, and account/settings surfaces when stored user data is implied. |
| Not sure — let AI decide | You haven't decided yet. | Defaults toward the multi-user product shape so auth isn't silently stripped. |
What the architecture preference questions are actually asking — skimmable picks for vibe coders, not a textbook.
This is what people see and click — your website or app screens. The choice shapes how the project folder is organized from day one.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Next.js | A full toolkit for building websites with React (a popular way to make interactive pages). Includes page routing, server endpoints, and deploy helpers in one package. | It expects you to follow its folder layout. Less “anything goes,” more “put things here.” | Best for apps with multiple pages, logins, or anything that needs more security under the hood. |
| React + Vite | React for the screens, plus Vite (a fast starter tool) so the project runs quickly while you build. | You connect more pieces yourself — like page navigation and talking to a server. | Best for a simple, single-page app or a quick prototype. |
| Vue 3 | Another popular way to build interactive screens, with a different coding style than React. | Fewer ready-made AI starter kits than React, so examples online can be thinner. | Best when you prefer Vue’s style, or your idea already assumes a Vue UI. |
| Let AI decide | Bluemoonkey picks a sensible default for your app. | You don’t choose the stack up front — you can change it later. | Best when you just want to start building and figure out the stack later. |
| Other | Any frontend toolkit you type yourself (for example SvelteKit or Angular). | The AI only knows what you write — name the framework clearly. | Best when your preferred UI toolkit isn’t in the list. |
The “behind the scenes” part of your app — saving data, talking to other services, and running the rules users never see. An API is simply how one program asks another program for something.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Express | A simple JavaScript toolkit for building server endpoints (the “API” your screens call). | You assemble more of the project structure yourself than with a bigger all-in-one framework. | Best for apps that need a separate server for logins, payments, jobs, or talking to many outside services. |
| Next.js API Routes | Server endpoints that live inside the same Next.js website project — no second codebase required. | Great when the server work is small; can feel crowded if the backend grows huge. | Best when you chose Next.js and want one project folder for both screens and server logic. |
| FastAPI | A Python toolkit for building those behind-the-scenes endpoints quickly. | Your app may use two languages — Python on the server and JavaScript in the browser. | Best for AI-heavy or data-heavy apps where Python libraries matter. |
| Django REST | A Python toolkit (Django) with ready-made patterns for APIs, admin screens, and structured apps. | More “batteries included” — also more conventions to follow. | Best for larger backend-heavy apps that want a full Python framework, not just a thin API layer. |
| Let AI decide | Matches a backend choice to your app description automatically. | You don’t pick the server toolkit up front. | Best for first drafts when you care about features more than the server toolkit. |
| Other | Any backend toolkit you type yourself (for example NestJS, Hono, or Flask). | The AI only knows what you write — name the tool clearly. | Best when your preferred server toolkit isn’t in the list. |
Where your app remembers things long-term — users, posts, orders, settings. Think of it as the app’s filing cabinet.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| PostgreSQL/Supabase | A solid “tables and rows” database, often hosted with Supabase — a service that also helps with logins and easy data access. | You organize data in related tables. Great for structured info. | Best for apps with accounts, saved user data, or payments. |
| MongoDB | A document-style database — stores info more like flexible folders of JSON than strict tables. | Very flexible, but relationships between data can get messier later. | Best when your data shapes change often or you’re storing nested content. |
| MySQL | A classic tables-and-rows database used by many websites and hosting plans. | Reliable and common; less “modern starter kit” buzz than Supabase. | Best when your host already offers MySQL, or your team already uses it. |
| SQLite | A tiny database that lives as a single file on the server — almost zero setup. | Not ideal when lots of people use the app at once, or when you run many servers. | Best for personal tools, prototypes, demos, or single-user apps. |
| Redis (cache/fast lookup) | An ultra-fast in-memory store — great for temporary data, queues, and quick lookups. | Usually not your only database; data can disappear if you only rely on memory. | Best when you need speed for sessions, rate limits, caches, or job queues. |
| Firebase/Firestore | Google’s hosted database that syncs data quickly to apps (often mobile or realtime). | Tied to Google’s Firebase ecosystem and pricing model. | Best for realtime apps, chat-like updates, or teams already in Firebase. |
| Let AI decide | Picks storage based on whether your idea needs accounts, scale, and so on. | You don’t name a database vendor up front. | Best when you haven’t chosen a host yet and just want a sensible default. |
| Other | Any database you type yourself (for example DynamoDB or PlanetScale). | The AI only knows what you write — name the product clearly. | Best when your preferred database isn’t in the list. |
Only matters if your app uses AI — drafting text, summarizing, chatting, classifying, and similar. An API key is a private password your app uses to call that AI service.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Claude | Anthropic’s Claude models you call over the internet — strong at writing, explaining, and multi-step reasoning. | Separate billing from OpenAI. You’ll need an Anthropic account and API key (a private password for the service). | Best for apps that draft, rewrite, coach, or run agent-style “do this then that” AI steps. |
| OpenAI/GPT | OpenAI’s GPT models you call over the internet — lots of tutorials and code samples online. | Model names and prices change often; you’ll need an OpenAI account and API key. | Best when your idea leans on ChatGPT-style features or you already pay for OpenAI. |
| Gemini | Google’s Gemini models you call over the internet — another mainstream AI option. | Tied to Google Cloud / AI Studio account setup and quotas. | Best when you already use Google Cloud, or you want Gemini specifically. |
| Local/open-source model | An AI model you run yourself (or via an open-source host) instead of Claude/OpenAI/Gemini cloud APIs. | More setup and hardware cost; quality and speed vary widely. | Best when privacy, offline use, or avoiding per-token cloud bills matters most. |
| Let AI decide | The blueprint picks a mainstream provider and a sensible default model. | You don’t lock in a vendor during planning. | Best for a first version — you can swap the API key later without redrawing the whole blueprint. |
| Other | Any AI provider you type yourself (for example Mistral, Groq, or Cohere). | The AI only knows what you write — name the provider clearly. | Best when your preferred model vendor isn’t in the list. |
How people create an account, log in, and stay logged in. Skip this category if nobody signs up.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Supabase Auth | Ready-made email/password and “Sign in with Google”-style logins, bundled with Supabase (often the same place you store data). | You’re leaning into the Supabase ecosystem — simplest when your database is there too. | Best default for new apps that need user accounts and saved data. |
| Clerk | A service that gives you polished login screens and user management without building those forms yourself. | Another paid product to manage — very smooth, but it’s another bill. | Best when login UX matters early and you want sign-up screens working fast. |
| Auth0 | A big identity platform used by larger companies for logins and security rules. | Can feel like overkill for a small side project. | Best for bigger apps, team products, or strict security/compliance needs. |
| Let AI decide | Adds login only if your description implies user accounts. | You don’t pick the login vendor during planning. | Best when you said “users can sign up” but don’t care which login service yet. |
How your app sends automatic emails — welcome notes, password resets, digests, alerts. (Not your personal Gmail inbox.)
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Resend | A modern email-sending service with simple templates your app can trigger. | Another API key (private password) to store — setup is usually quick. | Best for apps that send a modest number of transactional emails (welcome, reset, alerts). |
| SendGrid | A long-running email delivery service used by many businesses. | The dashboard can feel corporate; free tiers have sending limits. | Best when you expect higher email volume, or you already use SendGrid. |
| Let AI decide | Adds an email piece only if your idea mentions notifications or digests. | You don’t name the email vendor yet. | Best when email is a side feature, not the product itself. |
How you charge money — subscriptions, one-off purchases, or checkout. Skip this if the app is free.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Stripe | The usual choice for online cards, checkout, and subscriptions. | You’ll learn webhooks (Stripe pinging your app when a payment succeeds) and a test mode before going live. | Best for SaaS (software you rent monthly), paid plans, or most checkout flows. |
| Lemon Squeezy | A payments company that can act as “merchant of record” — they often handle sales tax paperwork for you. | Less flexible than Stripe for unusual billing setups. | Best for selling digital products as a solo founder who wants less tax admin. |
| Let AI decide | Only adds payments if your description mentions charging users. | You don’t lock a payments vendor during planning. | Best when you said “paid plan” but haven’t picked Stripe vs something else yet. |
For apps that post to Instagram, X, LinkedIn, and similar — or schedule posts for later.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Official platform APIs | Your app talks straight to Meta, X, LinkedIn, etc. through each company’s official interface. | Often needs app approval and has posting limits. Not instant to set up. | Best when posting is core to the product and you need maximum control. |
| Buffer / Hootsuite-style API | A middleman tool that already connected to many social networks; your app talks to them instead. | Monthly cost, and you’re limited to the platforms they support. | Best for a faster first version of “post to my accounts” without fighting each network’s login (OAuth — the “Allow this app” screen) yourself. |
| Let AI decide | The blueprint adds scheduling and publishing pieces from your description. | The exact vendor stays generic until you build. | Best when you described the behavior (“post every morning”) but not which tool. |
Static files on a File node — project files that are not a page, an API, or a database. Pick a type so the AI knows what kind of file to create at the path you set. These options match the File Type dropdown in the inspector. For a deeper walkthrough with examples, read the File Types guide.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Markdown (.md) | A plain text file with simple marks for headings and lists (like a lightweight Word doc for coders). Often used for README guides. | Great for humans to read; not for passwords or secret keys. | Best for project docs, how-to notes, or any guide the AI should write as a .md file. |
| Environment config (.env) | A list of settings as NAME=value lines — usually secret keys and URLs your app reads when it starts. | Real secrets must stay private. Share a blank .env.example template, not your real keys. | Best when the app needs API keys, database URLs, or on/off feature flags. |
| JSON (.json) | A structured text format using braces and quotes that computers love — common for settings and data files. | Very picky about commas and quotes; one typo can break the file. | Best for things like manifest.json, package settings, or structured app config. |
| YAML (.yml / .yaml) | Another structured settings format that uses indentation (spaces) instead of lots of braces — common in deploy and automation tools. | Spacing matters. A wrong indent can break the file. | Best for deploy configs, CI (automated build/test) files, or Docker Compose-style setup files. |
| Plain text (.txt) | A normal text file with no special format rules — just words and line breaks. | No built-in structure; the AI follows whatever you write in notes. | Best for simple lists, dumps, or notes that aren’t Markdown. |
| robots.txt | A small site file that tells search engines (like Google) which pages they’re allowed to crawl. | Bad rules can hide pages you want found — or expose paths you meant to keep private. | Best for any public website that needs basic search-crawler guidance. |
| llms.txt | A markdown-style index at your site root that helps AI tools discover your important pages and docs. | Still new — not every AI tool looks for it yet. | Best when you want Cursor/Claude-style agents to find your product pages and guides easily. |
| sitemap.xml | An XML (a tagged text format) list of your site’s URLs so search engines can find every page. | You need to update it when pages are added or removed. | Best for SEO on multi-page marketing sites or documentation hubs. |
| Config file (generic) | A catch-all for settings files that aren’t JSON, YAML, or .env. | You must say the exact filename and format in the path and notes. | Best for tool-specific settings (for example certain .toml or .ini files) that don’t fit the other rows. |
| Let AI decide | The AI picks a sensible file format from the path and purpose you set. | You don’t lock the format during planning. | Best when you know the file’s job but not which format yet. |
| Other (user-defined) | Any file type you type in yourself when the list doesn’t cover it. | The AI only knows what you write — be specific about the extension and purpose. | Best when you need something uncommon (for example .csv, Dockerfile, or a custom extension). |
What kind of “pause and check” gate a Checkpoint node is. Checkpoints sit between steps so something risky doesn’t happen automatically.
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| Human approval | A person must manually review and approve before the next step runs. | Safer, but slower — someone has to be available. | Best before public posts, customer emails, payments, or anything hard to undo. |
| Automated rule check | Code checks conditions (scores, keywords, limits) and decides pass/fail without a person. | Fast and cheap, but rules can miss edge cases a human would catch. | Best for spam filters, threshold checks, or “only continue if X is true” gates. |
| Scheduled/timed gate | The flow waits for a set time (or schedule) before continuing. | Adds delay on purpose — great for pacing, not for instant actions. | Best for “publish tomorrow morning,” cool-down periods, or digest windows. |
| Let AI decide | Picks a checkpoint style from your app description. | You don’t choose the gate style up front. | Best when you know you need a checkpoint, but not which flavor yet. |
| Other | Any custom gate you describe (for example multi-person approval or a fraud score). | You must explain the rule clearly in notes. | Best when your approval logic doesn’t match the common types. |
What your Admin Panel node is for — the private screens operators use to run the product (not the customer-facing app).
| Option | What it is | Tradeoff in plain English | When to pick it |
|---|---|---|---|
| User management | Tools to view users, reset access, ban accounts, or change roles. | Narrow scope — won’t cover content review or analytics by itself. | Best when operators mainly need to manage who can use the app. |
| Content moderation | Tools to review, approve, edit, or remove user-generated content. | Focused on content quality/safety, not billing or user roles. | Best for apps with posts, reviews, uploads, or AI drafts that need human review. |
| Analytics/monitoring dashboard | Charts and alerts so you can see usage, errors, and whether things are healthy. | Helps you observe the system; it doesn’t replace fixing user or content issues. | Best when you need visibility into traffic, failures, or publish success rates. |
| Full admin suite | All of the above in one admin area — users, content, and monitoring. | More to build and secure; bigger surface area. | Best for real products where operators need the whole control room. |
| Let AI decide | Picks an admin scope from your app description. | You don’t lock the admin feature set during planning. | Best when you know you’ll need an admin area, but not which pieces yet. |
| Other | A custom admin focus you type yourself (for example billing-only or support tickets). | You must spell out what’s in scope in notes. | Best when your ops needs don’t match the common scopes. |
Open your project in Cursor
Open Cursor and create or open your project folder. Starting fresh? Create an empty folder first.
Open Agent chat
Press Ctrl+L (Cmd+L on Mac). Make sure it says Agent not Chat at the top — Agent mode can create and edit files.
Paste your blueprint
Paste the exported prompt. Add at the end:
Build this app exactly as described. Start with database schema and auth, then APIs, then frontend pages.
Let Cursor run
Let it finish completely before asking questions. It may create 10-20 files — that's normal and expected.
Iterate with your blueprint
If something isn't right, go back to Bluemoonkey, click the specific node, copy its description, paste into Cursor: “Fix [component] to match this spec: [paste]”
💡 Pro tip: Save your blueprint JSON — it's your source of truth if Cursor goes off track.
A growing directory of AI tools, APIs and services explained in plain English. Find the right tool for your app — verified pricing, real use cases.
Growing with every blueprint generated
Real app architectures you can fork and build from
AI captions, scheduling, approval gates, and File nodes for README, .env, robots.txt, and llms.txt — 14 nodes ready to export
View blueprint →For dropshippers who waste hours checking prices manually across platforms
View blueprint →For local businesses drowning in Google reviews with no time to reply
View blueprint →For founders who want a weekly newsletter but never have time to write it
View blueprint →For support teams that need to prioritize tickets and draft responses faster
View blueprint →For building an AI-powered habit tracking app with streaks and nudges
View blueprint →For legal teams that need to flag risks and summarize contracts faster
View blueprint →Yes — the canvas, exports, imports, version history, README attachments, reference images, and shared blueprints are all completely free forever. We only charge tokens for AI-powered features: the AI Advisor, blueprint generation, and reverse engineering. You get 10 free tokens when you sign up to try everything out.
Tokens are how we charge for AI usage — the only part that costs us real money to run. 1 token = 1 AI Advisor message or 1 blueprint generation. 5 tokens = 1 codebase analysis. Token packs start from €5 for 60 tokens. Everything else on the platform uses zero tokens.
No. Your blueprints are private by default and stored securely in your account. We cannot see what you're building and we don't share your data with anyone. The only exception is if YOU choose to share a blueprint publicly using the Share feature — that's always your choice, never ours.
You do. 100%. Everything you create on Bluemoonkey belongs to you. We don't claim any rights to your ideas, your architecture, or anything you export. Download your blueprint as JSON anytime and take it with you — no lock-in.
If you can describe your app idea in plain English, you can use Bluemoonkey. Most people have their first blueprint in under 5 minutes. The AI does the heavy lifting — you just describe what you want to build and review what it creates. No technical knowledge required.
Not at all. Bluemoonkey is built for people who build with AI tools like Cursor and Claude Code. You plan the architecture here, export it as a ready-to-use prompt, and your AI coding tool does the building. Think of it as the planning layer before the building layer.
The free tools (canvas, export, import, sharing) keep working normally — tokens only gate the AI features. You can top up anytime with a token pack, or keep using the free features indefinitely.
Yes — export as JSON to save and reimport later, or export as an AI Prompt to paste directly into Cursor, Claude Code, or any AI coding tool. The export is yours to use however you want.
We use Stripe for all payments — one of the most trusted payment processors in the world. We never see or store your card details. Stripe handles everything securely.
Your data is stored in Supabase on EU servers, in compliance with GDPR. We are based in Cork, Ireland and operate under EU data protection law. You can request deletion of your account and all data at any time.