Why I build the software I explain

I have recorded more than 800 software videos since 2019, for over 200 brands, in English and Spanish. For most of that time I was strictly on the outside of the products I filmed. I read the documentation, clicked through the app, found the part that would confuse someone on their first day, and explained it.

That work is a strange kind of education. You watch 200 teams attempt the same handful of problems: how to get a new account to its first useful moment, how to name a setting, how to explain a pricing model without a spreadsheet. After a while you recognise the shape of a good decision before you can say why it is good.

What I could not see from the outside

There was a hard limit to it.

I could tell you a permissions screen was confusing. I could not tell you whether it was confusing because the model underneath was confusing, or because the labels were wrong. Those are different problems with different fixes and roughly opposite costs. From the outside they look identical.

The clearest version of this happened while I was recording a webhook setup. The flow felt awkward — three screens where one seemed enough — and I said so on camera, in the mild way you say things when you are not certain. Someone wrote in afterwards to point out that the second screen existed because that was where the retry policy got attached, and that collapsing the flow would have quietly dropped failed events. He was right. My explanation had been fluent and wrong.

Fluent and wrong is the specific failure mode of an explainer who does not build. It is not obvious to the audience, which is what makes it worth worrying about.

What changed when I started writing code

I began building the things I kept wishing existed while filming. Chrome extensions first, then web applications, then a macOS app. Nothing about that was a career plan. It was closer to the way a mechanic ends up with good tools.

Three things changed in the video work, none of which I predicted.

• I stopped reading marketing pages. When you have implemented a webhook receiver, the sentence "real-time sync" stops being a claim and becomes a question about delivery guarantees. The API documentation answers it; the landing page does not.
• I got faster at finding the interesting part of a product. Most software has one decision in it that everything else follows from. If you have made that kind of decision yourself, badly, you spot it in someone else's product in about ten minutes.
• I got more generous. Building teaches you which ugly things are laziness and which are the visible edge of a hard constraint. I criticise less and explain more, and the explanation is usually more useful anyway.

FlowCapture is the clearest case

Recording software for a living means the same three problems every day: scrolling a long page without the jerk of a mouse wheel, zooming into the click that actually matters, and keeping a webcam bubble somewhere that does not cover the interface. Every recorder I tried did one of those three well.

So I wrote one. FlowCapture is a Chrome extension that runs entirely on the device, built on the MediaRecorder API, WebCodecs and a canvas compositor. It is on the Chrome Web Store, published under Veeme Media, the agency I started in 2013, and it currently sits at 4.8 out of 5 across 19 ratings. It is the tool I needed 800 videos ago.

The thing it taught me was not about video. It was that on-device processing is a feature rather than a constraint. Once I stopped uploading footage to a server, the export got faster, the privacy explanation got short enough to fit in one sentence, and there was no infrastructure bill to justify. I had assumed local processing was the compromise. It was the product.

That is the sort of conclusion you cannot reach by reviewing other people's software. You reach it by shipping something and watching which of your assumptions survive contact with users.

The loop, stated plainly

I explain software because I build it. I build it because I run businesses that need it.

Each direction is load-bearing. The explaining work tells me what to build — FlowCapture exists because 800 recordings defined its requirements far better than any brainstorm would have. The building work makes the explaining accurate, because I am describing mechanisms I have implemented rather than features I have read about.

What it costs to say this honestly

The awkward part is that not everything I build ships, and I would rather say which is which than let the list imply otherwise.

Nine projects are listed publicly on this site. Seven have a working public link you can open right now: FlowCapture, FlightGlass, Akiya Scout, PagePing and Link Status Checker on the Chrome Web Store, MercadoTools on Google Play, and StackPulse, a macOS menu-bar app that reads AI provider usage and spend, open source under MIT. Two are labelled prototypes, because that is what they are. Shadow and Inbox Referee were built, they work on my machine, and no one else can install them.

The status labels on this site are set by a fetched link, not by how finished something feels. That rule is the reason the two prototypes are still called prototypes: I could describe all nine the same way and most readers would never check. A portfolio where every item is a triumph tells you nothing about the person, because you cannot see where their line is.

The other honest cost: building slows the video work down. A week spent on a pricing parser is a week not spent recording. I have accepted that trade because the alternative — explaining software indefinitely from the outside, getting fluent and occasionally wrong — is worse in a way the audience would eventually notice.