Looking for the contracts platform? It's now called legalflow.ai! Read more
Blog

Why I Started Programming After 10 Years in Tech Entrepreneurship

A founder's journey from 'too complicated' to 'full control'

For ten years, I tried to bring technology and law together with Legalloyd. We built a platform, generated hundreds of thousands of contracts, and worked with amazing developers. But there was one thing I could never do myself: program. Simply too complicated.

The Frustration of Not Knowing

In the beginning, I dove into the simple syntax we used for programming contracts. That was manageable. But the real programmers were always ten times better at it than me, so I stopped trying. I focused on what I could do: being a product owner. For years, I managed developers, handled product development, wrote user stories, and set priorities. I read books about Clean Code and Scrum, and together with great colleagues, I always tried to establish good processes.

But truly controlling, truly knowing if code was good—I couldn’t do that. I always pushed for documentation, made sure there were good descriptions with code so developers could read them quickly. But I couldn’t really assess that documentation either, because I didn’t truly understand what it was about. As an entrepreneur, that’s a vulnerable position. You’re dependent on others for something that’s the core of your product.

The Spark

Last year, something happened. Maurits Fornier, a friend and founder of Patroon, said to me: “You should just start programming. With AI, it’s possible now.” I was skeptical. After ten years, I’d long written myself off as “not technical enough.”

Around the same time, we decided to split off the platform from the law firm. Legalflow.ai became an independent company, and I needed a new website for Legalloyd. Maurits said: “I’ll make it for you, but we’ll use that as an opportunity to teach you how to do it. So you can manage your website yourself.” Said and done.

The Instructions That Changed Everything

What followed was surprisingly simple. Maurits sent me a list of tools to install: Homebrew, npm, Node, TypeScript, Supabase, Python, Claude Code, Codex. Then create a folder in VS Code, open the terminal, start Claude—and then you’re in the programming agent. That was it. With AI’s help, I could get incredibly far from there.

The next steps were installing React, setting up Vite, configuring Tailwind CSS, adding Shadcn components. And before you know it, you have a working application.

A Soccer Team as Learning Ground

I realized that for a first project, it was better not to immediately do something legal. Too much pressure, too many expectations, too close to my daily work. So I started programming a team manager for my son’s soccer team.

That turned out to be a golden choice. Every week I have to create a lineup for a team of 11-year-olds, and that became my use case. It’s incredibly fun to work from a concrete idea and a weekly need. You play with functionality, with look and feel, with the interaction between frontend and backend, with setting up a database. All tasks you encounter in any serious project, where you can really dive deep—without immediately trying to make a professional application.

It takes the pressure off. You’re allowed to make mistakes. You’re allowed to experiment. And meanwhile, you learn exactly the skills you’ll need later. And, last but not least, you’re a hero at home because you “make websites.”

The Real Lesson: Understanding Before Speed

At the SaaS Summit late last year, there were presentations about vibe programming and how professional developers can make that part of their process. What struck me—and I could finally follow this because I now can program somewhat myself—was that hard skills as a programmer are becoming increasingly necessary. The stories about AI slop and spaghetti code are legion.

And that brought me to an insight that actually connects everything I’ve learned over the past ten years: you can only make a good product, or design a good service, if you truly understand the underlying subject matter.

This applies equally to AI in legal processes. If you’re not a well-trained lawyer, or very well-versed in the intended end result, then it’s uncertain whether you’ll achieve a good result with AI. You can’t assess if it’s correct. You can’t see where the nuances are. You miss the errors that inevitably creep in.

Exactly the same applies to programming with AI. Precisely because I see what’s possible with AI, I also want to be able to truly assess whether the code is sharp, clean, and functions well. You want to force yourself to reach a deeper level of understanding, so that afterwards you can achieve results faster with AI’s help.

It’s a paradox: to use AI well, you first need to understand what you’re doing yourself. The acceleration only comes once you’ve mastered the basics.

The Practice: From Chaos to Control

Maurits gave me a series of principles that I still use daily. The most important is treating Git as checkpoints: make a commit after every substep, not because you have to, but because you can always return to it if something breaks. Claude helps you make commit messages based on your work.

For larger features, you start a new branch—you want to isolate things that could break everything. If it works, you merge into your development branch. Claude helps resolve conflicts. Your CLAUDE.md file should be well-organized but not too long; you fill it in gradually with short instructions. This becomes your memory for the project.

What also helps enormously are subagents for specific tasks. I have one for UI polish that opens a browser with Puppeteer, looks at my work, takes screenshots, and feeds those back to Claude—so Claude can also “see” and not just have the code as a basis. Another subagent specializes in bug fixes and monitors consistency in my codebase.

The Result

For the first time in 15 years of entrepreneurship, I don’t have an external party making or managing my website. That may sound small, but for me it’s revolutionary.

I can now make changes whenever I want. I understand what’s in my codebase. I can assess code quality. I can build new features without being dependent on third parties. I deploy my website via GitHub and Vercel with one push. And perhaps even more important: I can now finally read the documentation and understand what it’s about.

What I Would Tell Other Founders

If you’ve been thinking for years that programming is “too difficult” for you, I get it. I thought so too. But the combination of AI assistance and good guidance from someone who teaches you the right fundamentals makes the difference.

You don’t need to become an expert. You only need to know enough to understand what’s in your codebase, to check if the quality is good, to make small changes yourself, and to no longer be completely dependent on third parties. That’s already enough to have a completely different position as a founder.

The time investment? A few months of occasionally spending an evening or weekend on it. And now, six months later, it’s become a natural part of my work.

Start with something fun. A hobby project. A tool for your sports club. Something you play with every week. The rest follows naturally.


Sjors Dobbelaar is the founder of Legalloyd, a law firm for the innovation economy. He writes about entrepreneurship, legal tech, and—recently—also about programming.

StudioCareersBlog