How AI Became My Dev Team (And Why I Still Make The Decisions)

I run a construction company in West London. I also build software: a classifieds platform, a server-security tool, a couple of content tools. I am not a programmer in the way people usually mean it. I can't write most of that code from memory, and I've stopped pretending that I need to.

My working rule fits on one line: I imagine, describe, verify. AI codes. I decide.

This post is about what that actually looks like day to day: where AI genuinely does the work, and where I refuse to let it.

Where it started: paying for code I couldn't read

My first attempt at software was the usual one. I bought a ready-made classifieds script and hired freelancers to customise it. Then more freelancers, when the first ones disappeared or delivered something that half-worked.

The problem wasn't that they were bad people. The problem was that I couldn't judge their work. If you can't read code, a clean, maintainable feature and a duct-taped one look exactly the same: a button that does what it's supposed to do, until the day it doesn't.

That's the trap AI could easily recreate. If I just accept whatever it writes, I'm back where I started, only faster.

The rewrite: fast to build, slow to finish

The clearest example is 24ad.info, the classifieds platform. It started life on a Laravel codebase inherited from freelancers, one I never fully understood. Since February 2026 it runs on a stack rebuilt with Claude Code: React 19 on the front end, Express and tRPC on the back end, MySQL underneath.

I'd like to tell you the rewrite was a heroic all-nighter that fixed everything. It wasn't. The honest version is more useful:

• The rewrite itself was fast. Describing what a page or an API should do, and having working code minutes later, really does collapse the time between idea and result.
• The polishing took much longer. Edge cases, translations, payments, the small things real users hit. Some gaps and small bugs are still being fixed today.

That second point is the part most "I built X with AI" stories leave out. AI makes the first 80% cheap. The last 20% still needs someone who cares whether it's right.

Describing, not dictating

What changed my results wasn't a better model. It was learning to describe things properly:

1. What exists now. "Listings are created on a country subdomain, and the currency is set from that country."
2. What needs to exist. "The price field should be pre-filled, but always editable."
3. How I'll know it works. "On the Polish subdomain a new listing shows PLN, and changing it by hand sticks."

Vague requests get confident, plausible, wrong answers. Specific ones get code I can actually check.

The verification habit

"Verify" is the part of the rule that does the real work, so it gets its own tools:

• Project memory. Every project I work on has a plain-Markdown map of what's done, what failed and what's next, so an AI session starts from facts, not guesses. Something marked verified doesn't get silently redone; something marked failed doesn't get quietly suggested again. I open-sourced it as Project Brain.
• Fact-checking my own content. Even the articles on this blog go through a check. When a draft makes a claim about one of my products, a Claude Code instance running on that product's own server checks it against the real code and data before anything is published. That's not hypothetical: it has caught drafts confidently describing features and incidents that never existed. Those got cut.
• A human publishes. Nothing ships to a live site, and no article goes out, without me deciding it should.

Where I keep AI on a short leash

Some decisions stay mine, every time:

• What to build, and why. AI is excellent at "how". It has no idea what my users actually struggle with on a Tuesday morning.
• Anything involving money or customer data. Payments, licences, personal data: these are the places I slow down most and check hardest before anything goes live.
• When "technically correct" is still wrong. AI sometimes proposes a solution that works and still feels off: too clever, too heavy, solving a problem I don't have. Learning to say "no, simpler" was one of the most valuable skills I picked up.

What this actually adds up to

AI didn't replace a development team for me. It made it possible to have one at all: a collaborator that writes most of the code, explains it when I ask why, and never gets tired of my questions.

But the responsibility didn't move. If something breaks on 24ad.info at 3am, it's still my name on it. That's exactly why I still make the decisions.

Built by FixFlex Ltd, West London. If you're a non-technical founder wondering whether you can build real products this way: you can. Just don't skip the "verify" part.