The full-stack framework
built for agentic coding

From zero to running in under a minute

npm install -g @bloomneo/bloom

# Web app (React + Express, FBCA routing)
bloom create my-app

# Auth + user management + admin panel
bloom create my-app userapp

# Admin console (userapp + audit log, settings dashboard, 3-tier roles)
bloom create my-app adminapp

# Desktop app (Electron, SQLite, cross-platform)
bloom create my-app desktop-basicapp
bloom create my-app desktop-userapp

# Mobile app (iOS + Android via Capacitor 7)
bloom create my-app mobile-basicapp

Three packages. One framework.

Bloom isn't monolithic. Install the full stack with bloom create, or pull any pillar into an existing project. They're designed to compose but work standalone.

Add a folder. Get a route.

Bloom has one load-bearing convention across every template: Feature-Based Component Architecture. Backend endpoints and frontend pages are auto-discovered by scanning feature folders. No router config to edit, no import list to maintain, no manual registration. Adding functionality = creating files.

# Backend — drop a folder → auto-mounted API route
src/api/features/
└── invoice/
    ├── invoice.route.ts     → /api/invoice
    ├── invoice.service.ts   (business logic; uses appkit)
    └── invoice.types.ts     (shared with frontend)

# Frontend — drop a folder → auto-routed page
src/web/features/
└── invoice/
    ├── pages/
    │   ├── index.tsx        → /invoice
    │   ├── [id].tsx         → /invoice/:id   (dynamic segment)
    │   └── [...path].tsx    → /invoice/*     (catch-all)
    ├── components/          (local to this feature)
    └── services/            (API calls; uses uikit useApi)

Route pattern rules — how file paths become URLs:

Under the hood: the web router uses import.meta.glob('../features/*/pages/**/*.tsx'); the API router scans src/api/features/ at boot. Both are re-discovered on hot reload — no server restart required when you add a feature.

Designed assuming 50%+ of the code is written by an AI

Most frameworks were built for humans, then retro-fitted with an LLM integration post-ChatGPT. Bloom is engineered from day one around the assumption that Claude, Cursor, Copilot and Windsurf are your teammates. Nine concrete places that plays out:

Where Bloom stands vs established frameworks

Closest in scope to T3 Stack or RedwoodJS — not Laravel or NestJS directly. Bloom's differentiator is agentic-first design + cross-platform coverage; its weakness is ecosystem age.

Bloom's bet: runtime llms.txt fetching closes the training-data gap. Agents don't need to have seen Bloom before — the docs ship with the code, version-matched, ready to load into context.

Best fit today: solo developers and small teams (≤10) shipping SaaS with heavy Claude Code / Cursor / Copilot usage, and anyone building cross-platform products (web + desktop + mobile) who doesn't want to stitch three stacks.

Not yet the right fit: 100-engineer enterprise teams where hiring pool and 10-year ecosystem matter more than agentic ergonomics. Use Laravel or NestJS for those.

One framework. Every shippable surface.

Bloom is the scaffolder teams reach for when they need a working stack — not an evening evaluating starters.

• B2B SaaS productsAuth + role-based admin + Prisma in one command. Scaffold with userapp and ship MVP in a weekend.
• Internal admin consolesAudit log, settings editor, dashboard, 3-tier roles — all wired in adminapp out of the box. Add a feature folder and ship.
• Multi-tenant SaaS backendsAppKit's row-level tenant filtering + per-org databases are wired into the userapp template.
• Cross-platform desktop appsdesktop-basicapp / desktop-userapp ship Electron + embedded Express + SQLite. Packages to Windows, macOS, Linux.
• Native mobile (iOS + Android)mobile-basicapp via Capacitor 7. Same React codebase, same UIKit components, native builds on both stores.
• Marketing / content sitesFBCA file-based routing + UIKit PageLayout + themes. Swap the default template's pages for yours.
• AI agent platforms & LLM appsEvery scaffold is AI-ready — docs/ and .claude/skills/ are populated on install so agents extend your app correctly.
• Internal developer portalsDocs site, API explorer, internal status page — FBCA feature folders keep domain boundaries clean.
• CRUD-heavy ops dashboardsInventory, invoicing, ticketing — userapp + a few feature folders, no router config to manage.
• Prototypes that surviveBloom scaffolds production defaults from day one — the prototype doesn't get rewritten when it grows.

The five mistakes Bloom won't let you make twice

These are the only ways to silently break a Bloom project. Memorise them — or point your AI agent at AGENTS.md where they're spelled out line by line.

• ✕Never import { ... } from '@bloomneo/bloom'. Bloom is a CLI, not a runtime library. Nothing ships in node_modules for your app to import. If you're writing that import, you're off the canonical path.
• ✕Never hand-edit the page-router in a scaffolded project. The router auto-discovers features. Add a route = create features/<name>/pages/index.tsx. Don't touch the router file.
• ✕Never overwrite docs/appkit.md / docs/uikit.md. They're regenerated from node_modules on every npm install. Edit the upstream package's llms.txt, not the copy.
• ✕Never bloom create into a non-empty directory. Exits 1 with a conflict error. Use . for the current directory only if it's empty (other than dotfiles).
• ✕Never pin appkit or uikit to latest. Templates pin @bloomneo/appkit@^4.0.0 and @bloomneo/uikit@^2.0.1 for a reason — coordinated majors need a new bloom release.