Five Years Looking for One Person

It's easy to treat SEO as something you get to eventually. The cost is invisible until you look directly at it.

When I finally did, here's what I found on our own site.

Our structured data told Google our platform had a price of zero, across seven different pages. Nobody wrote that on purpose. It came from a copied block of code that spread quietly from page to page. For years, the machine-readable version of our business said something none of us would ever say out loud.

This is technical debt. Not the kind engineers argue about in planning meetings, but the kind that quietly misrepresents your business to every search engine that visits.

A page that should have been one URL was another, with no way for anyone to find the right one. Long sections of our most substantial content sat inside interface elements that search engines couldn't read at all. And we had five years of blog posts on a separate subdomain that generated essentially nothing of commercial value.

None of these are exotic problems. Every one of them was fixable in a day by someone who knew what they were looking at.

That's the part that bothered me. Not that the problems were hard, but that they were easy and still didn't get solved, because the work fell into the gap between two job descriptions.

At some point the frustration stopped being productive, and I decided to do it myself.

Not by sitting down and writing it line by line, which would have taken weeks I didn't have. By directing the work: decide what needed to be true, have an AI agent write the change, review it against what I know, and hand it to my team as a finished pull request instead of a wish list.

In a matter of weeks, the backlog I'd carried for five years was gone.

Structured data describing me and the company correctly, so a search engine understands who runs this business. The price-zero problem removed everywhere it had spread. The wrong URL retired properly. The unreadable content made readable. A content system that lets us publish guides without engineering time. And a writing section with its own publishing pipeline, which is how you're reading this essay.

Every one of those went to my engineering team the same way any other change does: as a pull request, reviewed, merged, and shipped on the normal release. Nobody's roadmap moved.

This isn't vibe coding. A live commercial site with customers on it is not a place to find out what the AI feels like building.

It only worked because I set the constraints before I set the AI loose.

Plan before code. Every task started with investigation and a written plan. Nothing changed until I read it and said yes. That single rule caught more problems than any review of the finished work would have.

Nothing changes without my approval. Not one file, not one line, not as a helpful extra.

Pull requests only, never a deploy. The AI could propose. My team decides what ships. That boundary never moved.

Only fix what we agreed to fix. No tidying, no "while I was in there."

The AI wrote the code. Every decision about what should exist was still mine.

The most useful thing I can tell another founder is that generating the work is the easy part. Judging it is the job.

More than once, the plan that came back was wrong. A proposal to fix something that turned out to be commented-out code that never ran. A finding that reversed itself under closer inspection. A build check that would have worked perfectly on my machine and silently done nothing in production.

Each of those was caught because someone read the plan and asked what would actually happen. That is where the engineering training earns its keep. You have to be able to follow what the code will really do, understand the business well enough to know which answers are unacceptable, and be stubborn enough to say no to a confident-sounding recommendation.

That skill isn't new. It's the same thing you do with any proposal from any team. What's new is how many proposals you can evaluate in a week.

I want to be precise here, because this is where these stories usually get oversold.

I didn't replace my engineering team. They build the product, which is a vastly harder problem than a marketing site. Their review still gates everything. They deploy, and I don't.

I also didn't stop being the CEO. My engineering training is why I could review this work honestly, but reading pull requests is not what my week is for. The point was never to become the person doing the implementation. It was to stop that being the reason nothing happened.

And I'd still hire the person I spent five years looking for. The difference is that not finding them is no longer a reason for the work to sit undone.

For most of my career, the distance between knowing what a company needs and having it built was measured in hiring cycles, budgets, and someone else's priorities.

That distance is shrinking fast. A founder who can specify clearly, set hard constraints, and review honestly can now close problems that used to require a hire they couldn't find or afford.

The bottleneck was never the code. It was translation, coordination, and waiting.

Five years of waiting ended in a few weeks of directed work. What I regret is the five years, not the weeks.