b2c-app-builder

B2C App Builder is an MIT-licensed, open-source project from Clueless Creations that frames consumer-app business building as a set of reusable primitives for AI agents. The README uses a restaurant-kitchen metaphor: stations are the responsibilities every consumer-app business shares and do not change with the app; capabilities define what each station must produce; providers implement them; recipes arrange the work into creation and operating loops; and selected knowledge is the mise en place that helps the agent decide well. The user is described as the executive chef, choosing the opportunity and product and setting the bar. The project states that skills and sourced knowledge alone leave open which job comes next, what the last job decided, which provider runs it, whether the result holds up, and what happens on failure. Capabilities, recipes, planning, bounded execution, evidence and recovery are presented as the answers, keeping several specialised agents and providers working on one business rather than disconnected pieces. Users supply their own agent and model, infrastructure, provider accounts and credentials, and execution environment; the method itself ships in full under the MIT licence. Covered areas, mapped to stations, include opportunity research (users, competitors, demand, a defensible product hypothesis), product definition (promise, first value, core loop, scope, success measures), experience (identity, onboarding, interaction, motion, accessible states), engineering (native and web surfaces with explicit contracts and runtime verification), revenue and growth (subscriptions, acquisition, funnels, attribution, lifecycle), and learning and operations (inspecting evidence, planning improvements, supporting users, maintaining the business). Five primitives are described: a Capability is a business responsibility with operation semantics and acceptance criteria; a Provider is an implementation of specific operations with declared support and limits; a Recipe is a configurable creation or operating loop; Knowledge is sourced guidance loaded in bounded amounts; Evidence is observations tied to a claim, artifact and environment. The README stresses that swapping a provider does not redefine what an entitlement or activation means, that a new recipe reuses the same execution and evidence machinery, and that builders keep control of product, brand, business model and operating loop. Getting started requires Node.js 24. `npm install -g b2c-app-builder` followed by `b2c setup` creates the local workspace registry and prints the MCP registration command for Claude Code, Cursor and Codex. A portable form needs no install (`claude mcp add --scope user b2c-app-builder -- npx -y -p b2c-app-builder b2c-app-builder-mcp`). From source, the repository is cloned and run with `npm ci` and `npm run setup`, which runs `npm link`. Initial commands include `b2c catalog --json` to list public capabilities, providers and recipes, and `b2c compose --config contracts/public-api/examples/subscription-app.json --json` to preview a composition without changing anything; the preview resolves each operation to a provider and lists blockers, and the declaration preview reports `canApply: false`. Activating an installed package recipe uses separate revision-checked composition plan and activation commands. For a new business, `b2c business-create` registers a planning workspace with a workspace name, absolute directory, product name, hypothesis and mandate; the target must be empty or absent, and existing workspaces can be adopted with `b2c workspaces register`. Status and plan commands follow. The described lifecycle creates a planning workspace, initializes the accepted product with a 99-workflow complete-business recipe, plans eligible work, and runs bounded sessions through the executor, with evidence reports separating current acceptance from missing or stale proof and interrupted requests closing through revision-checked recovery. Compositions bind a recipe to a target and can override the provider for a single operation via YAML (`apiVersion: b2c/v1`, recipe id/version, target platform and runtime, and bindings mapping an operation to a provider version and connection). Connection values are names of separately managed connections, never credentials. Mobile app operation is treated as its own capability: agents walk customer journeys, reproduce bugs, review design and capture screenshots or demo footage, with the agent host's native simulator tooling as the default provider and alternatives such as MobAI selectable. A Tuck example is cited as showing real app and web captures including trip planning, packing and a landing page, with gallery links to capture provenance and verification limits. A status table distinguishes declared support from working implementation. Implemented items include source-backed knowledge, the workflow catalog, the CLI and local MCP; workspace creation, planning, bounded execution, review and evidence; `b2c/v1` discovery, composition preview and business status with shared CLI/MCP schemas and contract tests; and local package import and composition activation with content pins, preview checks and recovery. Provider execution routes are explicit host adapters, and declarations alone never execute. A single complete, benchmark-quality consumer business is listed as the next milestone, while comparable market reports are implemented but the observed multi-business milestone remains unproven. On contribution, the project invites better consumer-app references, operation contracts, providers and recipes, noting that most contributions add a way to run a station rather than a new station, and that first-party and community extensions pass the same conformance suite. An AGENTS.md file routes agent work by scope to `b2c-app-builder`, `b2c-contributor` or `b2c-maintainer` skills. Third-party credits and legal notices are rendered from upstream manifests under `catalog/upstreams`.