The Startup CTO's Handbook

Original Article ↗ Hacker News Discussion ↗

Compliance, SOC2, and Auditability

  • Strong pushback on “start SOC2/PCI 6–12 months in advance”: several argue you should delay formal attestations until a large customer demands them.
  • Suggested approach: adopt basic best practices early (SSO, protected branches, minimal infra, certified vendors, central identity, secrets manager), which make future audits cheap if needed.
  • Distinction emphasized between being auditable vs being audited; many processes can be retrofitted if foundations are sane.
  • Tools like Vanta/Drata can streamline evidence collection but may push unnecessary controls (WAF, PHI scanning, heavy agents) beyond what SOC2/HIPAA actually require.
  • Some in accounting/supply-chain/ERP report the opposite experience: for deeply audited domains, not designing for auditability early is extremely costly later.

Databases, BI, and Scale

  • Many advocate defaulting to Postgres/MySQL managed services (RDS/Cloud SQL), using JSON support instead of NoSQL for most startups.
  • Read replicas + simple BI tools are seen as sufficient up to very large scales; “web scale” NoSQL is rarely justified early.
  • Concern raised that directly exposing app schema to BI/reporting creates a “public API” that freezes schema evolution; others accept this tradeoff until scale forces a proper analytics pipeline.

“Two Crews” (Feature vs Customer) Model

  • Heavy skepticism: splitting “feature” vs “customer” crews risks:
    • Shielding feature teams from consequences of their work.
    • Starving maintenance/customer teams of resources.
    • Slowing learning and degrading quality over time.
  • Some report success only with tight rotation (on-call/“hero of the week” models, or rotating customer-facing duty every few weeks/months) so everyone feels support pain and owns bugs.
  • General preference: developers should run and maintain what they build; rotations or shared responsibility beat permanent “shiny vs shitty” team splits.

CTO Role and Coding

  • Deep disagreement on whether a CTO should code:
    • One camp: at any non-tiny startup, CTO’s leverage is in strategy, hiring, roadmap, and external-facing work; sustained coding conflicts with manager-style interrupt-driven schedules.
    • Other camp: especially in early-stage startups, a technical, coding CTO is valuable; staying close to the codebase and customer pain leads to better decisions.
  • Several report that as teams grow (20–40+ people), leadership workload crowds out meaningful coding, often pushing folks either fully into management or back to IC roles.

Platform Teams and Over‑Engineering

  • Many anecdotes of platform teams becoming:
    • Over-abstracted, framework‑heavy, and slow.
    • Gatekeepers blocking product work until their ideal vision is ready.
  • Healthier pattern described as “buffet, not framework”: optional, well‑documented libraries and services that make the happy path easy without forbidding alternatives; success measured by enabling product teams, not enforcing purity.

Customer Support, Feedback Loops, and Meetings

  • Criticism of any framing where support is a “distraction”; for startups, intense customer support loads are a signal to improve product and process.
  • Recommended patterns:
    • Dedicated first-line support plus escalation to engineers.
    • Engineers periodically joining calls or rotations to absorb real user pain and drive better design.
  • Minor themes: skepticism of explainer video libraries vs text docs; insistence that “synchronous chat” should be explicit, not assumed; wariness of overly rigid meeting cadences and capital‑A “Agile” prescriptions.

Hiring, Culture Fit, and Use of the Handbook

  • Debate on “culture fit”: some see it as veiled discrimination; others as necessary to avoid rapid churn from obvious mismatches.
  • Acknowledgment that all hiring discriminates on some axis; tradeoff is communication efficiency/trust vs diversity of thought.
  • Several readers treat the handbook as a checklist or conversation starter (“what’s our answer to this?”) rather than a prescriptive bible, and criticize some content as better suited to later-stage, VC‑heavy startups than scrappy early teams.