Fractional CTO Product Leadership for AI-Native Dual-Product SaaS

By Amar Kumar

A proposed embedded fractional CTO and product engineering model for an AI-native operating company running two products at equal priority: a revenue-generating customer SaaS platform and an internal agent fleet that runs finance, operations, engineering oversight, and coaching. The approach would treat both surfaces as real products — with discovery, specs, CI gates, observability, and feedback loops — rather than shipping customer features while internal automation stays as throwaway scripts.

Proposed outcome: One embedded technical leader who owns product direction, hands-on delivery, and engineering standards across app.storscale.ai and the internal Claude/MCP agent layer — compounding reusable foundations instead of project-by-project contractor churn.

Scenario

This brief describes a proposed solution for StorScale (StorScale.ai) — the Storage Intelligence Platform for self-storage operators — not a delivered engagement.

The fractional leader would sit inside the tent: Slack, standups, roadmap decisions, and codebase ownership — not a scoped agency deliverable handed off at the end of a sprint.

Problem

StorScale's dual-product model creates leadership gaps that agencies and gig contractors rarely close:

• Split attention — Customer roadmap and internal agent reliability compete; without one owner, internal workflows become scripts while SaaS gets polish (or vice versa).
• Agent sprawl — Claude/MCP workflows start as experiments; without production gates they lack tests, idempotency, dead-letter handling, and audit trails.
• Standards drift — TypeScript strict mode, TDD, and green CI are stated values but erode under speed pressure without someone holding the line.
• Product vs engineering tension — Features ship without measurement; specs skip discovery; operators and internal users both feel the gap.
• Contractor churn — Scoped projects hand off context; the harness, migration discipline, and agent registry never compound.
• Human/agent boundary blur — Without explicit handoff design, humans redo agent work or agents run unchecked on finance and ops tasks.

Requirements

Functional

• Unified product backlog spanning customer platform and internal agent workflows, prioritized by business impact
• Full delivery loop: discovery → spec → build → PR review → deploy → measure (PostHog + Sentry)
• Internal agent registry: named workflows, schedules, inputs/outputs, owner, rollback path
• Human-in-the-loop gates for finance, pricing recommendations, and customer-facing intelligence outputs
• Stripe billing integrity; Supabase RLS policies reviewed per feature

Non-functional

• TypeScript strict: true across Next.js and Node agent services
• CI must stay green; coverage gates on critical paths (auth, billing, agent side-effects)
• Branch-based Supabase migrations; no schema changes without review
• Agent jobs idempotent; safe retries; structured logs to Sentry
• Central-time overlap for standups and architecture decisions; async Slack for everything else

Architecture

Three planes: the customer intelligence platform (operator-facing SaaS), the internal agent fleet (business operations), and the embedded leadership layer (product direction, standards, and shared CI/observability).

flowchart TB classDef customer fill:#dbeafe,stroke:#2563eb,color:#1e3a8a classDef internal fill:#ede9fe,stroke:#7c3aed,color:#5b21b6 classDef data fill:#ccfbf1,stroke:#0d9488,color:#115e59 classDef lead fill:#fef3c7,stroke:#d97706,color:#92400e classDef ext fill:#f8fafc,stroke:#475569,color:#334155 OPS["Self-storage operators"]:::ext TEAM["Internal team\nSlack · Notion"]:::ext APP["app.storscale.ai\nNext.js on Vercel"]:::customer DASH["Intelligence dashboard\nmarketing · customer · pricing"]:::customer OPS --> APP APP --> DASH AGT["Scheduled agent fleet\nRender + GitHub Actions"]:::internal FIN["Finance agent"]:::internal ENG["Engineering oversight"]:::internal RUN["Operations agent"]:::internal TEAM --> AGT AGT --> FIN AGT --> ENG AGT --> RUN MCP["Claude agents + MCP tools"]:::internal FIN --> MCP ENG --> MCP RUN --> MCP SB[("Supabase Postgres\nRLS · migrations")]:::data STR["Stripe billing"]:::data DASH --> SB DASH --> STR MCP --> SB OBS["Sentry + PostHog"]:::data APP --> OBS AGT --> OBS CTO["Fractional CTO layer\nroadmap · PR review · standards"]:::lead CTO --> APP CTO --> AGT CTO --> SB

Dual-product topology — customer SaaS and internal agent fleet share Supabase, observability, and embedded product leadership

sequenceDiagram autonumber participant PM as Product / CTO participant NOT as Notion spec participant DEV as Next.js + agents participant CI as GitHub CI participant VER as Vercel / Render participant PH as PostHog participant SEN as Sentry PM->>NOT: discovery + spec PM->>DEV: TDD implementation DEV->>CI: pull request CI->>CI: strict TS + tests + coverage alt pass CI->>VER: deploy preview / prod VER->>PH: feature funnel events VER->>SEN: release health PH->>PM: measure + retro else fail CI->>DEV: block merge end

Delivery sequence — discovery through measurement; CI gates block merge on both customer app and agent services

End-to-end delivery loop

Same loop applies to customer features and internal agent workflows — internal users are the second customer

Recommended stack

Engineering baseline (code)

TypeScript strict mode would be enforced at the compiler and CI level — not optional per package:

// tsconfig.json — customer app and agent services
{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitReturns": true,
    "exactOptionalPropertyTypes": true
  }
}

Agent & component design

Customer platform components

Internal agent workflows

Agent registry entry (YAML)

Each internal workflow would be registered with owner, schedule, and rollback — not buried in a cron comment:

workflows:
  - id: finance-weekly-reconcile
    owner: fractional-cto
    schedule: "0 6 * * 1"   # Monday 06:00 CT
    runtime: render
    model: claude-sonnet-4-6
    mcp_servers: [stripe, notion, supabase]
    inputs: [stripe_balance, bank_export_csv]
    outputs: [notion_draft, slack_approval_request]
    human_gate: true
    idempotent: true
    on_failure: dead_letter_queue + sentry_alert

Human vs agent boundary

Implementation plan

Reporting & ops

Alert cadence: P1 Sentry → Slack immediately; agent failure → retry then dead-letter + morning summary; Stripe webhook failures → page within 15 minutes.

Proposed deliverables

1. Architecture and risk memo (customer + internal products)
2. Engineering standards doc (TDD, CI, TypeScript, Supabase migrations)
3. Agent registry (YAML or Notion DB) with owners and rollback paths
4. One shipped customer feature with PostHog measurement plan
5. Hardened internal agent workflow with tests and human approval gate
6. Weekly product/engineering review template
7. Hiring rubric and onboarding checklist for next engineer

Effort estimate

Ongoing maintenance would consume roughly 20% of fractional time on agent fleet health, dependency updates, and CI hygiene.

Glossary

An AI-native company needs one product owner for both the dashboard operators pay for and the agents that run the business behind it. Following this plan, fractional leadership would compound — standards, registry, and delivery loop shared across both surfaces.