by Ivo Fokke,

4 min

This is my GitHub contribution graph. Look at the left half, then look at May.

https://f050b6f123f6401e85d83cc1dfbf5d7f.objectstore.eu/lavvus/workspaces/2001/YGvZ93SKNIvpvGkuHB8KrW6gVb78IyxKCg7DYqaQ.png

I became a developer this year. At my age, with no bootcamp, no course, and nobody at any point asking me to reverse a linked list on a whiteboard. This spring I opened Claude Code for the first time and started building. In May I started putting that work into GitHub, and the graph started telling the truth about how much of it there is. So the left half of that graph is not me being lazy. It is me being a developer without telling anyone yet. Since the 1st of May there are about 1,100 commits under my name, across 18 repositories. A CRM. A shared inbox. An expense app. A marketplace. A World Cup site. A gluten scanner for my phone. Every one of them is running somewhere, and several of them have real companies on them.

I was never the person typing

I have been a founder and CTO for years. I know what software should do, I can follow code well enough to see what it is trying to do, as long as it is not the clever kind, and I have sat in enough postmortems to know where things break. What I was not, and what I never pretended to be, was the person who types it all day. That part went to a team, or a contractor, or a budget line, and everything I wanted queued up behind it.

Claude Code took that queue away, at least for prototypes, simple apps and the small jobs that never justified a developer's time. I describe what I want, it writes the code, I test it the way a user would, we argue about what it got wrong, and I ship. Not alone, to be clear: I still need people around me who stop me from shipping slop. It is not autocomplete. It is a colleague who does the typing while I do the product work: deciding what to build, saying no to most of it, reading every commit message, and asking why something is the way it is. Those commit messages say what changed and why in plain sentences, because I made that a rule early on, and they are the reason I still understand my own codebases months later.

The green squares are not a productivity brag. They are a receipt for the gap that closed between knowing what a tool should do and having the tool.

What that looks like

Two examples from the last few weeks.

Parly is the shared inbox I built for small teams that answer customer mail together and would rather do it from Slack than from a shared Gmail password. One of the teams on it runs a support desk, and at the start of September they asked for two things a plain inbox never gives you: which company a mail is from, and what kind of question it is. On the 2nd of September Parly had a helpdesk mode. Switch it on for a mailbox and every conversation carries the sender's company, detected from their email domain with the logo pulled from their own site, plus a category from a short list the team controls. Both are columns and filters in the inbox. They used it for two days and came back with a list: replies going out without the quoted history, screenshots that only opened through the Downloads folder, filters that reset on every visit. All fixed by the 4th of September. A week, from request to fixes in production.

Bonnie is newer. Photograph a receipt on your phone and Bonnie reads it and files the expense. Forward an invoice by email and it files itself. Company money and private money never mix, which is the rule most expense tools get wrong first. It grew out of a friend's single file prototype at the end of August. Two weeks and about 190 commits later it is live at usebonnie.com, with sign in, a phone app, an admin side and a mail door. It is in use, the first expense reports have been filed, and people have started recommending it to each other, which is the only kind of marketing I have done for it.

Feature, edge cases, field reports, a whole second product, all shipped and in production by a person whose job description does not contain the word developer. Not long ago that list would have been a quarter's roadmap and a hiring conversation.

What I actually get out of it

Not code. I get to act on what I know. Every product person I have ever worked with carries a list of things they are certain would help, and the list dies of queueing. Mine stopped queueing in May, and the graph is what that looks like.

Parly is at parlyparly.com, Bonnie at usebonnie.com.

Bratelement

Bratelement

I love wearing blue t-shirts.

I'm Ivo Fokke, an entreprenerd based in Amsterdam with a passion for digital privacy. I'm into logistics, delivery networks, continuously contemplating on a new t-shirt brand, and occasionally sharing my thoughts on this blog.

As a founder and investor I am actively involved in a couple of companies. These days I am the CIO of the Rapid Logistics Group, I am trying to make the web a more private place with Soverin and I recently kick-started a blogging service called Lavvus... well, you are actually looking at it :).

You got to be starting something
Sometimes I (co-)invent, (co-)build and/or (co-)invest in innovative projects (preferably) by the next generation of entrepreneurs.