Skip to content

The Startup Handbook

Building a company, through a CTO’s eyes

I was part of a startup as it grew from six people to 400 and became a unicorn. I am now building another from scratch as CTO. This handbook is where I want to put what I learned from both, what I think we should do, and how we put those decisions into practice.

Each chapter follows one part of building and running a company, seen through a CTO's eyes. Most examples come from my experience. I'll show how those practices can look at different company stages, since what helped at 400 people may be more than a team of ten needs.

Why I wanted to build again

I spent a decade at my first startup, where I built its AI and research team. I saw early colleagues leave, watched the company change as it hired managers and lived through repeated rounds of layoffs. Unicorn status could sit alongside very ordinary worries about whether you would still have a job.

I still liked the early work: figuring out a problem with a small group, trying something and learning from people who might use it. I wanted to do that again, with a clearer idea of what I was choosing. I tell the longer story in Ten Years in Startups: Why I'm Building Again.

When I chose the next company, I wanted enough funding to give the team time to build and access to customers who could help us test our assumptions. Under the plan at the time, we had at least three years of funding with a full team, plus design partners and sales channels already in place.

The work was greenfield, I trusted the founding team, and I was joining early enough to influence how we built the company. After years in a larger organisation, I wanted to be close to those decisions again.

I also thought differently about my own financial position. Secondary sales at the first startup eventually gave some people access to money from their shares; the valuation alone did not. My preference now is for base pay I am comfortable with and equity on top. I want to understand the possible upside without needing it to justify the everyday arrangement.

Building the company

I knew I was signing up to help build a company, including the work beyond engineering. I was happy to take responsibility for the UK entity, payroll and security policies. Anyone taking a founding role should expect work like this alongside building the product.

I came from research and machine learning, and some of that work was new to me. I had never run production infrastructure, been the name on a security policy or submitted a VAT return. Learning how to do those things was part of getting the company started.

Becoming a CTO started from the fact that nobody handed me a manual. Those posts describe what the job asked of me in the first year: the self-doubt, the trust I had left people to infer, the planning we redid four times and the controls I wrote before we had them.

The rules we agreed, the templates and the cadences are scattered through those stories. This handbook collects them by subject, alongside what I have learned and what I would do differently. Beginnings starts once the company is incorporated and the funding is in place, and asks what comes next.

These are living posts

These chapters are pages I expect to keep editing as we change how we work, as something stops working, or as I find out I was wrong.

That changes a few things about how to read them:

  • The date at the top of a chapter is its latest revision.
  • The unfinished parts are listed at the end of each chapter. I would rather show the gap than fill it with advice I have not tested.
  • I revise sections in place, so an older link still points at the current version. The Updates page records new chapters, substantial new sections and changes in methodology.
  • New chapters will appear in the index below as I add them.

If you are reading this a year after the date above and a chapter has not moved, treat it with the suspicion you would give any wiki page nobody has touched.

How each chapter is laid out

I try to distinguish experience from recommendation. Where I describe something we did, I give the context. Where I say what I think we should do, it may still be a proposal. The CTO's part runs through each subject: the decisions I own, where I need to work with others, and what I have to put in place.

Sections headed How I do it now describe my current startup practice, with proposals and unfinished work identified. As the company grows covers what I would change at a scale-up and why. I used this practical format in the engineering foundations. Writing down how I work makes the gaps visible, especially when the answer is “not yet”.

The People chapter covers hiring, onboarding and supporting people as their roles change. The Appendices chapter contains plans and meeting notes to adapt to your team.

The examples are starting points. At a startup, I want enough structure for a small team to make decisions and get work done. As it grows, I would revisit who owns each decision and how work passes between teams. I would copy the questions before the answers.

I leave teammates' names out, as I did in the series.

How I have organised the handbook

The first chapters follow the work from the first customers and hires through decisions, delivery and production. The later chapters cover the routines, records and personal habits that keep the company running. Templates are collected at the end.

The chapters

  1. Beginnings. You have an idea, a company and funding. What comes next?
  2. People. Hiring, onboarding, feedback, performance and helping people grow.
  3. Decisions. Who decides, what ownership requires and how we keep agreements clear.
  4. Delivery. Turning priorities into goals, tracking the work and releasing changes safely.
  5. Production. Runbooks, checklists, releases, incidents and support once customers depend on the product.
  6. Collaboration. Meetings, shared context and the division of work as a team grows.
  7. Operations. Shared knowledge, handovers, compliance and the recurring work beyond engineering.
  8. Compliance. The policies, procedures, records and Notion workspace behind SOC 2 and ISO 27001, as checklists.
  9. Habits. How I use my time, follow through on commitments and hand work over as the role changes.
  10. Appendices. Goals, onboarding plans, one-to-one notes, handovers and meeting agendas to adapt.

Templates

Much of what these chapters describe lives in our Notion workspace as registers, forms and checklists; Compliance describes how it is organised. If you want any of it as a template, get in touch and I will share the structure with our own content removed.

What is missing

On-call, what our post-mortems taught us and the finance and legal work that landed on me still need fuller accounts. I have listed the gaps at the end of each chapter so they are easy to find, and I will fill them in as I work out what I think.

If something here is wrong, or you do it differently and it works, I would like to hear about it. That is most of the reason for writing it in public.

Changelog

  • 11 November 2026: Added the Compliance chapter, covering SOC 2 and ISO 27001 preparation: policy and procedure checklists, recurring reviews, evidence registers and a Notion workspace for keeping it all organised.