Stop Learning Apps. Start Building Them.

Nicolas Cole spent 45 minutes making a YouTube thumbnail. One thumbnail. He bounced between DALL-E, Gemini, and Canva, and at the end of it he had a preview image and the nagging certainty that he’d be doing the same thing next week.

So instead of getting better at the process, he had Claude build him a tiny app that does the whole thing in under a minute. Upload a photo, pick a template, hit download, and you’re done.

The full walkthrough is on his Substack if you want to steal his thumbnail maker or see the step-by-step. It’s a good post. But I want to talk about the thing underneath the thing, because that’s where it gets interesting for authors.

The old loop

You know the loop. You’ve lived it. I’ve lived it. (Mochi, my adorable cat, has judged me for it.)

1. Realize you need to do a thing, like make a book cover mockup or format a newsletter.
2. Google “best tool for [thing].” Sign up. Watch three YouTube tutorials.
3. Get moderately okay at it. Do the task in 20 minutes instead of 45 and call that progress.
4. Repeat forever, because the tool was built for everyone, which means it wasn’t really built for you.

That loop made sense when the alternative was hiring a developer. It doesn’t make sense anymore.

What actually happened in that thumbnail story

Cole didn’t learn a new design tool. He described what he wanted in plain language, showed Claude a screenshot of the style he was going for, and iterated through feedback rounds until the thing worked.

The interesting part is the process. He didn’t write a spec document. He said “I make YouTube thumbnails every week and I’m tired of using Canva.” He didn’t plan all the features upfront. He added them one at a time, testing between each. When something looked wrong, he took a screenshot and said “fix this.” No design vocabulary required.

Two hours of conversation, and now he has a tool that does exactly one thing, exactly the way he needs it done, with his brand colors baked in. That’s kind of wild.

Why this matters for authors specifically

You are drowning in general-purpose tools. Canva for graphics. Mailchimp (or ConvertKit, or Substack) for newsletters. Amazon’s ad console. BookBrush. Publisher Rocket. They all have learning curves, and they all do 400 things when you need 3.

Now imagine the alternative. Instead of learning the next app, you describe what you actually need.

“I want to paste in my back cover copy and get three versions of ad text for Amazon Sponsored Products, each under 150 characters, with my genre’s conventions baked in.”

“I need a tool where I paste a chapter draft and it flags every instance where I’m telling instead of showing, with the specific sentence highlighted.”

“Build me something that takes my book title, subtitle, and comp titles, and generates ten options for a Substack post announcing the launch.”

These aren’t apps that exist. They’re also not apps that need to exist as products, because they only need to work for you. Your workflow, your way.

The skill that matters now

For years, the indie author advantage was willingness to learn tools. Be your own marketing department, your own design team. That was real, and it still is. But the nature of the skill is shifting.

The authors who’ll move fastest over the next few years won’t be the ones who master the most platforms. They’ll be the ones who get good at describing what they need clearly enough that AI can build it for them. Describe the problem. Show an example of what good looks like. Give feedback. Iterate.

You already do this every time you work with an editor or a cover designer. Same muscle, different collaborator.

Start smaller than you think

You don’t need to build an app. You don’t even need to think of it as “building” anything. Start with the task you did this week that made you mutter under your breath. The one that took 30 minutes and felt like it should’ve taken 5.

Open Claude (or ChatGPT, or Gemini, whatever you’re comfortable with). Say “I keep doing [this thing] and it’s annoying. I wish it worked like this instead.” See what comes back. I’ve done this for half a dozen little annoyances in my own workflow at this point, and every single time I wonder why I waited so long.