CTO Advisor
Technical leadership frameworks for startup CTOs. Balance engineering excellence with business reality. Simple > clever. Boring technology wins.
Keywords
CTO, chief technology officer, architecture, tech stack, build vs buy, tech debt, team scaling, system design, microservices, monolith, database, API design, scaling, DevOps, CI/CD, engineering hiring, infrastructure, security, code quality, SRE, incident response, performance, reliability
Core Responsibilities
1. Architecture & System Design
Architecture decision process:
- Define constraints (team size, budget, timeline, scale requirements)
- List realistic options (what can this team actually build and maintain?)
- Evaluate tradeoffs (performance, cost, complexity, hiring, vendor lock-in)
- Document the decision (ADR — Architecture Decision Record)
- Plan migration path (if changing existing system)
Monolith vs Microservices decision tree:
- Team < 10 engineers? → Monolith
- Single product? → Monolith
- Need independent deployment of components? → Consider microservices
- Can you afford the operational overhead? → If no, monolith
- Clear bounded contexts with different scaling needs? → Microservices make sense
Database selection:
| Need |
Recommendation |
| General purpose, relational data |
PostgreSQL |
| Document store, flexible schema |
MongoDB |
| High-speed caching |
Redis |
| Full-text search |
Elasticsearch / Meilisearch |
| Time-series data |
TimescaleDB / InfluxDB |
| Graph relationships |
Neo4j |
| Simple key-value at scale |
DynamoDB |
| Analytics/OLAP |
ClickHouse / BigQuery |
The default stack for startups:
- Backend: Node.js/TypeScript or Python/FastAPI
- Frontend: React/Next.js or Vue/Nuxt
- Database: PostgreSQL + Redis
- Infrastructure: Railway, Render, or Vercel (avoid AWS complexity early)
- CI/CD: GitHub Actions
- Monitoring: Sentry + basic metrics
2. Tech Stack Selection
Evaluation criteria:
| Factor |
Weight |
Questions |
| Team capability |
30% |
Can the team build and maintain this? |
| Hiring pool |
20% |
Can we hire for this technology? |
| Maturity |
15% |
Is this battle-tested or bleeding edge? |
| Performance |
15% |
Does it meet our scale requirements? |
| Cost |
10% |
Total cost of ownership? |
| Lock-in risk |
10% |
How hard is it to switch later? |
The "boring technology" rule: Choose technology that's proven, well-documented, and has a large community. Save your innovation tokens for your product, not your infrastructure.
3. Build vs Buy Analysis
Decision framework:
| Factor |
Build |
Buy |
| Core to your product? |
Build if core differentiator |
Buy if commodity |
| Team expertise? |
Build if you have the skills |
Buy if it's outside your domain |
| Time to market? |
Build if no time pressure |
Buy if speed matters |
| Customization needs? |
Build if highly custom |
Buy if standard works |
| Long-term cost? |
Build if high volume makes it cheaper |
Buy if low volume |
| Maintenance burden? |
Build only if you can maintain it |
Buy to offload maintenance |
Rule of thumb: If it's not your core product and someone else does it well, buy it. Your engineering time is your most expensive resource.
4. Tech Debt Management
Tech debt categories:
- Deliberate-prudent: "We know this is a shortcut, and we know how to fix it later"
- Deliberate-reckless: "We don't have time for good design" (danger zone)
- Inadvertent-prudent: "Now we know how we should have built it"
- Inadvertent-reckless: "What's architecture?" (fire the dev lead)
Tech debt prioritization matrix:
| Impact |
High Frequency |
Low Frequency |
| High Impact |
Fix NOW |
Fix this quarter |
| Low Impact |
Fix when touching that code |
Probably never |
The 20% rule: Allocate 20% of engineering capacity to tech debt reduction. Non-negotiable. It compounds.
5. Team Scaling
Engineering team structure (by stage):
| Stage |
Team Size |
Structure |
| Pre-seed |
1-3 |
Everyone does everything |
| Seed |
3-8 |
Full-stack generalists + 1 specialist |
| Series A |
8-20 |
2-3 squads, tech lead per squad |
| Series B |
20-50 |
Engineering manager layer, platform team |
| Growth |
50+ |
Multiple orgs, principal engineers, architects |
Hiring priorities by stage:
- First 5: Generalists who can ship fast
- 5-15: First specialists (DevOps, security, data)
- 15-30: First engineering managers, senior ICs
- 30+: Platform team, architecture review board
Engineering culture essentials:
- PR review within 24 hours
- Deploy to production daily (or faster)
- Blameless post-mortems
- Document decisions (ADRs)
- Knowledge sharing (tech talks, pairing)
6. Security Architecture
Security by stage:
| Stage |
Must Have |
Nice to Have |
| Pre-seed |
HTTPS, auth, input validation |
Pen test |
| Seed |
+ secrets management, RBAC, backups |
SOC 2 prep |
| Series A |
+ SOC 2, dependency scanning, incident response |
Bug bounty |
| Series B+ |
+ SIEM, WAF, security team |
ISO 27001 |
CTO Metrics Dashboard
| Category |
Metric |
Target |
Frequency |
| Velocity |
Deployment frequency |
Daily+ |
Weekly |
| Velocity |
Lead time for changes |
<1 day |
Weekly |
| Quality |
Change failure rate |
<5% |
Weekly |
| Quality |
Mean time to recovery |
<1 hour |
Per incident |
| Health |
Tech debt ratio |
<20% of sprint |
Monthly |
| Health |
Test coverage |
>80% critical paths |
Monthly |
| Team |
Engineering satisfaction |
>7/10 |
Quarterly |
| Cost |
Infrastructure cost / ARR |
<15% |
Monthly |
Red Flags
- Deployment takes more than 30 minutes
- No one understands a critical system (bus factor = 1)
- "We'll fix it later" is the most common phrase
- Engineers spend >30% of time on toil (manual processes)
- No monitoring/alerting on critical paths
- Production incidents happening weekly
- Tech stack chosen by resume-driven development
Reference Files
references/architecture.md — System design patterns, ADRs, scaling strategiesreferences/tech-debt.md — Tech debt categorization, prioritization, reduction strategiesreferences/team-scaling.md — Hiring, team structure, engineering culturereferences/stack-selection.md — Technology evaluation frameworks, default stacks
1---2name: cto-advisor3description: Technical leadership for startup CTOs. Use when the user mentions architecture decisions, tech stack selection, build vs buy, tech debt management, team scaling, system design, infrastructure, security architecture, engineering process, code review standards, or any CTO-level technical decision. Also triggers on: CTO, technical architecture, microservices, monolith, database selection, API design, scaling, DevOps, CI/CD, engineering hiring, tech debt, code quality, system reliability, SRE, incident response.4---56# CTO Advisor78Technical leadership frameworks for startup CTOs. Balance engineering excellence with business reality. Simple > clever. Boring technology wins.910## Keywords1112CTO, chief technology officer, architecture, tech stack, build vs buy, tech debt, team scaling, system design, microservices, monolith, database, API design, scaling, DevOps, CI/CD, engineering hiring, infrastructure, security, code quality, SRE, incident response, performance, reliability1314## Core Responsibilities1516### 1. Architecture & System Design1718**Architecture decision process:**191. Define constraints (team size, budget, timeline, scale requirements)202. List realistic options (what can this team actually build and maintain?)213. Evaluate tradeoffs (performance, cost, complexity, hiring, vendor lock-in)224. Document the decision (ADR — Architecture Decision Record)235. Plan migration path (if changing existing system)2425**Monolith vs Microservices decision tree:**26- Team < 10 engineers? → Monolith27- Single product? → Monolith28- Need independent deployment of components? → Consider microservices29- Can you afford the operational overhead? → If no, monolith30- Clear bounded contexts with different scaling needs? → Microservices make sense3132**Database selection:**3334| Need | Recommendation |35|------|----------------|36| General purpose, relational data | PostgreSQL |37| Document store, flexible schema | MongoDB |38| High-speed caching | Redis |39| Full-text search | Elasticsearch / Meilisearch |40| Time-series data | TimescaleDB / InfluxDB |41| Graph relationships | Neo4j |42| Simple key-value at scale | DynamoDB |43| Analytics/OLAP | ClickHouse / BigQuery |4445**The default stack for startups:**46- Backend: Node.js/TypeScript or Python/FastAPI47- Frontend: React/Next.js or Vue/Nuxt48- Database: PostgreSQL + Redis49- Infrastructure: Railway, Render, or Vercel (avoid AWS complexity early)50- CI/CD: GitHub Actions51- Monitoring: Sentry + basic metrics5253### 2. Tech Stack Selection5455**Evaluation criteria:**5657| Factor | Weight | Questions |58|--------|--------|-----------|59| Team capability | 30% | Can the team build and maintain this? |60| Hiring pool | 20% | Can we hire for this technology? |61| Maturity | 15% | Is this battle-tested or bleeding edge? |62| Performance | 15% | Does it meet our scale requirements? |63| Cost | 10% | Total cost of ownership? |64| Lock-in risk | 10% | How hard is it to switch later? |6566**The "boring technology" rule:** Choose technology that's proven, well-documented, and has a large community. Save your innovation tokens for your product, not your infrastructure.6768### 3. Build vs Buy Analysis6970**Decision framework:**7172| Factor | Build | Buy |73|--------|-------|-----|74| Core to your product? | Build if core differentiator | Buy if commodity |75| Team expertise? | Build if you have the skills | Buy if it's outside your domain |76| Time to market? | Build if no time pressure | Buy if speed matters |77| Customization needs? | Build if highly custom | Buy if standard works |78| Long-term cost? | Build if high volume makes it cheaper | Buy if low volume |79| Maintenance burden? | Build only if you can maintain it | Buy to offload maintenance |8081**Rule of thumb:** If it's not your core product and someone else does it well, buy it. Your engineering time is your most expensive resource.8283### 4. Tech Debt Management8485**Tech debt categories:**86- **Deliberate-prudent:** "We know this is a shortcut, and we know how to fix it later"87- **Deliberate-reckless:** "We don't have time for good design" (danger zone)88- **Inadvertent-prudent:** "Now we know how we should have built it"89- **Inadvertent-reckless:** "What's architecture?" (fire the dev lead)9091**Tech debt prioritization matrix:**9293| Impact | High Frequency | Low Frequency |94|--------|---------------|---------------|95| **High Impact** | Fix NOW | Fix this quarter |96| **Low Impact** | Fix when touching that code | Probably never |9798**The 20% rule:** Allocate 20% of engineering capacity to tech debt reduction. Non-negotiable. It compounds.99100### 5. Team Scaling101102**Engineering team structure (by stage):**103104| Stage | Team Size | Structure |105|-------|-----------|-----------|106| Pre-seed | 1-3 | Everyone does everything |107| Seed | 3-8 | Full-stack generalists + 1 specialist |108| Series A | 8-20 | 2-3 squads, tech lead per squad |109| Series B | 20-50 | Engineering manager layer, platform team |110| Growth | 50+ | Multiple orgs, principal engineers, architects |111112**Hiring priorities by stage:**113- **First 5:** Generalists who can ship fast114- **5-15:** First specialists (DevOps, security, data)115- **15-30:** First engineering managers, senior ICs116- **30+:** Platform team, architecture review board117118**Engineering culture essentials:**119- PR review within 24 hours120- Deploy to production daily (or faster)121- Blameless post-mortems122- Document decisions (ADRs)123- Knowledge sharing (tech talks, pairing)124125### 6. Security Architecture126127**Security by stage:**128129| Stage | Must Have | Nice to Have |130|-------|----------|-------------|131| Pre-seed | HTTPS, auth, input validation | Pen test |132| Seed | + secrets management, RBAC, backups | SOC 2 prep |133| Series A | + SOC 2, dependency scanning, incident response | Bug bounty |134| Series B+ | + SIEM, WAF, security team | ISO 27001 |135136## CTO Metrics Dashboard137138| Category | Metric | Target | Frequency |139|----------|--------|--------|-----------|140| Velocity | Deployment frequency | Daily+ | Weekly |141| Velocity | Lead time for changes | <1 day | Weekly |142| Quality | Change failure rate | <5% | Weekly |143| Quality | Mean time to recovery | <1 hour | Per incident |144| Health | Tech debt ratio | <20% of sprint | Monthly |145| Health | Test coverage | >80% critical paths | Monthly |146| Team | Engineering satisfaction | >7/10 | Quarterly |147| Cost | Infrastructure cost / ARR | <15% | Monthly |148149## Red Flags150151- Deployment takes more than 30 minutes152- No one understands a critical system (bus factor = 1)153- "We'll fix it later" is the most common phrase154- Engineers spend >30% of time on toil (manual processes)155- No monitoring/alerting on critical paths156- Production incidents happening weekly157- Tech stack chosen by resume-driven development158159## Reference Files160161- `references/architecture.md` — System design patterns, ADRs, scaling strategies162- `references/tech-debt.md` — Tech debt categorization, prioritization, reduction strategies163- `references/team-scaling.md` — Hiring, team structure, engineering culture164- `references/stack-selection.md` — Technology evaluation frameworks, default stacks
ceoimperiumprojects