Chapter 05 · Operational Blueprint · 2026-04-25

Product Builder

The Automated Product Factory. Nova AI Ventures’ implementation of the agentic engineering discipline (per §02).

Product Builder takes an idea and produces a validated, build-ready state where agentic software engineering (per §02 sections 2-5) can be triggered. This is the factory floor — not a backlog, not a dashboard, not project management.

1. What Product Builder IS

🏭 PRODUCT FACTORY · THE MACHINE
  • Automated pipeline — takes raw idea, produces build-ready product state
  • Factory floor — not a product-on-shelf; Nova AI Ventures’ internal machine
  • The dark factory reference point — Nova AI Ventures’ concrete implementation of Willison’s pattern (§02 section 4)
  • Input: idea + business line + sponsor
  • Output: product in G4 ready state — infra validated · design set · engineering plan ready · AI Management-Suite has briefings

What Product Builder is NOT

  • ❌ Backlog tool (Jira / Notion) — nope
  • ❌ Project management dashboard — nope, it actually CREATES infrastructure
  • ❌ Product-on-shelf for external sale — nope, Nova AI Ventures’ internal factory
    • (not to be confused with Line 04 AI Management Suite, which IS a productized offering)
  • ❌ Template generator — nope, validates end-to-end before handoff

2. The 7-Stage Automated Pipeline

What Product Builder does automatically when we create a new product:

🎨 VISUAL CONCEPT · PRODUCT CREATION FLOW
Phase 0 · Pre-Builder

Loose inputs — anything triggers the Builder

We don’t need all — one signal is enough. The rest fills in during Product Builder.

💡

Idea

In head or in notes

✏️

Wireframes

Initial flow sketches

📊

Pitch Deck

First business thesis

🔧

POC

Vibe-coded quick test

↓
🚀
The Pivot Moment

Launch Product Builder

product-builder.nova-labs.ai / new · slug: naiv-<product>
Product Builder scaffolds entire family immediately — 11 folders initialized simultaneously.
↓
7-Stage Automated Pipeline
# Stage What happens
Stage 01 Idea Extraction Captures raw idea + sponsor + business line · decomposes into modules · extracts requirements
Stage 02 Technical Validation Validates all APIs · calls Nova AI Stack to confirm feasibility · identifies LLM calls + usage patterns
Stage 03 Infrastructure Setup (auto-provisioning) API keys · CLIs (Google, RAG, LiteLLM) · subdomain <product>.dev.nova-labs.ai · database · Google auth · RAG system (Vertex AI)
Stage 04 Design Generation Disk design (data model) · DB schema · UX/UI · wireframes populated to product-wireframes/ · branding populated to product-branding/ (via MCP Stitch + Claude Code)
Stage 05 Engineering Plan LLM calls mapped · real working test suite scaffolded · delivery plan · security tests · acceptance criteria
Stage 06 AI Management-Suite Handoff Briefing packages for Dexter · Vera · Ada · Mira · Iris · (future Luna Pixel)
Stage 07 Handoff State Idea VALIDATED · backlog READY · APIs WORKING · CLIs WORKING · delivery plan SET · security READY · agent briefings DISTRIBUTED

Handoff State definitions (Stage 7)

  • VALIDATED — idea passed Technical Validation + 7-field POC template + founder consensus
  • WORKING — APIs verified · CLIs connecting · subdomain live · database operational
  • READY — engineering plan distributed · test suite scaffolded · delivery plan set
  • DISTRIBUTED — agent briefings delivered to Dexter · Vera · Ada · Mira · Iris · design tooling configured

After stage 7 → agentic software engineering kicks in (trio Ada / Dexter / Vera — wave-based delivery, see section 7 below).

3. Product Family Folder Structure · naiv-<product>/

📁 FAMILY STRUCTURE · 11 FOLDERS

Each product gets a dedicated folder with 11 top-level subfolders. Product Builder scaffolds all of them from day 1.

3.1 The 11 folders

Phase 1 · SPEC “What are we building, for whom, why?”
01 overview
Panel · idea · sponsor · business line · metadata
02 product-poc
Real working POC (optional, sometimes)
03 product-wireframes
UI wireframes (when needed)
Phase 2 · BRAND “How does it look, feel, speak?”
04 product-branding
Logo · CSS theme · tone · identity. Single source of truth for styling.
05 product-pitch-deck
3 HTML decks: internal (mandatory) · operator · investor
06 product-marketing-assets
Social · store assets · email templates · one-pagers · ad creatives
Phase 3 · BUILD “Ship the MVP.”
07 product-app
MVP app (staging repo + master/main repo, both in Nova AI Ventures)
08 product-backlog
GitHub issues · features · releases · epics
Phase 4 · LAUNCH “Route users to the product.”
09 product-www
Landing page · final destination page of the app
10 product-deployment
Environments + states + repo status (management.nova-labs.ai pattern)
Side · LEGAL “Paperwork that runs in parallel.”
11 product-legal
Legal files in MD (SPV · IP · contracts)
naiv-<product>/
  overview/                   — Panel · idea · sponsor · business line · metadata
  product-app/                — MVP app (staging: <product>.dev.nova-labs.ai)
                                 · staging repo + master/main repo (both live in Nova AI Ventures)
  product-www/                — Landing page · final destination page of the app
  product-backlog/            — GitHub issues · features · releases · epics
  product-branding/           — Logo · CSS theme · tone · identity
                                 ** Single source of truth for styling **
  product-deployment/         — Environments + states + repo status
                                 (pattern: management.nova-labs.ai/settings/releases)
  product-legal/              — Legal files in MD (SPV · IP · contracts)
  product-marketing-assets/   — Marketing stuff ONLY:
                                 · social media graphics
                                 · store assets (App Store, Google Play)
                                 · email templates · ad creatives
                                 · one-pagers · press materials
  product-pitch-deck/         — 3 HTML pitch decks (uses product-branding):
    internal/index.html           — For us internally (MANDATORY)
    operator/index.html           — For operator candidate (optional early)
    investor/index.html           — For potential investor (optional early)
  product-wireframes/         — UI wireframes (when needed)
  product-poc/                — Real working POC (optional · [sometimes])

3.2 product-branding/ Template (Nova AI Ventures Brand Package standard)

product-branding/
  brand-colors/                   brand-colors.json · brand-variables.css
  logos/                          18 variants (horizontal/stacked × 3 bg × claim)
  favicons/                       7 sizes + site.webmanifest
  og-images/                      8 variants (branded + unbranded, OG + Twitter + square)
  email-signatures/               signature-generator.html
  brand-guidelines.html           Full brand guidelines as HTML
  typography-guidelines.md        Fonts · hierarchy · usage rules
Key point: brand-colors/brand-variables.css = single source of truth for styling. Imported by pitch decks, www, app.

3.3 Pitch Deck Convention

  • Format: HTML index.html per deck · uses product-branding/brand-variables.css · Nova AI Ventures-standard template sections: Problem · Solution · Market · Traction · Team · Ask
  • Mandatory: Internal pitch (G2)
  • Optional early stage: Operator pitch (activates at G4) · Investor pitch (activates when raising)
  • Template lives in: Product Builder core (reusable skeleton, per-product branding overlay)

3.4 Staging / Master Repo Convention

Each product has two git repos in the Nova AI Ventures GitHub organization:

  • staging repo → deploys to <product>.dev.nova-labs.ai
  • master / main repo → deploys to production

Local

Dev machine

feature branch
→

Staging repo

Nova AI Ventures org

<product>.dev.nova-labs.ai
→

Master / Main

Production

stays in Nova AI Ventures
Master ALWAYS stays in Nova AI Ventures (even post-spin-out — flag to re-evaluate in §13 Governance).

3.5 Design Tooling

Stage 4 (Design Generation) uses:

  • MCP Stitch from Google — design system integration
  • Claude Code design capabilities — wireframes, UI components

No dedicated designer agent yet. Placeholder name for future: Luna Pixel (reports to Iris) · re-evaluate Q4 2026.

4. The Gate System · G0–G6

🚪 GATES · DECISION CHECKPOINTS

4.1 Gates + Folder Mapping

Gate Name Primary folder Criteria
G0 Capture overview/ Idea · sponsor · business line identified
G1 POC (real working) product-poc/ Real working POC end-to-end
G2 Internal Pitch product-pitch-deck/internal/ Branded HTML pitch · founder consensus
G3 Validation product-branding/ + product-www/ + product-marketing-assets/ + product-wireframes/ + optional investor pitch Market pull evidence (paying users / LOIs / threshold)
G4 Operator Onboarded product-pitch-deck/operator/ Operator identified · pitch delivered · signed
G5 MVP Build product-app/ + product-backlog/ Full handoff state · managed by operator · four-founder GO
G6 SPV Formalization (virtual → formal) product-legal/ Virtual SPV: legal framework + equity split + operator agreements drafted before public MVP launch. Formal SPV: incorporated as registered legal entity after commercial success trigger (e.g., 50k PLN MRR + 3 months positive margin per §06 section 5)
Throughout Env tracking product-deployment/ Live status of all deployments
The virtual → formal transition. A product enters the virtual SPV state when the MVP build starts publicly — the legal framework (equity split, operator agreements, IP assignments) is drafted and aligned even though no separate legal entity yet exists. Revenue flows to Nova AI Ventures (the registered holding entity). Once the product hits commercial success (operator launched MVP · post-launch traction · profitability trigger per §06 section 5 · usually 50k PLN MRR sustained 3 months), the SPV formalizes into a registered legal entity. This creates a separate company where the operator holds real equity, external investors can invest, and long-term governance lives. See §13 Governance for full mechanics.

4.2 Two Origination Paths (from §04 Line 02)

  • 02a Nova AI-initiated — idea from us → gates G0-G6
  • 02b Co-founded with expert — idea from domain expert → gates G0-G6 (paths merge post-G3)

Both use the same gates and same folder structure. The difference lives in origination + operator dynamics, not in Product Builder mechanics.

5. 4 Outcomes at Each Gate

🎯 OUTCOMES · 4 PATHS PER GATE

Each gate has 4 possible outcomes (not just pass/fail):

Outcome Meaning
Advance Pass gate · continue to next stage
Kill Stop all investment · document learnings · close file
Cap Freeze at current level · no more founder-hours · keep running in low-maintenance mode
Productize / Re-route Move to different business line (L02 → L03 template · L02 → L04 Management Suite · etc.)
Hard rule: Every product at every gate MUST have next decision date + kill criteria. No “parked indefinitely.”

6. Per-Product Tracking · 8 Mandatory Fields

📋 TRACKING · 8 MANDATORY FIELDS

Each product in Product Builder MUST have from day 1:

# Field Owner
1 Sponsor (which founder carries this) Bart / Vincent / Maciek / Mikołaj
2 Business line (L01 / L02a / L02b / L03 / L04 / L05) Sponsor
3 Current gate + evidence required to advance Sponsor
4 Nova AI Stack reuse (which layers) Maciek + Bart
5 Token economics + margin assumptions Vincent + shared founder help
6 Operator ICP + candidate longlist + outreach Sponsor (+ shared founder help)
7 Legal / IP / SPV readiness Mikołaj
8 Kill criteria + next decision date Sponsor (validated by 4 founders)

7. Handoff to AI Management-Suite

🤝 HANDOFF · SUITE TAKES OVER

After the 7-stage pipeline, the product enters active build phase — managed collaboratively by the full AI Management-Suite, not just the delivery trio. Each agent plays a specific role, empowered by specific tool sets (process flows, MCPs, skill libraries) tied to their domain. The Product Builder handoff is the starting point · the AI Management-Suite takes it from there.

7.1 The Full AI Management-Suite Role in Product Work

Each agent’s responsibility and tool empowerment:

  • Iris (Head of Marketing) — brand design, landing page copy, marketing assets · empowered by designer tool set (integrates with wireframes, brand templates, Stitch)
  • Mira (Head of Product) — product requirements, roadmap, feature prioritization · empowered by research + analytics tools
  • Dora (Head of Legal) — SPV documents, T&C / privacy / refund, compliance · empowered by legal template library + contract review tools
  • Brian (Head of Finance) — pricing, margin analysis, token economics modeling · empowered by financial modeling tools + metering dashboards
  • Aurelia (Head of Growth / BD) — lead generation, partnership outreach, operator sourcing · empowered by CRM + outreach tools
  • Ada (Head of Architecture) — technical direction, codebase analysis, architectural decisions · empowered by codebase analysis tools + Git integration
  • Dexter (Head of Software Engineering) — implementation, deployment, runtime · empowered by PI · OpenClaw · GitHub · Docker · Traefik
  • Vera (Head of QA) — browser validation, regression testing · empowered by Playwright tool set (not just smoke tests — full click-through attended QA)
Each agent is not just an assistant — they are a domain owner with specific tools. When the AI Management-Suite handles a product, every domain (legal, assets, design, research, delivery, QA, growth) is addressed in parallel, not sequentially.

7.2 How the Suite Interacts with Humans

The AI Management-Suite communicates with the four founders through Slack or Telegram channels per product. Every product has a dedicated channel. Agents post updates, ask questions, request approvals, and surface decisions. Founders weigh in through these channels.

Example interaction for brand design:

  • Iris starts a thread: “Working on brand direction for product X. Here are 3 options using current wireframes.” Attaches Figma / Stitch links.
  • Vincent reviews, comments, picks a direction.
  • Iris iterates, produces final brand assets, commits to product-branding/.
  • HITL rule applied: nothing published externally without Vincent’s sign-off.

7.3 New Features Flow (Not Just Greenfield)

The same pattern applies to new features on existing products, not just greenfield builds. Example:

  1. Founder posts in the product’s Telegram channel: “Hey, I saw this feature idea. Let’s deep dive.”
  2. Mira (PM) engages with the founder · asks clarifying questions · coordinates with Ada.
  3. Ada (Architecture) analyzes the current Git repo · assesses technical feasibility · flags architectural concerns.
  4. (Optional) A researcher agent runs market / competitor research on the feature.
  5. They converge on a clear feature proposal.
  6. Designer tooling (Luna Pixel future or MCP Stitch / Claude Code now) uses current wireframes + brand system to propose UX.
  7. Founders sign off.
  8. GitHub issue created — with full context: feature spec · design · acceptance criteria · QA plan.
  9. Dexter (SWE) picks up the issue · implements · works with Vera on tests.
  10. Vera uses Playwright not just for smoke tests — for full click-through attended QA — makes sure the feature actually works end-to-end in the browser.
  11. PR review by Ada · merge · deploy.
  12. Vera closes the loop with regression confirmation.

7.4 Wave-Based Delivery (Dexter · Ada · Vera discipline)

Within the full AI Management-Suite coordination, the delivery trio runs a disciplined wave-based loop for all implementation work:

Role Owns
Ada — Head of Architecture Technical direction · platform decisions · execution standard · service boundaries
Dexter — Head of Software Engineering Hands-on delivery · implementation · runtime · deployment · verification
Vera — Head of QA Browser validation · Playwright regression · defect surfacing · truth-check real behavior

Unit of execution

Wave → Tasks → Verification → QA → Feedback → Fixes → Next wave

Core tools (from Nova AI Stack Layer 04)

  • PI — bounded agentic execution engine (one task · one session · one artifact)
  • OpenClaw — orchestration (sessions · watchdogs · cron)
  • GitHub — execution ledger (issues · PRs · audit trail)
  • Docker + Traefik — runtime + routing
  • Playwright — browser truth layer

Handoff contract — 5 structured inputs from Product Builder

  1. Family definition (surfaces · MVP scope)
  2. Build brief (goal · flows · constraints · non-goals)
  3. Task graph (ordered waves · atomic task IDs · verification commands)
  4. Verification spec (local · browser · runtime · deploy · regression checks)
  5. Domain / runtime map (staging URLs · Docker / Traefik · env vars)

Critical pattern vs. SnapSell

Old (risky — SnapSell): implementation first · QA late / loose

New (required): wave-first · Playwright coverage per wave · Vera loop per wave · GitHub issues even for greenfield · regression pack grows every iteration

QA Gate — wave closure criteria (7 requirements)

  1. Code implemented
  2. Local verification passed
  3. Staging reachable
  4. Playwright suite passes
  5. No critical regression
  6. Vera validates or signs off non-blockers
  7. PR / issue trail current

Full doctrine: notes/dexter-delivery-doctrine.md — expanded in §07 AI Management-Suite.

8. Where Product Builder Lives

📍 WHERE IT LIVES · URLS + ACCESS
  • URL: product-builder.nova-labs.ai
  • Product family folders: naiv-<product>/ (per product)
  • Access levels:
    • Founders — full read/write
    • AI Management-Suite — relevant product scope (auto-distributed briefings)
    • Operator candidates — limited view (specific product, redacted financials)
    • External counsel (Mikołaj’s domain) — per-product read for legal review
“Nova AI Ventures exists to systematically turn human expertise and modern AI into real systems, real products, and real companies — at speed and at scale.”