CTO Plan Review
A CTO's verdict on one design doc or RFC: what breaks first at 10x, failure modes, security and on-call gaps, and true cost of ownership.
Before & after
Same prompt, same agent — the only difference is the skill.
That's a good planning question to think about. Scaling can be challenging as your business grows. You'll want to consider your database capacity, server resources, and how your API handles increased load. Think about whether your architecture has bottlenecks. You might need to add more servers or optimize queries. Caching can help too. Different scaling strategies work for different architectures. It really depends on your current setup and growth trajectory. Have you thought about what the main scaling challenges might be?
ARCHITECTURE INTERROGATION CRITICAL SCALING CLIFF: Database: PostgreSQL single-instance, 150GB at 10x load (current: 15GB) Issue: Replication lag at scale; connection pool exhausts at 3000 QPS (you hit 2900 at 8x) Fix urgency: IMMEDIATE before Series A (breach likely at 6x within 2 quarters) DECISION POINT: Upgrade to managed Postgres + read replicas (4 weeks, 18k) vs rebuild on Firestore (8 weeks, design risk) Recommendation: Postgres scaling path preserves schema; you own the upside SECONDARY CLIFFS: 1. API Gateway rate-limiter (per-user, not global) — add sliding-window counters (3 days) 2. Cache invalidation strategy (currently TTL-only) — add event-driven purge (2 days) 3. Message queue depth (SQS at 80% max depth today) — forecast 220% at 10x; add worker pool (1 week) TEAM SCALING BLOCKER: Your on-call rotation (2 people) cannot handle 10x incident volume. Add 1 engineer to SRE role before scaling 5x. REB UILT ESTIMATE: 12 weeks to 10x-safe architecture. Start now. Do not fundraise on current architecture.
About this skill
Get the review a CTO would give your design doc before the team commits months to it. Every finding names a component and a fix, not a vague worry.
What it does
- Restates the plan's assumptions so gaps are visible
- Names the first component to break at 10x load and why
- Traces failure modes: timeouts, retry storms, idempotency, rollback
- Checks tenant isolation, secrets, and personal data flows
- Counts on-call and maintenance in build vs buy cost
What you get
A verdict, assumptions list, first breaking point, ranked risks with fixes, hidden ongoing costs, and what evidence would change the verdict.
Best for
Tech leads, staff engineers, and CTOs reviewing RFCs, migrations, service splits, or build-vs-vendor proposals.
SKILL.md preview
---
name: cto-review
description: Critique one architecture proposal, design doc, RFC, migration plan, or build-vs-vendor plan through a CTO's lens and return a verdict, the component that breaks first at 10x load, failure modes, security and operability gaps, true cost of ownership, and what would change the verdict. Use when the user says "review this design doc", "will this architecture scale?", "poke holes in our migration plan", "we're about to build our own X instead of buying, check it", "CTO review of this RFC", or pastes a system design and asks "what are we missing?".
---
# CTO Plan Review
… (sign up to view the full skill)More development skills
View all Development skills →Performance Bottleneck Profiling: Node, Python, Go
Classifies a slowdown, gives exact profiler commands, reads the output, and proves the fix with same-conditions p95/p99 numbers.
Feature Scaffolding with Working Tests
Turn a short feature spec into code, runnable tests, and integration wiring that match your existing project.
Feature Flag Rollouts and Kill Switches
Design staged flag rollouts, verify rollback paths, and audit flag debt with explicit defaults, gates, and retirement plans.
Microcontroller Firmware and RTOS Engineering
Build and debug MCU firmware with bounded ISR/RTOS timing, safe DMA ownership, and measured power budgets.