Files
boundhq/inbound/NORTH_STAR.md
T

3.6 KiB

Dev Centre North Star Spec

This spec defines how the North Star should appear inside Dev Centre so Brendan sees launch readiness, not just generic module completion.

Goal

When Brendan opens Dev Centre, the first screen should answer:

  1. Can we onboard the first paying SaaS customer?
  2. What is blocking that?
  3. Which module needs the next smallest safe action?

Top Band: North Star

  • Current North Star: first paying SaaS customer onboarded and retained for 90 days.
  • Stage 1 readiness score.
  • Launch status: Blocked / At Risk / Ready for first customer / In customer trial.
  • Top 3 blockers.
  • Next recommended action.

Launch Checklist

Checklist groups:

  • Security and access
  • Tenant provisioning
  • Auth/login
  • Compliance/PDF
  • Core workflow
  • Xero/accounting
  • Onboarding assets
  • Testing

Module Readiness Table

Columns:

  • Module
  • Stage classification
  • Build status
  • Data status
  • SaaS safety
  • Test status
  • Blocker
  • Owner
  • Next action

Blockers Panel

Show only launch blockers:

  • login bounce
  • PDF compliance defaults
  • Xero scopes/setup
  • tenant isolation tests
  • SaaS Admin deploy
  • VPS credential/security items

First Customer Progress

Fields:

  • Customer identified?
  • Tenant provisioned?
  • Owner login verified?
  • First quote created?
  • First invoice created?
  • Xero connected/manual fallback?
  • 7-day/30-day/90-day check-in status?

Data Needed

Current Dev Centre tables can support some of this:

  • dev_log_items
  • dev_module_status
  • dev_revisions
  • dev_improvements
  • dev_technical_debt

Additional fields or derived config needed:

  • stage classification: Stage 1, Stage 1.5, Stage 2, Later
  • launch blocker boolean
  • owner: Brendan / AI / customer / external
  • test status: not run, failing, passing, blocked
  • route promotion status from route-module-map.json
  • North Star checklist status

Completion Scoring Logic

Readiness should not equal build completion.

Suggested formula:

stage_1_readiness =
  25% build_complete +
  25% data_source_correct +
  25% saas_safe +
  25% tested_in_launch_flow

Launch blockers should cap the score:

  • login broken: cap Auth and overall launch at 50%
  • legal PDF issue: cap Quotes/PDF/overall launch at 70%
  • tenant isolation untested: cap overall launch at 75%
  • SaaS Admin not deployed: cap onboarding at 60%
  • Xero blocked: cap Xero at 50%, but allow manual-accounting exception if Brendan approves

Module Readiness Categories

Category Meaning
Stage 1 - Must Work Required for first paying customer
Stage 1.5 - Strongly Recommended Can be manual/assisted at launch
Stage 2 Useful after first customer validates SaaS
Later / Parked Do not spend launch time
Internal Only Dev/admin tools not sold as product modules

Testing Checklist

Dev Centre should show pass/fail for:

  • login
  • tenant creation
  • customer creation
  • quote creation
  • compliant PDF generation
  • quote acceptance
  • project/job creation
  • invoice creation
  • Xero push or manual fallback
  • cross-tenant data isolation
  • Tradify import dry run
  • Email Intake dry run

What Brendan Should See First

Recommended first line:

Stage 1 SaaS launch is blocked by: login verification, PDF compliance defaults, SaaS Admin deploy, tenant isolation tests, and Xero setup decision.

Then show one button or command:

Next best action: verify login on staging or approve AI to deploy SaaS Admin and PDF defaults.

Readiness Verdict

Dev Centre should become the launch cockpit. The current module completion tab is useful history, but it is not a safe source of truth for Stage 1 launch decisions.