Startup CTO Checklist: First 90 Days, Tech Stack, Hiring, and Process Decisions

The first 90 days as a startup CTO set patterns that persist for years. The decisions you make — or avoid — about tech stack, team process, and hiring shape what's possible later.

Most first-time CTOs either move too fast (over-engineering for scale that doesn't exist) or too slow (avoiding decisions until they're urgent). This checklist is calibrated for the reality of a Series A or early Series B startup: you have product-market fit evidence, a small engineering team (5–20 engineers), and 12–18 months of runway.

---

Days 1–30: Listen Before Deciding

The instinct is to come in and fix things. Resist it. Your job in the first 30 days is to understand the current state accurately — not to improve it yet.

What to Learn

Codebase audit:

# Get a quantitative baseline
# Lines of code by language
cloc src/ --by-file-by-lang

# Test coverage
npm run test -- --coverage

# Dependency audit
npm audit
pip-audit  # Python

# Cyclomatic complexity
npx ts-complexity --threshold 5 src/**/*.ts

# Duplication
npx jscpd src/ --threshold 3

# Dependencies age
npx npm-check-updates --format group

Team interviews (30-minute 1:1s with every engineer):

• "What slows you down the most each week?"
• "What are you most proud of that we've built?"
• "What would you change if you had a week of free time?"
• "What does the team do that doesn't make sense to you?"
• "What do you think we should stop doing?"

Product and business context:

• Where are users dropping off?
• What are the top 3 support tickets per week?
• What features are on the roadmap that scare the engineering team?
• What are the security and compliance obligations?

What to Document (Days 1–30)

# Engineering State of the Union — [Date]

## Strengths
- [What's actually working well]

Debt Inventory

Immediate Risks

• [Things that could cause an outage or data loss in the next 30 days]

Team Sentiment

• [Anonymous-ish summary from 1:1s]

Key Decisions Needed

• [Things that need a decision from you or the CEO in the next 60 days]

---

Days 31–60: Fix the Acute Problems

By day 30 you know what's broken. Now fix only the things that are urgent — not the things that are annoying.

Criteria for a 30-60 day fix:

• Could cause an outage or data loss
• Is actively slowing the team more than 20% per week
• Creates legal or security liability

Common Acute Fixes

No monitoring:

// Before anything else — you need to know when production breaks
// Minimum viable observability stack:

// 1. Error tracking (15 minutes to set up)
import * as Sentry from "@sentry/nextjs";
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  // Capture 100% of errors in production
  beforeSend: (event) => {
    if (process.env.NODE_ENV === "production") return event;
    return null; // Don't send dev errors to Sentry
  },
});

// 2. Uptime monitoring (5 minutes — use Checkly or Datadog synthetics)
// 3. Structured logging (1 hour)
// 4. On-call rotation (15 minutes — PagerDuty or OpsGenie)

No deployment process:

# Minimum viable CI/CD — even if it's just this
# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  test-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
      - run: npm run build
      - name: Deploy
        run: |
          # Whatever your deployment is — Vercel, ECS, Render
          # The point: tests must pass before deploy

Secrets in code:

# Audit for hardcoded secrets
git log --all --oneline | xargs -I {} git show {} | \
  grep -iE "(password|secret|api_key|token)\s*=\s*['\"][^'\"]{10,}"

# Install git-secrets or truffleHog for ongoing scanning
pip install truffleHog
trufflehog git file://. --only-verified

---

Days 61–90: Set the Foundation

By day 60, acute fires are handled and you understand the landscape. Now set the foundations that will scale.

Tech Stack Decision Framework

Avoid the temptation to rebuild everything with your preferred tech. Evaluate changes against this criteria:

interface StackChangeEvaluation {
  technicalBenefit: {
    performanceGain: number;       // % improvement
    developerProductivity: number; // % faster feature delivery
    maintenanceCost: number;       // % change in maintenance burden
  };
  migrationCost: {
    engineeringDays: number;
    riskLevel: "low" | "medium" | "high";
    rollbackComplexity: "trivial" | "complex" | "impossible";
  };
  teamImpact: {
    newHiresEasier: boolean;    // Is this tech easier to hire for?
    teamFamiliar: boolean;       // Does current team know this?
    learningCurveWeeks: number;
  };
}

// Decision rule:
// Only change the stack if:
// 1. migrationCost.engineeringDays < 6 months of productivity gain
// 2. riskLevel is "low" or "medium" with tested rollback
// 3. teamFamiliar OR learningCurveWeeks < 4

Reasonable startup stack (2026):

Process Decisions to Make in Days 61–90

1. Define "done"

# Definition of Done — [Company Name]

A feature is done when:
- [ ] Code reviewed by at least one other engineer
- [ ] Unit tests written (coverage maintained at ≥ 80%)
- [ ] No new HIGH or CRITICAL Sentry errors in staging
- [ ] Feature flag implemented for risky changes
- [ ] Runbook updated if it changes deployment behavior
- [ ] Product manager has demo'd and signed off

2. Establish sprint rhythm

Weekly is the right sprint length for most startups. Two weeks is too slow — you lose the feedback loop. Daily is too fragmented — context-switching kills output.

# Weekly Rhythm

Monday: Sprint planning (60 min max)
Wednesday: Mid-week sync — blockers only (20 min standup-style)
Friday: Ship + demo (whatever is ready to show)
Friday: Retrospective (30 min — keep, stop, start)

3. Incident process

Before you have your first major incident, establish the process:

# Incident Severity Levels

P0: Production down or data loss — all hands, 15-min updates to CEO
P1: Major feature broken for all users — engineering team, 30-min updates
P2: Feature degraded for some users — single owner, hourly updates
P3: Minor issue — ticket created, normal sprint

---

The First 5 Hiring Decisions

Early hiring mistakes are expensive — both the cost of a wrong hire and the time lost managing them out.

Hire Order for a 5-person Engineering Team

Engineer #1: Senior full-stack — must be independently productive
Engineer #2: Senior full-stack or backend — covers different domain
Engineer #3: Frontend specialist or DevOps/platform
Engineer #4: Product engineer (strong design sense)
Engineer #5: Your first specialist (ML, security, data — based on product)

What to Screen For (Beyond Technical Skills)

// The 4 things that matter most for early hires:

interface EarlyHireRequirements {
  // Can they ship without a lot of hand-holding?
  autonomy: boolean;

  // Will they tell you when something is a bad idea?
  // (Yes-people are dangerous at this stage)
  constructivelyDisagreeable: boolean;

  // Do they care about the problem, not just the code?
  productMindset: boolean;

  // Can they work in ambiguity without constant direction?
  comfortableWithAmbiguity: boolean;

  // Technical skills — necessary but not sufficient
  technicalBar: "senior" | "staff";
}

Interview Structure for Early Hires

# Interview Process (5 steps, < 2 weeks total)

1. **Resume screen** (30 min) — CTO only. Looking for: shipped products, real companies, longevity.

2. **Async take-home** (3 hours max) — A real problem from your codebase.
   NOT: "implement a linked list reversal"
   YES: "here's a bug in our production code — find and fix it"

3. **Technical deep-dive** (60 min) — Walk through their take-home. Ask why they made choices.
   Probe: what would you do differently with more time?

4. **System design** (45 min) — Design something at the scale you'll hit in 18 months.
   Probe: what would break first, how would you fix it?

5. **Team fit** (30 min) — With 2 engineers who would work with this person.
   Ask team: "Is there any reason not to hire this person?"
   (Not "do you like them" — "is there a reason not to")

Decision within 48 hours of final round.

---

What Not to Do

Don't rewrite the existing product. Unless it literally cannot be extended (rare), rewrites take 3–4x longer than estimated and you lose institutional knowledge.

Don't hire a VP of Engineering before Series B. You need builders, not managers. A VP of Engineering who can't code will create process without output.

Don't run sprints without deploying. Velocity that doesn't ship is not velocity.

Don't build your own auth. Use Clerk, Auth0, or Auth.js. You will get it wrong, and the security cost is existential.

Don't skip documentation because "we'll do it later." Architecture Decision Records take 30 minutes each and save weeks of confusion later.

---

90-Day Scorecard

interface CTOScorecard90Days {
  // Observability
  productionErrorTrackingLive: boolean;
  oncallRotationEstablished: boolean;

  // Process
  ciCdPipelineRunningTests: boolean;
  definitionOfDoneDocumented: boolean;
  incidentSeverityDefined: boolean;
  weeklyRhythmEstablished: boolean;

  // People
  everyEngineer1on1Done: boolean;
  firstHireProcessDefined: boolean;

  // Architecture
  stackDocumented: boolean;
  technicalDebtInventoryCreated: boolean;
  top3SecurityRisksAddressed: boolean;

  // Product
  understoodTopUserPainPoints: boolean;
  alignedWithCeoOnTechStrategy: boolean;
}

If you can check all of these by day 90, you've laid the foundation for sustainable engineering growth.

---

See Also

• Technical Debt Management — debt prioritization framework
• Engineering Hiring and Team Building — interview process depth
• Team Topologies for Engineering Organizations — org design
• Engineering Onboarding Programs — getting new hires productive fast

---

Working With Viprasol

Many startup CTOs are strong individual contributors who haven't managed an engineering organization before. We work alongside technical leaders to audit codebases, design scalable architectures, and build the engineering processes that let teams ship fast without accumulating catastrophic debt.

Engineering consulting → | Web development services →