Skip to main content

What is Bloom?

Bloom is an AI Product Owner that turns conversations into software projects.

Instead of juggling product docs, project boards, GitHub issues, and PR reviews, you chat with Bloom - through Telegram or the web dashboard. Bloom interviews you to discover requirements, maintains a living Product Requirements Document (PRD), plans milestones, manages GitHub issues, coordinates engineering work, reviews the resulting pull requests, and keeps you informed across the whole software development lifecycle. It behaves like an experienced Product Owner with the technical know-how of a Lead Engineer - and by default it also builds: delegated tickets are implemented by Bloom's own AI engineering swarm, which opens real pull requests that Bloom then reviews.

This page condenses the Product Requirements Document (the source of truth for what Bloom does) and the repository README. When they disagree with this summary, they win.

Who it is for​

Solo founders, indie hackers, and small teams who want to go from an idea to shipped software without personally shepherding product docs, boards, issues, and reviews across half a dozen tools.

What Bloom does​

A project's life with Bloom, end to end (the Core workflows guide walks each step against the current app):

  1. You start a conversation - a new chat is a new project.
  2. Bloom interviews you until the essential facets (objective, target users, core features, success criteria) are covered, and drafts a PRD it keeps refining as you talk.
  3. You approve the PRD; Bloom freezes that revision and commits it to the project repository as PRD.md. Projects can start greenfield (Bloom creates the repository) or adopt an existing repository.
  4. Bloom plans milestones and tickets - including design work and a guaranteed MVP deployment ticket - and syncs them to GitHub as milestones and issues. GitHub stays the source of truth for engineering execution.
  5. Bloom delegates ready tickets, tracks status through coordination labels, and drives the review -> fix -> re-review loop on every pull request, merging only work that passes review against the ticket's acceptance criteria.
  6. Bloom escalates to you only when a decision or unblocking genuinely needs a human, and proactively reports progress, completed milestones, and anything awaiting your input.
  7. The plan stays alive after approval: describe a change in chat and Bloom drafts a new PRD revision, computes the delta against the current plan, and reconciles GitHub once you re-approve.

What Bloom will not do​

Bloom is deliberately not a general coding assistant, and it keeps a human in the loop:

  • You approve the PRD, every plan revision, and every client-facing deliverable; every PR is reviewed against acceptance criteria before merge.
  • Bloom does not make autonomous architecture decisions.
  • Bloom does not run deployments or production infrastructure for your project - it plans and scaffolds the deployment pipeline, then parks it for your credentials and go-live approval.
  • One project maps to one repository.
  • Its swarm implements planned, reviewed tickets, not ad-hoc "write me a function" chat requests - and you can substitute your own engineers or swarm for Bloom's.

The surfaces​

  • Telegram - chat with Bloom from the bot, gated to registered, linked accounts. One Telegram chat multiplexes all your projects through an active-project pointer.
  • Web dashboard - a chat-app workspace: sign in with Google, projects as conversations in a sidebar, and a per-project Project View with tab-routed Chat, Details, Workflow (the live SDLC graph), Timeline, Credentials, and Settings. Web chat and Telegram drive the same per-project conversation history.
  • Admin console - a separate, grant-gated operations surface for Bloom's operators, not for project owners. See Admin console basics.

How it works, in one paragraph​

Bloom's SDLC process is defined as data: a stack-agnostic workflow spec describes the lifecycle as a graph of typed nodes over shared state, and a small built-in interpreter runs it inside a Node + TypeScript + Express backend. Integrations are seams: a pluggable LLM provider (Anthropic by default, with an offline fake provider for development), a platform-neutral VCS layer speaking to GitHub (and GitLab) through short-lived App credentials, and a pluggable engineering engine behind the swarm. The architecture overview has the real map.

Where next​