Your Best Content Gets Read Once. A Tool Gets Used Every Week.

Why building something simple is the next visibility move

TL;DR: Building a tool does something for your visibility that content alone can't. Content gets read once. A useful tool gets used again and again, inside someone's workflow. I've been building one for six weeks with no coding background, and the process taught me as much about consistent effort as anything I've done in 30 years of online marketing. The paid section walks you through three steps to find the tool hiding in your existing work and get a first version started.

Six weeks ago, at a colleague's suggestion, I started building a tool for travel agents.

I had a simple idea. Agents get a flood of supplier emails every week. Luxury resorts, cruise lines, tour operators. The content is polished. It’s also completely generic. Most agents copy and paste it straight to their clients, and it reads exactly like what it is: someone else’s brochure.

I wanted to build something that would take that content and rewrite it in the agent’s voice. Paste in the vendor copy, choose a tone, get a client-ready email.

One input. One output. How hard could it be?

Image created with NotebookLM

What I didn’t account for

I am not a developer. I’ve never written production code. What I had was a clear picture of what the tool should do and an AI coding assistant willing to help me build it.

The approach is called vibe coding. You describe what you want. The AI writes the code. You test it, tell the AI what broke, it rewrites it. You repeat that loop until something works.

What I didn’t account for was how many loops that would take.

The first version had a backend that worked and a frontend that existed but they refused to talk to each other. A CORS error sat between them like a locked door. I spent time trying to fix it, didn’t get far, and had to step back.

A session was lost. Then another. I came back each time with just enough context to reconstruct where I’d left off, and we’d pick up the loop again.

The moment the loop became familiar

Somewhere around week three, something shifted.

The errors stopped feeling like failures. They started feeling like feedback.

I learned that when the AI ignored my length instructions and kept writing five-paragraph emails instead of two-sentence ones, the problem wasn’t the AI. The problem was my prompt. Vague instructions produce vague results. When I switched from “please keep it short” to “exactly two sentences, no bullet points, no greeting, no sign-off,” the output changed immediately.

I learned that when the backend kept running old code after I’d made changes, it meant old processes were still running in the background. One command clears them out. Now I run it automatically before every restart.

None of these were complicated once I understood them. But I had to hit each wall to learn what was on the other side.

What this has to do with visibility

I’ve been writing about visibility since 1996. I know what consistent effort looks like in content. You show up, you publish, you learn from what lands and what doesn’t, and you keep going.

Building a tool works exactly the same way.

Every session I came back to was a rep. Every bug I fixed was a data point. The six weeks weren’t six weeks of struggle. They were six weeks of compounding.

The app I have now is a real working MVP. It runs locally, connects front end to back end, produces three subject line options and a full email draft, and gives the user clear controls over tone and length. It doesn’t look like the thing I described in week one, because what I described in week one was a guess. What exists now is based on actual learning.

That’s the same thing that happens to a newsletter when you’ve written it for two years. It stops being what you imagined and starts being what your readers actually need.

The skill worth developing

A lot of people I talk to are sitting on tool ideas. They can describe exactly what they want. They know the problem it would solve. They’re just not sure they can build it.

What I want to tell you is that the building part is learnable. The barrier isn’t technical ability. It’s the willingness to stay in the loop long enough for things to click.

You don’t need to understand how the code works. You need to be able to describe what you want clearly, test what you get, and notice where it breaks. Those are the same skills you use to write clear content.

But here’s the part that surprised me: building a tool does something for your visibility that content alone can’t.

Content gets read once. A useful tool gets used again. It becomes part of someone’s weekly workflow. When an agent uses this to write 10 client emails a month, the tool shows up for them every time they open it. That’s a different kind of presence than a post in a feed.

Where the app is now

It’s still on localhost. No one can use it but me.

Deployment is the next step. Then a small beta group of travel agents who’ve agreed to test it.

After that: the things I’ve deliberately left out of version one. Saved tone preferences. Email history. Direct export to Gmail. But those come later. The version that exists now solves the original problem. That’s enough to move forward.

The pattern I suggest

If you have an idea for a simple tool, start with the smallest version of it.

Define one input and one output. Describe what you want to an AI coding assistant and let it write the code. Run it, see what breaks, tell the AI what you found.

Stay in the loop.

The app doesn’t have to be live to teach you something. The build itself changes how you think about your work, your audience, and what visibility can look like when it’s something people use instead of just something they read.

Six weeks in, I’m still in the loop. The door is open now.

Below are three steps I use to move from idea to working tool. Each one includes the exact prompt I’d run first.