Skip to content
Bloom
Open the dashboard

The dashboard signs in with Google.

Public Beta

Your next product starts as a conversation

Bloom is an AI Product Owner: tell it what you want to build and it interviews you, writes the PRD, plans milestones, files the GitHub issues, and reviews every pull request - keeping you the approver from first message to shipped software.

The dashboard signs in with Google.

New project - via Telegram or the web dashboard

  1. You: I want a booking page for my pottery classes.

  2. Bloom: Let's shape it. Who books today, and what should the first version handle?

  3. You: Two class types. Card payments can wait.

  4. Bloom: Noted - payments deferred and recorded as an explicit assumption in the PRD.

PRD draft ready - awaiting your approval
How Bloom interviews: open questions are asked, deferred choices are recorded as explicit assumptions in the PRD.

What a project leaves behind

Not slideware. These are the artifacts Bloom produces for every project, in the tools you already use.

  1. PRD

    PRD.md - draft for your approval

    • Objective - online booking for pottery classes
    • Target users - returning students
    • Success criteria - a class booked end to end
    • Assumption - card payments deferred

    A living PRD. Bloom interviews you, drafts it, and revises it as you talk. Nothing is built until you approve it in plain language.

  2. Plan

    Milestone plan - M1: MVP

    • Booking form - acceptance criteria, complexity
    • Class schedule page - depends on booking form
    • Deployment pipeline - in the MVP milestone
    • Dependency graph validated - no cycles

    A milestone plan with acceptance criteria, MoSCoW priorities, validated dependencies - and a deployment ticket in the MVP milestone, always.

  3. Studies

    UI design studies - pick a direction

    • Design options rendered side by side
    • Desktop and mobile frames for each option
    • Your pick gates the UI work

    For UI surfaces, Bloom produces design studies made for your project - and you choose the direction before implementation begins.

  4. Issues

    GitHub - issue #12

    • Implement booking form
    • Acceptance criteria - 3 items
    • Milestone M1 - depends on #11
    • Synced from the approved plan

    The plan syncs to GitHub as real milestones and issues. From that point, GitHub is the source of truth for what is actually done.

  5. PRs

    Pull request #18 - feat: booking form

    • Reviewed against acceptance criteria
    • Changes requested - then fixed
    • Re-reviewed - merged
    • Review loop run by Bloom

    Bloom's AI swarm - or your own engineers - implements each ticket; Bloom reviews every pull request and only passing work merges.

  6. Deploy

    Deployment - awaiting you

    • Pipeline scaffolded as a real CI workflow
    • Your credentials - entered privately, never in the repo
    • status: awaiting-client - approve to go live

    The pipeline parks for your credentials and your go-live approval. You ship when you say so, and Bloom messages you the live URL.

You stay the approver

  • The PRD

    Approved by you, in chat, before any code is written.

  • Every plan revision

    Changes come back as a computed delta against the plan - applied only after you re-approve.

  • Go-live

    Deploys wait for your credentials and your explicit approval. Bloom then messages you the live URL.

What Bloom won't do

  • Replace your judgment

    You approve the PRD, every plan revision, and every deliverable. Bloom never removes the human from the loop.

  • Decide architecture alone

    Significant technical decisions come to you as options with tradeoffs - Bloom never locks in an architecture without your sign-off.

  • Code ad-hoc

    Bloom implements planned, reviewed tickets - it is not a general coding assistant that writes code from chat requests.

Start with a sentence

Open the dashboard, describe what you want to build, and see how far one conversation goes.

The dashboard signs in with Google.