Execution Gameplan & VC-Readiness Review

Purpose: A board-ready, cross-document review of the entire Kobi Digital Ads doc set. It (1) confirms what is strong, (2) surfaces the hard external blockers that could change the plan or stop account creation, (3) lists scope decisions to lock now, (4) gives a tight-but-safe, gated execution timeline with an explicit pre-flight critical path, and (5) prepares the VC board Q&A — including the commercial gaps the engineering docs do not (and should not) answer.

How to read this: Sections 2 and 3 are the "we cannot afford to miss this" content. Section 7 is what the board will actually grill you on. Section 8 is what we need from you before the meeting.

Related: Roadmap & timelines · Platform access & API readiness · Onboarding API cross-check · Vision & scope

---

1. Review verdict

The documentation set (31 docs) is unusually mature for Phase 0 — it is a strong engineering and operations specification. Specific strengths:

• Platform access realism — scope/capability matrices, rate-limit tiers, PRE vs ONB separation, red-flag automation. This is where most teams are naive; here it is a strength.
• Agency-owned, no-client-billing model — internally consistent across vision, onboarding, platform, and security docs.
• GA4-as-source-of-truth + ID-first attribution — the UTM spec is precise and avoids the classic Google auto-tagging/UTM collision.
• Agentic cost discipline — Cost Guard, QC telemetry, per-task LLM cost catalog, model routing. Rare to see this rigor pre-build.
• Human control plane split (Human Touch vs System Ops behind IAP/VPN) is clean and maintainable.

The gap is not engineering — it is (a) a handful of platform constraints that are understated and could block scaling, and (b) the absence of any commercial layer (market, unit economics, moat, working capital), which is exactly what a VC board evaluates. Both are addressed below.

---

2. Top blockers that could change the plan (ranked)

These are ordered by "likelihood × impact on the plan." Each has a status, the real constraint, and the mitigation that must be owned now.

🔴 B1 — Meta caps API ad-account creation at 5; scaling requires the gated 2-Tier Business Manager program

• The constraint (verified): Meta's API (POST /{business_id}/adaccount) is limited to 5 ad accounts per Business Manager. To go beyond, you must adopt the 2-Tier Business Manager solution (a parent BM that programmatically creates a child BM per client), and access to those APIs is not self-serve — you must request it through a Meta representative. All accounts in the BM must also be in good standing or creation is blocked entirely.
• Why it matters: The current architecture ("Kobi BM → one ad account per tenant") is fine for a ≤5-tenant pilot but hits a hard wall at client #6. This is the canonical "we can't create accounts because the API won't let us" failure — and the fix is a relationship-gated program with no guaranteed SLA.
• Plan impact: The Meta tenant model becomes child-BM-per-client, not just ad-account-per-client. That changes the onboarding flow, the asset-assignment logic, the credit-line sharing model, and the registry schema (store child_business_id per tenant).
• Mitigation (own now):
  1. Pilot on a single BM (≤5 ad accounts) — not blocked; Phase 1/2 can proceed.
  2. In parallel, open the 2-Tier BM request with a Meta partner/sales rep in Phase 0 (treat like the DV360 sales cycle — long lead, relationship-driven).
  3. Design the registry and onboarding connector for child-BM-per-tenant from day one so no rework when access lands.
  4. Track as a new pre-launch item (PRE-10) and a scaling red flag.
• Status in docs: Mentioned only in passing ("consider 2-tier for scale", ONB-3). Now elevated — see fixes in meta-ads.md, platform-access, cross-check.

🔴 B2 — Commercial model lives at the parent/VC level (this module owns the cost side)

• This module is one part of a larger Kobi project managed directly by the VC; pricing, take-rate, market sizing, and fundraise are owned and held confidently at the parent/VC level — intentionally not in this engineering repo.
• What the module does own and must get right is the cost side, now consolidated in the Cost model & estimates: per-tenant $8–42/mo, portfolio ~$240 → ~$4.5K/mo (5 → 200 clients), **13-week core go-live DDL** (solo sprint; ~50 eng-weeks = full-module accounting only), and the media-float working-capital call-out (B3).
• Action: keep this module's numbers (cost, timeline, blockers) crisp so they slot cleanly into the parent's commercial model.

🔴 B3 — Working-capital / media-float exposure (agency-billing model)

• Kobi pays platforms (often on extended credit) and invoices clients monthly. At scale, pass-through media spend dwarfs SaaS revenue and Kobi is effectively financing clients' ad budgets. A single non-paying or fraudulent client = direct cash loss; growth consumes working capital.
• Not addressed anywhere. Needs: credit policy, prepayment/escrow for new clients, per-tenant credit limits tied to credit_sub_limit (the spend caps exist; the cash/credit policy does not), and a financing line. VCs will probe this hard because it changes the capital intensity of the business.

🟠 B4 — Meta "Full" Marketing API tier is a chicken-and-egg gate

• Full tier (production rate limits) requires 500+ API calls over 15 days with <15% error rate — i.e., you must already be calling the API at volume to qualify. New apps start on Limited.
• Mitigation: Generate qualifying volume during Phase 1 pilot (sandbox + single-BM real calls) so Full tier is approved before Phase 2 multi-tenant launch. Put it on the pre-flight critical path with a dated target, not "apply when needed."

🟠 B5 — GA4 is "source of truth" but onboarding makes it optional

• Onboarding v1 does not create GA4 properties and only links if the client grants Admin. Yet optimization is specified to run on GA4 ("never optimize on platform-reported conversions alone"). If a client declines GA4 Admin, the documented optimization premise breaks and the Phase 1 exit criterion ("pilot live on Google with GA4 SoT reporting") cannot be met.
• Decision to lock: For pilots, GA4 Admin grant is effectively required (make it a soft gate). Define the explicit fallback when GA4 is absent: optimization runs on platform-reported + CRM signals with a clearly degraded mode and a banner, not silent. See fix in optimization.md / onboarding.

🟠 B6 — Google approvals are slower than assumed

• adwords is a sensitive scope; external OAuth verification is 4–8 weeks (mitigated by internal-first). Developer-token approval currently has a reported backlog (don't assume 2 days). Standard Access requires Basic first + RMF compliance + ~10 business days.
• Mitigation: Internal OAuth + dedicated automation user for pilot (already the plan); file Basic week 0; file Standard the moment ops/day projections approach 10k.

🟠 B7 — Closed-loop (CRM → CAPI) is the headline value prop but lands last (Phase 4)

• The strongest differentiator — connecting ad spend to real business outcomes — is sequenced to the final phase. A pilot that can't show closed-loop ROI under-sells the thesis to the board and to design partners.
• Mitigation: Ship an interim file/webhook-based offline import for Google + Meta in Phase 2 (the cross-check already notes a file-based interim is possible), so at least one closed-loop story exists before Phase 4 hardens it.

🟡 B8 — Platform-dependency / account-suspension concentration risk

• The entire business depends on staying in good standing with Google and Meta. Agency BM suspensions are common and can take all clients dark at once. Break-glass admins are documented; the business-continuity runbook (multi-BM/MCC sharding, prevention, early warning, appeal SLAs, client comms) is now specified in security — platform account suspension & business continuity. Remaining action: assign per-platform appeal owners and rehearse.

🟡 B9 — Agentic platform is over-scoped for an MVP

• Cost Guard + QC telemetry + automatic model promotion + 80% QC floor alerting is excellent target-state engineering, but it is a lot to build before first revenue. A startup should ship rules-based optimization + a thin LLM layer + basic guardrails first and layer the QC/Cost-Guard machinery in Phase 2–3. See the MVP cut in Section 4.

🟡 B10 — Factual/compliance accuracy fixes (small but board-visible)

• Special Ad Categories are only HOUSING, EMPLOYMENT, FINANCIAL_PRODUCTS_SERVICES, ISSUES_ELECTIONS_POLITICS. Schools and health are not special categories. Docs incorrectly map School→HOUSING and say "required for schools/health." Also: social/political ads are banned in the EU (TTPA, Oct 2025) — relevant to the TR/EU footprint. Fixed in Section 6.

🟠 B11 — Account-creation gating is not Meta-only — Google MCC eligibility + TikTok BC caps

• The Meta 5-cap (B1) is the loudest, but the same class of "the API won't let you create the account" risk exists on Google and TikTok and was previously undocumented:
  • Google Ads: a new/low-spend Kobi MCC can be refused API account creation (CREATION_DENIED_INELIGIBLE_MCC, enforced since Mar 2025) until it meets spend thresholds / has enough active policy-compliant child accounts — a chicken-and-egg gate like Meta Full tier. Also a 2,500/week creation cap and frequency quota (RESOURCE_EXHAUSTED).
  • TikTok: a default per-Business-Center advertiser-account cap that varies by BC type, raised only via a TikTok account manager — relationship-gated like Meta 2-Tier.
• Mitigation: make account-creation eligibility a Phase-0 gate on all three platforms, not just Meta — seed the Google MCC with spend/history early, confirm TikTok BC headroom with the rep, and handle the specific error codes with UI break-glass. See platform access — Google account-creation limits and TikTok structure.

---

3. Pre-flight external-dependency critical path (start NOW, parallel to engineering)

These are calendar-bound external approvals — engineering speed cannot compress them. They are owned by ops / finance / legal / sales, not engineers, and several gate later phases. Start every long-pole item in Phase 0.

Long poles to watch: PF-11 (Meta 2-Tier), PF-16 (DV360), PF-7/PF-10 (scale tiers). Pilot (≤5 Meta accounts, Google, GA4) is not blocked by the long poles — so build the pilot while the long poles mature.

---

4. Refined phase-by-phase execution timeline (tight, with safety)

Principle: respect a startup's need for speed, but gate each phase on the external approval it actually depends on (Section 3) and on a working pilot — not on calendar optimism. Durations assume 2–4 engineers + ops, and run the pre-flight track in parallel.

Headline milestones for the board:

• Pilot live (Google + GA4): ~week 10–12.
• First closed-loop ROI story: ~week 12 (interim) → hardened week 26.
• Multi-channel (Google + Meta + TikTok): ~week 18, contingent on PF-10/PF-11.
• Full module: ~26 weeks (≈6 months) with parallel workstreams; DV360 only if the sales contract lands.

MVP cut (what to defer to protect the pilot date): automatic model promotion, the full QC-telemetry/BigQuery analytics stack, the 80%-floor alert job, Cost Guard's full ledger (keep a simple per-run hard budget), the first-party relay, and DV360. Ship: onboarding, Google + GA4, rules-based optimization with a thin LLM planner/QC, a hard spend guardrail, and the Human Touch approval inbox.

---

5. Scope decisions to lock now (or they change the project later)

Leaving these open risks rework or a blocked launch. Each needs an owner and a decision date before Phase 1 build.

---

CPAS — Phase 2 core track (open questions)

Meta Collaborative Ads (CPAS) — brand ↔ marketplace catalog collaboration. Strategic: democratize a format large advertisers use heavily today. Build: Phase 2 (not Phase 1 pilot). Spec: meta-collaborative-ads-cpas.md.

Locked direction:

• Measurement: Meta shared-item insights (catalog_segment_value, converted_product_*, segment ROAS) — not GA4-primary for CPAS campaigns.
• Execution: catalog_segment_id; dedicated ad account per retailer where Meta requires.
• TikTok: similar opportunity exists; spec later.

---

6. Cross-document consistency fixes (checklist)

Concrete inconsistencies/inaccuracies found across the set. ✅ = corrected in this pass (see edits); ☐ = recommended follow-up.

---

7. VC board — anticipated questions & honest readiness

Mapped to where you're strong (lead with these) and weak (have an answer ready).

Where the docs make you strong

Where the answer lives elsewhere (parent/VC-owned) or needs prep

Most commercial items below are held at the parent/VC level, not in this module. The module's job is to supply clean cost, timeline, and risk inputs (see cost model) that those answers build on.

Framing tip for the board: Lead with "we de-risked the technical unknowns to an unusual depth for our stage (show the readiness doc), and we know exactly which 3 external approvals gate scaling and have started all of them." Then pivot to the commercial story. The engineering depth is a credibility asset — but the board buys the business, so don't let the deck be 90% architecture.

---

8. What this module needs decided (commercial sits with parent/VC)

Pricing, market sizing, and fundraise are owned at the parent/VC level and are out of scope here. What the module needs to proceed cleanly:

1. Decisions S1–S9 — S1–S3, S7–S9 ✅ locked (ADRs 0001–0004); S4 partial (limit mechanics locked, payment source → finance); S5–S6 deferred.
2. Working-capital payment model — prepay vs invoice vs hybrid (S4/B3) — finance / parent billing team.
3. Confirm cost assumptions — the cost model uses planning bands; replace with real run_id token + infra usage from the pilot to lock budgets.
4. Design-partner status — any pilots lined up (PF-17), so Phase 1 has a real tenant.

Commercial figures, when needed, slot directly against the module's cost model and timeline.

---

Related documents

• Roadmap & timelines — phase detail (engineering)
• Platform access & API readiness — scopes, tiers, PRE register
• Onboarding API cross-check — endpoint-level automation reality
• Vision & scope — billing model, in/out of scope
• ADR 0001 — tech stack