NoahGuides
Guides for startup CTOs and technical founders
Field notes from building and leading engineering teams — as co-founder and CTO of Veryable, and from hundreds of conversations with founders on the Code Story podcast. Each guide answers one question directly, then goes deep.
Leadership
The CTO role, hiring leaders, and how the job changes as the company grows.
Fractional CTO vs full-time CTO: which does your startup need?
Hire a fractional CTO when you need senior technical judgment on a handful of decisions and you cannot yet justify an executive salary or equity grant. Hire a full-time CTO when technology is the product, the roadmap runs continuously, and the person needs to build and own a team.
7 min read
CTO vs VP of Engineering: how the two roles actually differ
A CTO owns technical direction — architecture, platform bets, and the technology story told outside the company. A VP of Engineering owns execution — delivery, process, hiring throughput and team health. One person holds both jobs until roughly 15–40 engineers, then the split becomes urgent.
6 min read
When to hire a CTO for your startup
Hire a CTO when technology is a durable part of your competitive advantage and no one on the founding team can make architecture, hiring and security decisions with confidence. Before that point, a fractional CTO or a strong senior engineer is usually the better spend.
7 min read
Scaling an engineering team from 5 to 50
Engineering teams break at predictable sizes — around 8, around 20 and around 50 — and each break is a communication problem before it is a process problem. Add structure one step ahead of the pain, and add only the process that removes a specific failure you can name.
8 min read
Teams
Structuring, hiring and measuring an engineering organisation.
Startup engineering team structure that actually ships
Structure a startup engineering team around customer outcomes, not technology layers. One cross-functional team until roughly ten engineers, then split by product area with clear ownership, and add a platform team only when duplicated infrastructure work becomes the bottleneck.
7 min read
How to hire your first engineers
Hire your first engineers for slope and range rather than for stack familiarity: people who learn fast, work close to customers, and can own a problem end to end. Run a short, consistent loop built around real work, and make the decision on evidence rather than on rapport.
8 min read
Engineering metrics that matter (and the ones that don't)
Track a small set of team-level metrics: deployment frequency, lead time for changes, change failure rate and time to restore, plus one customer-facing reliability measure. Never measure individual engineers by commits, lines or story points — those numbers are trivially gamed and destroy trust.
6 min read
Building
Architecture, MVPs, vendors, diligence and technical debt.
How to choose a tech stack for a startup
Choose the boring, well-supported stack your team can hire for and debug at 2am. The only choices worth agonising over are the ones that are expensive to reverse — your data model, your authentication boundary and your core integrations; everything else can be swapped later.
7 min read
MVP development: how to build the right first version
An MVP is the smallest thing that lets a real user complete a real job and lets you learn something you cannot learn by asking. Scope it to one workflow, one user type and one measurable outcome, and aim to have it in front of customers in eight to twelve weeks.
7 min read
Build vs buy: a decision framework for technical leaders
Build what customers pay you for; buy everything else. If a capability is not part of your differentiation, the total cost of owning it — maintenance, on-call, security and opportunity cost — will almost always exceed the licence fee.
6 min read
Technical due diligence checklist for startups
Technical due diligence assesses whether the technology can support the plan the company is raising against. Reviewers look at architecture and scalability, code and delivery practice, security and compliance, key-person risk, and the credibility of the roadmap and its costs.
8 min read
Managing technical debt without stopping the roadmap
Treat technical debt as a cost line, not a moral failing: quantify what each item costs you per month in slowed delivery, incidents or risk, then pay down the expensive ones continuously. A steady 10–20% of capacity beats an annual cleanup sprint that never gets scheduled.
6 min read