Why Every CEO Needs a GitHub Repo

I started my career as a graphic designer in 1997. I learned a little HTML and a little CSS along the way, then partnered with a technical co-founder who built the software while I handled strategy, marketing, customer relationships, and business development. For most of my career, that division of labor was how a non-technical founder built a software company. I am no longer sure it will be an option in five years.

The shift that changed my mind

Until the first week of October, I had never made a meaningful contribution to a code repository. My GitHub history showed a single test deploy from an AI course back in April, and nothing else. Then something changed. I started building a new product myself, using Claude together with Vercel and Supabase, and the activity graph looks like a cliff.

Here is what my contribution counts looked like over a few days:

• October 3. 51 contributions, the first real day of work.
• October 4. 189 contributions.
• October 5. 316 contributions, which is my record.
• A few days later. 32 contributions already by the time of our call, squeezed into spare moments between other work.

Two weeks in, the product had 1,600 people signed up and 15 paying customers. That is small and early, and I would not tell you it is a finished business. What matters is that I built it myself, as a non-technical person, with no engineering team. I can open pull requests and merge them in spare moments, with Claude doing the heavy lifting on the code.

This is why I keep telling founders to get their hands dirty. The tools have reached the point where the gap between idea and working software is measured in days, and the people who understand what is possible will make better decisions than the ones who do not.

What this does and does not mean

When I shared this in our mastermind, one of the members, who is also a non-technical founder, offered a thoughtful pushback. His company has an established codebase and a large set of existing customers. He told the group plainly that he is not going to change anything in that codebase himself, because the odds of breaking something are far higher than the odds of improving it.

I agree with him, and that is not what I was suggesting. Nobody should be pushing changes to a production system that serves paying customers without the skills and safeguards to do it safely. My point was about a different kind of benefit.

Here is how I think about the difference between the two:

• Production code. Leave it to the people with the training, the tests, and the review process to make changes safely.
• Your own side project. This is a safe sandbox where a mistake costs you nothing, and where you can learn how modern development actually works.

The reason to build a side project is not to compete with your engineers. It is to understand their world well enough to manage it.

Accountability and the ability to spot weak answers

Anyone who has managed engineering without a technical background knows the uncomfortable feeling of not being able to evaluate what you are told. A project is late, and you hear that it was more complicated than expected. A feature is expensive, and you are told it is the only way. Without any hands-on experience, you have to take those explanations on faith.

As I told the group, having a side project in your own GitHub repository helps you hold engineering leaders accountable. You learn what a reasonable estimate looks like, what a pull request is, and how much work goes into a deployment. You also learn which AI tools exist and what they can do, which lets you ask a pointed question: are our engineers using the best tools available?

A member who is technical made a related point. Problems that were hard to solve a few years ago are much easier now because AI helps with almost everything. Another member described how his team has been using one coding assistant and is evaluating whether to commit fully to another, a sign that the right tool changes quickly and someone needs to be paying attention.

If you are a CEO who cannot yet evaluate what your engineering team tells you, here are the questions I would start asking:

• What AI tools is the team using? Ask for specifics, and whether they have tried the newest options.
• How much faster are we shipping than last year? If the answer is not much, find out why.
• Can you show me a demo, not a status report? A working demo is hard to fake.
• What would take this from weeks to days? Engineers who are using AI well will have an answer ready.

Questions like these only work if you understand enough of the answer to know when it sounds thin. That is the real value of a side project.

What it looks like when you manage without any hands-on knowledge

We saw the cost of the opposite situation in the same call. A non-technical founder is replacing most of his engineering group with an outside agency. He told us that, with his engineering manager also leaving, he is relying on the agency to say what it needs, and that makes him uneasy. Nothing about his plan is careless. It simply shows how exposed a CEO is when everything technical passes through other people, with no way to check it directly.

A founder with even a little hands-on experience has several advantages in that position:

• A sharper checklist. You know to ask about access, deployment steps, backups, and who holds the keys to each system.
• Faster detection of gaps. You notice when an answer skips a step.
• Better conversations with agencies. You can discuss scope and timelines in specifics, and a good agency will respect that.
• Less dependence on a single person. When a technical leader leaves, you are not starting from zero.

None of this requires deep expertise. It requires enough exposure to the vocabulary and workflow that the explanations you hear start to make sense.

What AI-assisted teams are reporting

The experience of other founders in the group supports the idea that AI-assisted development is now a normal part of building software. One member said that his team uses a coding assistant every day, that the team is happy with it, and that the rebuild of his entire product went smoothly on the engineering side. He is now looking at whether to commit fully to a single assistant. Another described a developer-facing product whose users are mostly working with AI coding tools when they discover it.

The takeaway is that your engineers, your customers, and your competitors are all working with these tools. If you do not understand them, you are making decisions about a world you have not seen. Spend a few hours there, and you will make better ones.

How to start this week

You do not need a plan that takes months. A few hours spread across a couple of weeks is enough to change how you see your own company. Here is a simple path:

• Pick a small, real problem. Choose something you actually need, such as an internal tool, a landing page, or a simple dashboard.
• Create a repository and connect a hosting service. Ask Claude to guide you through each step. It is patient, and it knows the vocabulary.
• Make changes and deploy them. Watching your work go live teaches you more than any article.
• Learn the terms as you go. Commits, branches, pull requests, merges, and previews will become familiar quickly.
• Share what you learn with your team. Showing your engineers that you are building too changes the tone of every technical conversation.

Another member told the group that his team has organized their entire onboarding process into small, written procedures that Claude can walk the team through. He noted that once all of that context exists, building a self-serve version for customers is easy. That is a good example of what becomes possible when leadership understands the tools.

Stay close to the tools

I said it to the group, and I will say it here. I encourage all of us who are non-technical to keep our hands dirty and stay up with as many of the tools as we can. The pace of change is not slowing down, and the CEOs who know what the tools can do will set a higher bar for their teams, ask better questions, and spot problems earlier.

You do not need to write production code, and you do not need to outbuild your engineers. You do need enough hands-on experience to know when the answer you are hearing does not add up. A repository of your own is the cheapest way I know to get there, and it only takes an afternoon to start.