Why I still write code as a co-founder
The conventional advice
You hire engineers. They write the code. You read pull requests. You spend your time on customers, hiring, and strategy.
This works for a venture-funded startup with a clear roadmap and 15 engineers. It does not work for an agency where the product IS the engineering decisions.
What I actually do
I write the proof-of-concept for every new service line we offer. Three reasons.
I know in 90 minutes whether a thing is buildable. A senior engineer needs a week of scoping. I save the company a week of scoping per service line.
I write the docs that the team uses. Documentation written by someone who has not built the thing is theoretically about the thing. Documentation written by someone who has built the thing is about reality.
I keep my taste sharp. The day I stop writing code is the day I start approving bad pull requests because I cannot tell the difference.
What this looks like in a week
- Monday morning: a client emails asking if we can build X. I spend 2 hours building a rough X.
- Monday afternoon: I either tell them yes with a price, or no with a refund.
- Tuesday: I document the rough X.
- Wednesday: a senior engineer takes the rough X and turns it into production code.
The total time from "client question" to "delivered feature" drops from 3 weeks to 4 days. The total cost to the company drops because we never quote work we cannot deliver.
When this stops working
When the company is large enough that a founder writing code becomes a bottleneck for the team's coordination, this pattern reverses. The advice "founders should stop coding" applies to that company. It does not apply to mine yet. It probably never will, because I am deliberately building a company small enough that the founder-as-IC pattern keeps paying.