Bhavana's Week 12: Finish What You Scoped

In the last week of her SEO engineering series, Bhavana Bhariday rechecks an old blocker, finds it no longer applies, and builds the company page from patterns proven over the previous 11 weeks.

2:48 video3 min readWatch on YouTube

The most common way a project stays stuck isn't a new obstacle showing up, it's an old one that nobody rechecks. That's the exact trap Bhavana Bhariday calls out in the finale of her twelve-week series as a Humanitarians AI Fellow: a blocker she hit in week 10 was still treated as active in week 12, purely out of habit, even though the reason behind it had quietly stopped applying.

A blocker is a fact about a moment, not forever

The instinct, as Bhavana puts it, is to trust past decisions: it was blocked before, so it must still be blocked now. In week 10, building the company detail page had been paused because it seemed to depend on sponsorship tier data that wasn't ready yet. By week 12, instead of assuming that dependency was still missing, she actually went and checked. It wasn't. The company page had never truly needed to wait on that data at all.

Building from parts that already existed

Once she looked past the outdated assumption, the build itself turned out to be straightforward. The base companies table already held everything a genuinely useful first version of the page needed: name, slug, logo, verification status, and job count, none of which depended on the sponsorship tier data that had caused the original pause. The page follows the same meta pattern already established for job pages in earlier weeks: a clean title, a canonical URL, and a noindex directive until a company is actually verified and has jobs attached. It's also wired to the cookie-less client built the week before, so the page is genuinely ISR cached rather than merely configured to look that way. As Bhavana notes, the whole point of twelve weeks of building consistent patterns is that the next page becomes mostly assembly rather than fresh design work.

Resolving a real edge case: slug collisions

One genuine design question did surface during the build. The companies table is only guaranteed unique per source and slug together, not on the slug alone, which means two different scrape sources could in theory produce the exact same slug string. Rather than assuming any single matching row is automatically the correct one to display, the query orders candidates by job count and deterministically takes the top match, so the most substantial company record for that slug wins every time. It's a small fix, but it closes a gap that could otherwise have shown a thin or stale record instead of the most complete one.

An honest caveat, kept to the end

Bhavana is careful to name a limitation rather than paper over it: the dev database still has no company rows in it, so the real happy path, an actual company with live jobs rendering on the page, hasn't been observed firsthand yet. That's not a new problem; it's the same empty-database limitation she flagged back in week three. The page is built and cache-verified, but it hasn't yet met real data.

Key takeaways

  • A blocker recorded in week 10 was assumed to still apply in week 12, but rechecking showed the underlying reason no longer held.
  • The company page was built entirely from existing, proven data: name, slug, logo, verification status, and job count.
  • It reuses the same meta pattern as job pages (clean title, canonical URL, noindex until verified) and the prior week's cookie-less ISR caching fix.
  • Slug collisions across different scrape sources are resolved deterministically by ordering on job count and taking the top match.
  • The dev database still lacks company rows, so the full happy path with real data hasn't been observed yet.
  • Twelve weeks of consistent patterns turned this final page into mostly assembly work rather than new design.

Try it yourself

Bhavana's closing challenge is worth applying to your own backlog: find something you scoped out months ago, and before assuming it's still blocked, check whether the original reason still holds or whether the data or dependency you were waiting on has quietly arrived. This kind of disciplined, pattern-driven engineering work is representative of the projects tackled in the Humanitarians AI Fellows program.

Chapters

  1. 0:00Blockers are Temporary Moments
  2. 0:30Building the Company Page from Proven Parts
  3. 0:55Resolving Slug Collisions Deterministically
  4. 1:2012 Weeks: One Legible SEO System
  5. 1:45Finale: Finish What You Scoped
Full transcript(auto-generated, with timestamps)

Blockers are Temporary Moments

[0:00]Hi, I'm Bavana, a Humanitarian's AI Fellow, and this is week 12, the finale of my Job Seeker report, where I've been the SEO engineer making Google find and rank our job listings. This week closes a loop. The company page I scoped out in week 10 rebuilt, because when I re-checked, the reason to wait no longer applied. The instinct would be to trust past me. It was blocked before, so it's blocked now. But a blocker is a fact about a moment, not forever. So I actually looked. No

Building the Company Page from Proven Parts

[0:31]Company page existed yet, and better, the base companies table already had everything a genuinely useful first version needs. Name, slug, logo, verification status, job count. None of it depending on the sponsorship tier data that caused the pause. The page never actually needed to wait, so it got built from parts already proven. The same meta pattern as job pages, a clean title, a canonical URL, and no index

Resolving Slug Collisions Deterministically

[0:57]Until a company is actually verified with jobs. And it's wired to last week's cookie-less client, so it's genuinely ISR cached, not just configured to be. Nothing new invented. The whole point of 12 weeks of patterns is that the next page is mostly assembly. One real design question came up. The companies table is only unique per source and slug together, not on the slug alone. So two

12 Weeks: One Legible SEO System

[1:20]Different scrape sources could, in theory, produce the same slug string. Rather than assume any single row is the obviously correct one, the query orders by job count and deterministically takes the top match. The most substantial company for that slug wins every time. And one thing to stay up front about, the same way this whole series has, the dev database still has no company rows in it, so the real happy path, an actual

Finale: Finish What You Scoped

[1:47]Company with actual jobs rendering live, hasn't been seen firsthand yet. That's the same empty database limit from week three, not a new one. The page is built in cash verified. It just hasn't met real data yet. Recap and the close. The company page came off the shelf because I rechecked the blocker instead of trusting it and the blocker was gone. It was built from proven parts. The job page meta pattern, last week's cookie less cash fix. One real edge, the slug collision resolved deterministically. And an honest caveat kept, the same as always. 12 weeks, one legible SEO system. The rule at the end. Recheck what you scoped out because the reason may not have survived. Your turn and the last one. Open your own backlog and find the thing you scoped out months ago. Before you assume it's still blocked, ask Claude to check whether the reason still holds, whether the data or the dependency you were waiting on has quietly arrived. Then build it from the patterns you already have. Run this and

More from Humanitarians AI Fellows

Humanitarians AI Lyrical Literacy Project