Skill Issue Dev | Dax the Dev
search
Part of series: Founder Notes

Being CEO and still shipping code

9 min read verified human-written
Last updated:
Print view
Sections

The advice founders get most often, once you cross the line from “engineer with a side project” to “engineer with a company,” is: stop coding. Hire a CTO. Spend your time on customers and capital. Trust your team.

The advice is not entirely wrong. It’s just incomplete. Almost all of it is written by founders whose product was a SaaS dashboard or a marketplace. The product I’m shipping is a cryptographic SDK that has to interoperate, byte-for-byte, with an on-chain Rust program that itself has to interoperate with a Groth16 verifier whose constraint system has to match the prover’s circuit. Stop coding is a luxury available to founders whose product is forgiving. Mine isn’t.

So I write code. I review every PR that touches the SDK core. I do not draft a single line of marketing copy without first having shipped something the marketing copy is allowed to be about. And — the part this post is mostly about — I have built an AI tooling layer that lets me hold that posture without becoming the bottleneck.

The false dichotomy

The version of “stop coding” that most founders absorb is something like: every hour you spend on code is an hour you’re not spending on customers, capital, or hiring. The math, framed that way, is brutal. Ten hours of code is ten hours of not closing the next round. So stop.

The math is wrong because the variables don’t trade off the way it implies. The hours are not fungible. My hours of code are not the same as the next senior engineer’s hours of code, in either direction. They are slower, because I context-switch more. They are more strategic, because I see the entire surface. They are more expensive per hour, because mine are also the hours that close customers. They are more load-bearing, because the parts of the codebase I touch tend to be the parts that determine whether the system is correct.

The right way to do the math is: which hours of code create disproportionately more leverage downstream? For me, those are:

  • Architectural calls on the SDK boundary. (One hour. Saves the team thirty hours of refactor in two months.)
  • Reading every PR that touches zera-core. (Fifteen minutes per PR. Catches a bug class that would otherwise reach production.)
  • Writing the canonical example file when a new module ships. (Two hours. Replaces a documentation effort that would otherwise be much longer and worse.)
  • Drafting the technical content the company says, in public, that it stands behind. (Most of the blog.)

Those four buckets, in aggregate, are maybe 8–12 hours per week. The rest of the week is the actual CEO job. The mistake is picking either all-code or no-code. The right answer is load-bearing code only, and being honest about which is which.

What I stopped doing

For the record — the things I had to give up:

  • I do not pick up tickets in the SDK that aren’t on the load-bearing path. The team is faster at them than I am.
  • I do not write tests anymore. Test coverage is a habit; tests are a downstream artifact of the habit. The team writes them and writes them well.
  • I do not own DX polish. Error messages, log formatting, CLI affordances — all owned by people who care more about them than I do at the moment.
  • I do not do code review on the wallet, the AMM, or the medical demo unless someone explicitly asks. Each of those has an owner whose taste I trust.
  • I do not personally set up the CI pipeline. (This was a hard one to give up. Give it up anyway.)

The pattern: I stopped doing the things that, if I disappeared for a week, the company would still ship correctly. I kept doing the things that, if I disappeared for a week, the company would ship something subtly wrong.

How AI fills the gap

The reason this posture is workable in 2026 and was not workable in, say, 2019, is that the personal leverage you can build on top of an AI coding workflow is the difference between a working CEO-IC schedule and one that quietly destroys the company.

I run two patterns and I think they’re both worth describing.

Pattern 1: Claude Code as a senior pair

Most of my SDK reviews now happen with Claude Code in the loop. I don’t mean “I ask the AI if the PR looks good.” I mean: I read the PR; I write a short prompt summarising what I think is happening and what I’m worried about; the model walks the rest of the codebase to either confirm or refute my worry; I make my call.

The leverage isn’t in doing the review faster. The leverage is in being able to express, in one paragraph, the part of the codebase I’m worried about, and have an agent that can read that paragraph plus the entire rest of the codebase faster than I can. The review I do at the end is the same review I would have done. The context-loading is what I outsourced, and context-loading was 80% of the time cost.

This works because Claude Code is good enough now to be boring. I don’t have to phrase things magically. I write the review like I’d write it to a senior colleague. The model reads the whole repo and comes back with the cross-references I need. That’s it. That’s the workflow.

Pattern 2: an MCP server over my own writing

This is the one I get asked about more.

I have three or four years of writing on this blog. There is, in that archive, the answer to most questions a reasonable person might ask me — what’s your stance on X, what was the architecture decision on Y, what’s your bullet point on supply-chain attacks for an investor deck. The thing is, when someone asks me one of those questions, the answer that ends up in my mouth is the recent answer, the one I happened to be thinking about that morning. The two-year-old version of me, who probably had a smarter take, doesn’t get to vote.

So I’m building (TODO: Dax confirm exact ship date — Q2 2026) lib.skill-issue.dev, an MCP server over the entire archive of this blog plus a small pinned set of references. It’s a Cloudflare Worker. It uses Vectorize for retrieval and Workers AI for embedding. It exposes three or four tools to any MCP-aware client: search, fetch, summarise, cite. Every Claude Code session I run can hit it. Every customer call where I want to find the version of a take I had eighteen months ago can hit it.

The point of building this is not that the world needs another personal RAG system. The point is that the company is going to grow, and the founder’s writing is the cheapest possible scaling mechanism for what the founder thinks. The MCP server is the API I built so my own context isn’t bottlenecked on me being awake.

Same MCP pattern that ships in zera-sdk’s mcp-server, incidentally. We dogfood our own thesis.

The team thing

A short word on the part that doesn’t fit cleanly into either of the patterns above.

Being a technical CEO who still ships code only works if the team understands the boundaries. The team has to know which parts of the codebase are mine to push back on (the SDK core, the cryptographic surface, the visible API) and which parts are theirs (everything else, increasingly). If I drift into reviewing CI changes, I am taking work away from people who are good at it, and the message I’m sending is “your work isn’t really yours.” That’s poison.

So I draw a hard line. The architecture diagram of the SDK has my fingerprints on it. The CI pipeline has someone else’s. The wallet’s UI has someone else’s. The Solana program has the person who wrote it. Mine to push back on is a small list, deliberately. The list is also visible to the team — they know what it is.

This was harder to learn than I’d like to admit. I went through a phase where I was reviewing too many PRs because reviewing felt productive. The team got slower, not faster. The fix was to delete most of my review notifications and explicitly hand ownership of three subsystems to three people. Speed went up. My satisfaction went down for about two weeks and then went up permanently.

The shape of a week

If you’re curious how this actually allocates: a representative week, give or take, is roughly:

  • 8–12 hours: load-bearing code (per the bullets above)
  • 6–8 hours: customer + investor calls
  • 4–6 hours: 1:1s and team async (Linear, GitHub, Slack)
  • 4–6 hours: hiring loop (sourcing, screens, panels)
  • 2–4 hours: writing — public posts, founder letters, customer briefs
  • The rest: triage, email, the long tail of things a CEO has to look at.

I don’t believe in the heroic 80-hour week, but I do believe in the consistent 50–55-hour week, and I think this allocation is roughly that. TODO: Dax adjust if reality drifts.

Why this is the post I keep getting asked for

Every founder I talk to who came up technical wants permission to keep coding. The permission is, of course, theirs to give themselves — but the framing in the broader founder canon (the Hard Thing, High Output Management) is mostly written for SaaS founders whose products do not require their hands.

Cryptographic infrastructure is not SaaS. The product is correct or it is not. The CEO of a company shipping correctness should keep their hands in the codebase. The trick is the AI-augmented workflow that makes the math work — context-loading via Claude Code, archive search via your own MCP server, and a hard list of subsystems where you, personally, are the last review.

That’s the entire post. Keep coding. Build the AI scaffolding around yourself that lets you keep coding. Stay out of the parts of the codebase that aren’t yours. Trust the team on those parts. Be loud about which parts are yours.

Further reading

Related

Hire me — book a 30-min call $ book →