Everyone told me to stop.
Not cruelly — genuinely, advisedly, with the kind of concern people reserve for someone they think is wasting their time. "You're a founder now, Gautam. Delegate the code." My co-founder at Seahawk Media said something similar around 2018 when we crossed a hundred active client projects simultaneously. The logic was sound: founders should think about systems, hiring, pipeline. Not pull requests.
I ignored that advice. And I'm glad I did.
---
The Moment I Almost Quit Coding (And Didn't)
Back in 2019 a client handed me a brief that still makes me laugh. A mid-sized e-commerce brand — I won't name them — wanted a complete WooCommerce rebuild, custom product configurator, the lot. Tight deadline. I assigned it to a developer on the team, confident this was exactly the kind of thing I should be stepping back from.
Three weeks in, the developer left. Personal reasons, completely understandable. But we had a half-built configurator, a client breathing down my neck, and a codebase only one person had fully understood.
I opened VS Code that Sunday at 7am and didn't close it until noon. I got through it. Not because I'm a hero — because I actually remembered the code patterns, the WooCommerce hook architecture, the way woocommerce_before_add_to_cart_button behaves when you've got a custom post type feeding product variations. I hadn't forgotten. I'd just been pretending I had moved on.
That project reshaped how I think about my role entirely.
---
What "Founder Who Codes" Actually Means
It doesn't mean I'm building every feature. I'm not. Seahawk has developers far better than me at specific things — animation, complex React state management, database optimisation at scale. That's not false modesty. It's true.
But coding as a founder means I never lose the feel of the work. There's a difference between managing a project and understanding one. When a developer tells me "this will take two weeks," I can ask the right question — "is that two weeks because the API authentication is genuinely complex, or because we're rebuilding something that already exists in a WordPress plugin?"
You can't ask that question from 10,000 feet. You just can't.
The Estimation Problem
Here's the thing about software estimates: they're stories developers tell themselves as much as they tell clients. I've seen a senior dev quote four days for a custom WordPress REST API endpoint that took six hours once I sat down with them and scoped it properly. Not because they were lazy. Because neither of us had dug into what the endpoint actually needed to do.
When you code regularly, your BS detector for estimates improves. Dramatically.
---
It Makes Me a Better Client, Internally
One thing nobody tells you about running an agency: your developers are your internal clients. You have to sell them on good decisions just like you sell external clients. And you lose that ability the moment you stop speaking their language.
I use Figma for design handoffs. I use Git (specifically GitHub, we moved everything there from Bitbucket in 2021). I write actual tickets in Linear with enough specificity that a developer can start work without a kickoff call. That last one alone has saved us probably 40 minutes per project, and we run a lot of projects.
None of that is possible if you've gone fully "big picture." You need to know what a developer needs in a ticket. You only know that if you've sat on the other side.
The Code Review No One Expects From the Boss
Occasionally I'll drop a PR comment. Not to micromanage — I make that explicit. But a note like "this filter is running on every page load, can we cache the result?" signals something important: I'm paying attention at the level that matters.
Developers respect that. Some are surprised by it. And honestly, the ones who are annoyed by it — that tells me something useful too.
---
The Tooling I Actually Use in 2024
My stack is embarrassingly unsexy for a tech founder. VS Code with a handful of extensions (Prettier, GitLens, PHP Intelephense). A local development environment running LocalWP — I switched from MAMP in 2020 and never looked back. Terminal for everything Git-related because I never fully trusted any GUI.
When I'm working on client projects I still reach for WordPress. We've built on Webflow, Shopify, custom Laravel — but WordPress is where I'm fastest, and speed matters when you're dipping in and out rather than doing 8-hour focused sessions.
I used Coolors.co last Tuesday to pull a brand palette for a quick fix on a client's landing page. Took me four minutes total. Would've taken an hour to brief a designer, wait, and review. That's the founder coding advantage in miniature.
---
What You Actually Lose When You Stop
Most founders who step away from the editor convince themselves they'll stay technical through osmosis. They'll absorb it from stand-ups and Slack threads. They won't.
Here's what actually happens:
- Your vocabulary drifts. "API," "webhook," "cache invalidation" — you start using these words without knowing what they mean in the specific context of your stack.
- You lose the ability to prototype. A two-hour coding session can answer a product question that three stakeholder meetings couldn't.
- You become dependent on developer availability for small decisions. Something that used to take you 20 minutes now requires scheduling.
- Developers notice. Not all of them will say it, but there's a subtle shift in how they engage with a founder who clearly hasn't touched the work in years.
I've watched this happen to people I respect. Good people who built genuinely technical agencies, then gradually abstracted themselves out of their own expertise. By year five they were running the business entirely and they were good at it — but they'd lost something they couldn't quite name.
---
The Counterargument (And Why I Disagree With It)
The strongest case against founder-coding is opportunity cost. Paul Graham has written about this in various forms — the idea that founders should do things that don't scale, but also that focus is the only real advantage an early-stage operation has.
Fair. Genuinely fair.
But I think that argument applies more cleanly to product founders at VC-backed startups than to agency founders and freelancers. Our context is different. We don't have a runway problem that coding distracts from. We have a quality and trust problem — and coding is part of how we solve it.
When Seahawk pitches a complex WordPress migration to an enterprise client, the fact that a co-founder can discuss database table structure and wp-config constants in detail is not a small thing. It changes the room.
---
How I Protect Coding Time Without It Becoming a Problem
This took me years to figure out. Genuinely. I used to code reactively — only when something broke or a developer was stuck. That's the worst of both worlds. You're in the code but stressed, never in flow.
Now I do this:
- Block 90 minutes on Monday and Thursday mornings. No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
- Keep a "founder's project" running at all times. Something small — a personal tool, a client micro-feature, an internal automation. Right now it's a Python script that pulls our project status from Linear and formats a weekly digest. 180 lines, nothing fancy.
- Review at least one PR per week. Even if it's just to read. Stay in the diff.
- Rebuild something from scratch once a quarter. A landing page, a plugin, a small integration. Whatever. The point is staying sharp on fundamentals.
The total time is maybe 4-5 hours a week. That's it. Nobody's suggesting you run sprints.
---
FAQ
Does coding make you a worse CEO or co-founder?
Only if you let it crowd out actual leadership responsibilities. The issue isn't coding — it's using coding as an avoidance strategy for the harder founder work: difficult conversations, hiring decisions, commercial thinking. If you're opening the editor when you should be talking to a churning client, that's a problem. But 4 hours a week on a Thursday morning isn't leadership negligence.
What if my team sees me coding and thinks I don't trust them?
Be direct about it. I've told my team explicitly: "When I write code, it's not a signal that I think you're wrong or slow. It's how I stay grounded in what we actually build." That conversation takes 90 seconds and mostly only needs to happen once.
Is this realistic for founders running larger teams?
Honestly, harder at 50 people than at 15. But the principle scales — even if the practice changes. At a certain size, "coding" might mean reviewing architecture decisions, doing one exploratory spike per quarter, or deeply understanding what's inside a Lighthouse performance report rather than writing the fix yourself. The point is: don't let technical fluency atrophy entirely.
When should a founder genuinely step back from the code?
When coding is blocking someone else from growing. If a developer is waiting on your PR review to merge their work, and you're consistently the bottleneck, that's the signal. Step back from the critical path. You can still write code — just not on the main branch at 2am.
---
Coding kept me honest. That's the simplest way I know to put it. When you can still read a diff, estimate a feature, and ship a small thing on your own — you see your own business more clearly. You know what's actually hard and what's just badly explained. That clarity is worth more than the four hours a week it costs.
Still opening the editor. Probably will until I physically can't.