In an earlier post I described cloning an app — copying the audio player I’d built onto a tablet to give away. That was a copy: same content, same speaker, a second home.

This post is about a step further. I took that same engine and pointed it at a different speaker, and then at a different kind of media — and it just worked. Each time, what should have been “build a whole new app” turned out to be “feed the engine something new.”

I built one engine: take in a library of recordings, transcribe them, make every word searchable, and play back the exact moment you searched for. That engine now runs more than one app — a second speaker’s library, and even a library of video instead of audio. The second app was nearly free, and the third nearly free again, because the expensive part was already done.

That’s one of the quieter benefits of building your own software, and it’s worth spelling out.

The Engine, Not the App

When I finished the first app — a searchable library of one teacher’s recorded talks — I stopped thinking of it as “an app.” Under the content, it was a general machine with a few steps:

  1. Take in a pile of recordings.
  2. Transcribe them (I’d built two methods you can swap — one tuned for speaker separation, one for fine timing).
  3. Correct and index the text so every word can be found.
  4. Play back the recording at the moment a search lands on.

None of those steps care whose recordings they are. The machine doesn’t know one speaker from another. That’s the part that makes everything after it cheap.

App #2: A Different Speaker, Nearly Free

Not long after, a second teacher’s recordings needed the same treatment — a different person, a different set of talks, but the same need: make hundreds of hours findable and playable.

A company would have to build a second product. I didn’t build anything close to that. I pointed the engine at the new content. The transcription methods I’d already written ran on the new recordings. The search and playback I’d already built indexed them. What had cost me weeks the first time cost a fraction of that the second time, because I was reusing the engine and only swapping the content.

This is what “personal software is a template” means in practice. The first app is expensive. Every app after it is the engine plus new content. You stop building apps from scratch and start stamping them out.

App #3: The Engine Learned to Watch Video

Here’s the part that surprised me.

The second speaker’s library wasn’t audio. It was video. And my engine was built entirely around audio. You’d expect that to break the reuse — video is a different beast, right?

It barely mattered. The hard, valuable part of the engine — transcribe the speech, index every word, and jump to the exact timestamp when you search — is the same whether the thing playing is a sound file or a video. A spoken word is at 14 minutes 22 seconds into the recording whether you’re listening or watching. The only real change was the last step: play the moment in a video player instead of an audio player.

So I changed the search to drive video the same way it drove audio — type a word, get every place it’s spoken, tap to watch from that second. It was a change, not a rebuild, because most of the machine didn’t care about the difference. The engine turned out not to care about audio versus video, and I only found that out by trying.

Why This Adds Up (and Why You Can’t Buy It)

Step back and look at the shape of it. The first app was costly. The second was much cheaper. The third — jumping to a new kind of media — was cheaper still. Each app I build makes the next one cheaper, because each one adds a reusable part to the engine: a transcription method, a search behavior, a playback trick. That runs in my favor over time.

A subscription app can’t give you this. When you rent software, every new need is a new product you hope someone else decides to build, and a new fee. You can’t point Spotify at your church’s video archive. You can’t tell YouTube to act like your audio app. The engine isn’t yours, so the advantage isn’t yours either.

When the engine is yours, that advantage is yours too. The small set of apps I run for my family — recordings, hymns, a children’s library — shares parts for exactly this reason. I didn’t build a set of apps. I built one engine, reasonably well, and kept pointing it at new needs.

The Human Part

As with the rest of this series, the AI did the work — it wrote the changes, ported the search, wired up the video player. My job was to see the reuse: to notice that a second speaker was the same problem with different content, and that video was the same engine with a different last step. Knowing what’s actually the same under two things that look different is judgment, not coding. That’s the part that stays mine.

If you’re enjoying the behind-the-scenes view of how one non-coder builds a small shelf of software with AI, please subscribe.

Key Takeaways

  • Stop thinking “app,” start thinking engine: take in → transcribe → index → play back at the exact moment.
  • The engine doesn’t care whose recordings it holds, so a second speaker’s app was nearly free — engine plus new content.
  • The engine didn’t care about audio versus video either: going from audio to video was a change, not a rebuild, because “jump to the timestamp” is the same either way.
  • Each app you build makes the next one cheaper — personal software adds up in your favor.
  • You can’t buy this: rented apps don’t give you the engine, so they don’t give you the advantage.
  • The reusable insight is human: noticing when two different-looking needs are the same problem underneath.