I Didn't Know What a Terminal Was. Now I Ship Software.

Starting with Claude as a brain

My background is building companies, not building software. So I started where anyone can start: I used Claude as something to think with. Not to write code — to explain things. What is a repository. What does deploying mean. Why does anyone need a database separate from the application.

The unlock was not that the answers were good, though they were. It was that I could ask the stupid question. The one you will not ask a developer because you can feel their afternoon draining away, and the one you cannot Google because you do not yet know the words for it. I asked hundreds of those. Nobody sighed.

Then I asked it to explain Claude Code to me, which is where it stopped being a conversation and started being a workshop.

What changed with Claude Code

Claude Code taught me GitHub, Vercel, Supabase, and every other piece I needed to understand along the way — but I did not have to do any of it. It did.

That is the sentence I would go back and tell myself two years ago, because it is the thing I had backwards. I assumed the sequence was: learn the tools, then build. The actual sequence was: try to build, hit the thing I did not know, have it explained in the exact context I was standing in, and watch it get handled.

Learning in that order is significantly faster, and it sticks better, because every concept arrives attached to a problem you currently have rather than to a chapter heading. I understand what a database migration is because one broke, not because I read about migrations.

What I actually built

The order here is deliberate, and I would recommend the same shape to anyone.

First, something for my son. A piano app — babymusicpads — because he liked pressing things that made noise. Zero stakes. Nobody was depending on it. If it had never worked, the only cost was an evening. That is exactly what a first project should be, and most people skip it because it feels unserious.

Then, something that annoyed me. receiptbot.io, a receipt app for my admin across my companies. A real irritation, small enough to hold in my head, and mine to get wrong. This is the step where it stopped being a hobby: something I built was now doing actual work.

Then I started solving real problems in my businesses. That is the whole progression. Toy, then irritation, then the things that genuinely matter — and by the time I reached the third, I had enough judgement to know when something was going wrong before it went live.

What I would tell someone starting

• Build something with no stakes first. A toy for your kid. The point is not the app — it is getting through an entire build once so the process stops being abstract.
• Ask the questions you would be embarrassed to ask a person. This is the single biggest advantage of learning this way and most people waste it by trying to sound competent.
• Do not learn the tools first. Learn them at the moment they block you. You will remember them, and you will skip the ninety percent you never actually needed.
• Pick the second project from your own irritation. Not a tutorial, not a startup idea. Something that wastes your time weekly. You will know immediately whether it works, because you are the user.
• Expect to not understand parts of it. I still do not understand everything running in my applications. That was uncomfortable at first. It is the same relationship most business owners have with their accounting software.

What this means for a company

If someone with no technical background can build working software, the interesting question is not whether your team could. It is which internal problems have been quietly filed under “we would need a developer for that” and left there for years.

Every company has a queue of those. The report someone assembles by hand every Monday. The spreadsheet that three people maintain and nobody trusts. The small internal tool that was never worth a developer's sprint and so never got made. None of those needed a developer. They needed someone with the problem and a few evenings.

This is not about replacing your engineers — they should be working on things that are genuinely hard. It is that the bottleneck moves from “who can build” to “who understands the problem well enough to describe it.” In most companies, the person who understands the problem best is nowhere near the engineering team.

That is the shift underneath everything we do at Deployed. The technology stopped being the constraint a while ago. The constraint now is whether anyone in your organisation has been given permission, and shown once, that this is something they are allowed to do.

Getting a team to that first build — the moment it stops being theoretical — is the whole point of the Deployed Kickstart. Everyone leaves having made something for their own job. The Partner programme is what turns the first one into a habit.

Frequently asked questions