SEO SOP: Decide the One Thing to Ship Next

AI removed the build constraint and replaced it with a harder one. This SOP is the move Ben Senescu made when his open source project drew sixty pull requests he could not safely merge, from his Unscripted SEO interview. It works on any backlog that grew faster than your ability to check it: a content calendar, a client roadmap, a feature list.

Objective

Convert an unbounded backlog into one published direction and one active lane of work, without burning the goodwill of the people who filled the backlog. The outcome is a written roadmap that states both the decision and the reason, an input channel that still carries signal, and a definition of done you can actually verify. This is a half-day of work and it is repeatable every time the backlog rebuilds.

Key Steps

1. Count the backlog honestly and stop pretending you will clear it. Ben had sixty open pull requests from people he had never met, on top of roughly fifty open issues. The number is not the problem. Believing you will get to it is the problem.
2. Test each item against verification, not build effort. The question is no longer “can I build this” — assume yes. The question is “if this is subtly wrong, will I find out.” Anything that fails that test does not belong in the lane regardless of how cheap it is to produce.
3. Declare bankruptcy publicly, not silently. Ben posted an update in his community saying he was not addressing the open PRs. Closing them quietly reads as abandonment; saying so out loud, with the reason attached, reads as a decision. (inferred: he describes posting the update; the goodwill framing is the reason it works, not a step he prescribed.)
4. Publish the roadmap that replaces the backlog. It has to exist before the bankruptcy, so the “no” has somewhere to point. Ben’s roadmap names specific next work and is the thing he referred people to.
5. Keep the input channel that carries signal. Close the one that carries cost. He stopped taking pull requests and explicitly kept issues, saying the most useful contribution now is a well-written issue describing how someone wants the product to work. Separate “tell me what you need” from “here is a change I want you to own.”
6. Choose a direction and say which one out loud. Horizontal, covering more ground shallowly, or deep, improving one thing. Ben chose horizontal on purpose and published that choice. An unstated direction gets relitigated in every request.
7. Define done as one thing you can verify. Not a count of shipped items. If you cannot describe how you would notice this being broken, it is not finished.
8. Re-run this when the backlog rebuilds. It will. This is a recurring triage, not a one-time cleanup.

Cautionary Notes

• “I could build all of it in three weeks” is the trap, not the plan. Ben’s exact reasoning: he could implement every Semrush feature in three weeks with Claude Code, and every one would be slightly broken in a way that is impossible to untangle afterwards. Volume of output is not the win condition.
• Do not close the channel that carries the signal. Killing issues along with pull requests would have removed the demand data that tells him what to build next. The two look similar and are not.
• Silent closure costs more than the backlog did. In a community that contributes work, an unexplained mass close reads as the project being abandoned.
• A roadmap without reasons gets argued with. The reason is what stops the same request arriving again next week.
• Do not treat this as a one-off. The conditions that produced sixty PRs have not changed, and will produce sixty more.

Tips for Efficiency

• Write the roadmap first, then the bankruptcy post. Ten minutes of sequencing saves the awkward gap where people have been told no and shown nothing.
• Budget in units of what you can verify per week, not what you can produce per week. That number is much smaller and it is the real capacity.
• Keep the roadmap short enough that a contributor reads all of it. A long one is a backlog wearing a different hat.
• When you decline something, name the channel that is still open in the same sentence.
• Revisit on a fixed cadence rather than when the pile becomes painful, which is always later than it should be.

Why this belongs in an SEO SOP library

Because the same thing happened to content. Anyone can now generate more articles, more location pages and more programmatic variants than they can fact-check, internally link or keep current. The failure mode is identical to Ben’s: not a single obvious break, but a hundred things that are each subtly wrong, arriving faster than anyone can audit them.

“I could probably implement every feature in Semrush in three weeks with Claude Code, but they’d all be so slightly broken that it would just be impossible to fix. I think that’s the biggest thing in the AI era, figuring out: I can do anything. What’s the one thing I should do?”

Sources & Relevant Episodes

• Ben Senescu, OpenSEO — described this as the decision that defined the AI era for him as a builder: capability stopped being the constraint, and judgment became it. Full interview: The $10 SEO Tool: How Open Source Broke the $99-a-Month Ceiling.
• Founder and product angle on the same conversation: Pricing Under the Incumbent.
• Listen: Ben Senescu on Open Source SEO and the $99 Ceiling · Watch: on YouTube.
• Related reading: SEO SOP: Vet Links By Relevance, Not DA — the same instinct applied to link building.