Bloom: The Meta-System for Compounding Product Development

Most product scaffolding is accidental.

You copy from the last project, carry forward whatever worked, leave behind whatever didn't, and accumulate a slightly different setup every time. After five projects, your sixth starts with a pile of conventions that belong to five different versions of how you thought about building software.

I wanted something different. I wanted each new product to inherit the best thinking from every product before it — deliberately, not by copy-paste. I wanted the decisions to compound.

So I built Bloom.

What Bloom Is

Bloom is a meta-system for product development. Not a framework you extend — a system you mount. It's five independent git repositories that attach to any product as submodules under .bloom/, giving you structure, decisions, tools, and habits without the noise.

The core idea is composition over inheritance. Each repo is independent and versionable. A product mounts what it needs. When the system improves — better stack defaults, sharper session habits, cleaner templates — every future product inherits those improvements automatically.

The decisions live in the system. Not in your head. Not in your last project's README.

The Stack

Bloom has two profiles. The default is lite:

• •Next.js 15 (App Router, Turbopack)
• •React 19 + TypeScript 5.8
• •Supabase (auth + Postgres)
• •Tailwind 4 + shadcn/ui + Radix
• •pnpm
• •Vitest + Playwright
• •Vercel

The lite template isn't a config file — it's a working starter. Auth pages, dashboard route group, Supabase SSR helpers, proxy middleware, shadcn components, e2e test spec. Wired together and tested.

The philosophy is time-to-deploy over portability. Default to lite. Graduate to the full Nx/NestJS profile only when there's a real reason to own more infrastructure.

Using It: Scaffolding Kingmaker

This week I started a new product called Kingmaker — an AI coaching tool that helps people follow through on their goals. The concept: you bring a coaching plan, and the AI checks in with you, surfaces your commitments, holds you accountable, and makes drift harder than progress.

Kingmaker already existed as a git repo (started the night before with a mission statement). So instead of bloom-init, I mounted the submodules manually:

BLOOM_SOURCE="file:///Users/me/Projects/Active/Bloom"
git -c protocol.file.allow=always submodule add "$BLOOM_SOURCE/soul" .bloom/soul
git -c protocol.file.allow=always submodule add "$BLOOM_SOURCE/idea" .bloom/idea
git -c protocol.file.allow=always submodule add "$BLOOM_SOURCE/stack" .bloom/stack
git -c protocol.file.allow=always submodule add "$BLOOM_SOURCE/shulkerbox" .bloom/shulkerbox

Then scaffolded the docs spine and notes from templates:

for template in intent mission north-star product-surfaces architecture IA-graph; do
  [[ -f ".bloom/idea/templates/${template}.md" ]] && cp ".bloom/idea/templates/${template}.md" "docs/${template}.md"
done
cp -R .bloom/shulkerbox/templates/notes/. notes/

Copied in the lite stack template, installed dependencies, ran the type checker. Clean pass.

For local development: supabase init && supabase start gives you the full Supabase stack running locally in Docker — Postgres, Auth, Storage, Studio at localhost:54323. No cloud account, no credentials to manage during development. When it's time to ship, one command pushes to a hosted project.

From zero to a working Next.js 15 app with Supabase auth, shadcn UI, and passing e2e tests: about 20 minutes.

What You Get for Free

Beyond the running app, Bloom installs a set of habits:

Session continuity. The shulkerbox templates scaffold a notes/ directory — inbox.md, activity-log.md, friction.md, insights.md. Every session ends with a handover note. Every session starts by reading it. You never lose context across sessions, and you never rebuild it from scratch.

Spec-first discipline. The idea templates scaffold your docs spine: intent → mission → north star → product surfaces → architecture → IA. You fill these in before you build. Every task traces back up this chain. If it can't, you probably shouldn't be building it.

Task traceability. Vision → mission → north star → roadmap → tasks. The structure makes this visible and enforces it as habit rather than process.

No-main-commits. The stack installs a pre-commit hook at bootstrap. You always work on branches. Not optional, not something to remember — just how the repo works.

What You Still Have to Build

Bloom is honest about its scope. It's a meta-system, not a product.

For Kingmaker, the product work is still ahead:

• •Coaching data schema — sessions, goals, plan items, commitments, weekly pillars
• •Plan ingestion — an API that parses a coaching document into structured phases and actions
• •AI session loop — Claude as coach, streaming, remembering what you committed to last time
• •Session UI — chat interface, pillar tracker, commitment review at session start

Bloom gets me to zero cleanly and quickly. The product is mine to build. That's the right division of labour.

Is It For You?

Bloom is opinionated. If you disagree with Next.js + Supabase + Vercel as defaults, you'll spend more time deviating than benefiting. The deviation policy is explicit: when you diverge from a stack default, you write an ADR explaining why. Three products deviating on the same concern is a signal to update the stack itself.

The payoff compounds with volume. If you're building one product once, it might feel like overhead. If you're building as a practice — shipping, learning, iterating across products — it starts to feel like leverage. The decisions made in product one become the foundation of product two without copy-paste. The habits transfer. The quality compounds.

That's the design goal: intelligent compounding, not accidental accumulation.

What's Next

Bloom isn't a public package yet. It's been a personal system, increasingly used with clients on consulting work. Kingmaker is the first product I'm building fully in public with it.

The pieces I plan to open up:

• •The bloom-init bootstrap script
• •The stack.yaml contract and lite template
• •The session continuity patterns from shulkerbox

The best way to follow along is to watch Kingmaker get built. The framework reveals itself through the product.

Building something and thinking about how to make the overhead compound rather than accumulate? I'd enjoy that conversation.

What carries forward

• •Composition over inheritance: mount independent, versionable repos rather than copy-paste conventions across projects.
• •The decisions live in the system, not in your head or your last project's README.
• •Session continuity, spec-first discipline, task traceability, and branch hygiene are habits installed by the scaffolding — not processes to remember.
• •Bloom gets you to zero cleanly. The product is yours to build. That's the right division of labour.

Why it belongs here

This is the first public post about Kingmaker — an AI coaching product built with Bloom. It positions the site's engineering and product-building voice alongside the design and leadership work.