1  Runi Team Setup & Department Equip Plan

Prepared by: IT Center (Ted) Date: 2026-07-10 Status: v0.1 internal working plan Positioning: Service-first. Runi = AI made it. Runi makes it run. Staffing model: Blend, redeploy existing IT staff now, hire dedicated on traction.

Runi is a delivery service that takes AI-generated demos (Cursor, Lovable, Bolt, v0, Claude Code) and makes them run, deploy, and ship. It sells engagements, not a product. The whole department is organised around the engagement lifecycle: Audit → Fix → Ship, with human sign-off at every gate.

This plan follows Clover’s 内建外销 model: prove it on our own demos first, then take a friendly pilot, then formalise and scale.

1.1 Service line & unit of work

Service What it delivers Doubles as
Runi Audit Read the client’s repo, report can-it-run status, risks, fix priority, effort estimate. Paid diagnostic + the basis for the Fix/Ship quote (de-risks both sides).
Runi Fix Fix bugs, deployment, database, auth/permissions, APIs. The bulk of billable delivery.
Runi Ship Turn the fixed demo into a deployable, maintainable, handed-over product. Highest-value engagement; recurring maintenance upsell.

The Audit is the funnel: quote it small (or free-lite), and it converts into Fix/Ship scope.

1.2 Operating model, engagement lifecycle

Intake  →  Audit  →  Scope + Quote  →  Fix/Ship (milestone-based)  →  Human verify  →  Handoff
                                                                          ↑
                                                          AI never verifies AI

Each stage has a named owner and a standard artifact (see Section 1.5). Every AI-Post output passes human verification before it reaches the client. This boundary is the product’s trust story, so it is non-negotiable.

1.3 Team blueprint (blend staffing)

Roles first, early on, one person wears several. The Now column is redeployed existing IT staff (part-time / rotational); the Hire on traction column is what we recruit once the trigger in Section 1.6 is met.

Role Responsibility Now (redeploy) Hire on traction
Runi Lead / delivery owner Intake, scoping, quoting, client comms, go/no-go. Ted (or senior engineer), part-time Dedicated delivery lead when 3+ concurrent engagements
Audit engineer Run Runi Audit, produce standardized report + estimate. 1 senior engineer, rotational 1 dedicated auditor when audit demand is steady
Fix/Ship engineers Deployment, DB, auth hardening, API repair, maintainability. 2 product engineers, part-time 2-3 dedicated engineers as pipeline fills
Human verifier / QA Enforce AI-never-verifies-AI; final sign-off. Lead or rotating senior Fold into dedicated pod
AI Post(s) First-pass fixes, migrations, test scaffolds, diagnosis. Stand up 1-2 now Scale count with engagement volume

Blend principle: no net-new fixed cost until the pilot proves demand. Existing engineers split time between product work and Runi; AI Posts absorb repetitive volume so redeployment stays light. Convert to dedicated hires only when the Section 1.6 trigger fires.

1.4 Equip checklist, what the department needs before engagement #1

A. Golden-path toolkit, stack-agnostic (this is the Fix/Ship SOP)

Runi meets clients on their stack. Vibe-coding tools default to a handful of host/service combos, and Runi engineers must be fluent across all of them, not just Cloudflare. Our internal builds give us the principles (auth, DB hygiene, deployment discipline, maintainability); the toolkit maps those principles onto whichever stack the client’s demo already uses.

Principles we bring (stack-independent):

Target-stack playbooks, build one per common combo (fix-in-place recipes):

Layer Stacks Runi must handle Notes
Hosting / frontend Vercel (v0 default), Netlify (Bolt), Cloudflare Pages, Render, Railway Next.js/React dominates inbound demos
Backend / DB (PaaS) Supabase (Lovable/Bolt default), Neon, PlanetScale, Firebase, Railway Postgres, our Cloudflare D1 Supabase is the single most common inbound backend
Auth Supabase Auth, Clerk, Auth.js/NextAuth, Firebase Auth, AWS Cognito Insecure/incomplete auth is the most frequent Fix item
Traditional / scalable cloud AWS (ECS/EKS/Lambda, RDS/Aurora, S3, CloudFront, VPC), GCP, Azure The enterprise ceiling: real scale, compliance, VPC isolation, cost control. Also our existing L2 Support turf.
Runtime source Cursor, Claude Code, v0, Lovable, Bolt Know each tool’s default output shape and its typical failure modes

Two delivery modes (decided at Audit, priced separately):

  1. Fix-in-place, repair and ship on the client’s existing stack (Vercel + Supabase, etc.). Default; lowest friction; what most clients want.
  2. Migrate / scale-up, move to a more robust stack when the current one can’t meet the requirement (cost, scale, security, compliance). A larger, explicitly-scoped engagement. Targets range from lightweight (Cloudflare golden path) to traditional/scalable cloud (AWS primary, GCP/Azure) for enterprise-grade workloads. Offered per requirement, never forced. AWS scale-up leans directly on our existing L2 Support / AWS operational experience.

B. Runi Audit kit

C. AI Post infrastructure

D. Tooling access + governance

E. Skills readiness

1.5 Standard artifacts (one per stage)

Stage Artifact Owner
Intake Engagement brief (client, demo source, goal, urgency) Lead
Audit Runi Audit report + effort estimate Audit engineer
Scope + Quote Milestone-based quotation Lead
Fix/Ship Progress log + change record (audit-trailed) Fix/Ship + AI Post
Verify Human sign-off checklist Verifier
Handoff Deployable product + runbook + maintenance option Lead

1.6 Phased ramp & the hire trigger

Phase Timing Staffing Goal Exit trigger
0, Dry-run Now Redeploy + 1-2 AI Posts Toolkit + Audit kit built; 2-3 internal demos run through Audit→Fix→Ship Toolkit proven, Audit report standardized
1, Pilot After Phase 0 Same (part-time) 1 friendly external engagement end-to-end; validate effort estimates vs actuals Pilot delivered, quote model calibrated
2, Scale (hire) On traction Convert to dedicated hires Run concurrent paid engagements Trigger: ≥3 concurrent engagements or redeployed staff >50% time on Runi for 4+ weeks

The trigger is deliberately quantitative so the hire decision is evidence-based, not a hunch. Until it fires, the blend holds.

1.7 What “traction” means (metrics to watch)

  • Audit-to-Fix/Ship conversion rate (funnel health)
  • Estimate accuracy: quoted effort vs actual (drives pricing confidence)
  • AI Post assist ratio: % of delivery volume handled first-pass by Posts
  • Redeployed-staff time drain: hours/week pulled from product work (this is the hire pressure gauge)
  • Engagement margin

1.8 Guardrails

  • AI never verifies AI. Every Post output gets human sign-off. Non-negotiable.
  • Capacity conflict is the #1 blend risk. Cap redeployed hours per engineer per week; if the cap is breached repeatedly, that is the hire trigger, don’t absorb it silently.
  • Security/audit is the moat. Anyone can vibe-code a fix; “deployable, permissioned, auditable” is what Runi sells. Hold the golden-path standard on every engagement.
  • Scope discipline. Runi Fix is not “rebuild from scratch.” The Audit defines the boundary; anything beyond it is a new engagement.

1.9 Immediate next actions

  1. Assign a Runi Lead (default: Ted) and name the 1 auditor + 2 fix engineers to redeploy part-time.
  2. Build the golden-path toolkit and Audit report template (see the Equip checklist above).
  3. Stand up 1-2 AI Posts with supervisors and monthly KPIs.
  4. Pick 2-3 internal past demos for the Phase 0 dry-run.
  5. Add Runi tool subscriptions to the IT Tool Budget Tracker.
  6. Set the Phase 2 hire trigger in writing so the whole team knows the rule.

Next deliverables available on request: Runi Audit SOP + report template; milestone-based quotation model; pitch memo for Min.