The challenge
The client is an Austin-headquartered B2B SaaS in the contract operations category, ~$22M ARR, Series B, ~200 customers. The marketing team consisted of three people: a head of growth, a content lead, and a paid marketer. Acquisition was 73% paid, 23% outbound, 4% organic.
The CFO had pushed back on the next paid-acquisition budget request because the LTV:CAC math was thinning. The head of growth had been advocating for an organic investment for 6 months but didn't know how to scope it. They came to us with a one-line brief: "We need an organic engine. Tell us what it looks like."
What we found
Two weeks of audit produced a clear opportunity map. The category, contract operations, had a long tail of structured search demand that the client wasn't competing for:
- Industry-specific use cases. Variants like "contract management for [vertical]" had real volume and almost no quality content addressing them.
- Integration-led queries. "Salesforce contract automation," "HubSpot contract workflow", searches where the SaaS had a real integration story but no content explaining it.
- Comparison queries. Direct vs competitor searches were intercepted by review sites; the client's own POV wasn't surfaced.
- Use-case templates and calculators. Operators searching "contract risk calculator" or "force majeure clause template" weren't finding the client.
Total addressable monthly search volume across these patterns: ~280K. The client's site captured 5,800 of them.
Approach
We scoped a 9-month program in three phases. Each phase had a written kill-switch: if the indexation or engagement quality wasn't where we modeled, we'd pause the next batch.
Keyword universe + data architecture
Mapped 1,800 candidate page patterns across 4 templates. Designed the Postgres schema for the variable data, every page had ≥3 unique data points (industry benchmark, integration depth, use-case template) baked into the model.
Template build (Next.js + ISR)
Built one template per pattern on Next.js with ISR. Internal linking model designed up front. Authority signals (author bylines, last-updated date, source citations) baked into the template.
Phase 1: 200 pages live
Shipped the integration-led pages first. Watched indexation for 4 weeks before approving Phase 2. Removed 14 pages that had unique-data conflicts during QA.
Phase 2 + Phase 3: 1,200 more pages
Industry-vertical and use-case-template pages shipped in 4 batches. Internal-linking density tracked weekly. Two batches were edited before publish based on Phase 1 learnings.
Pruning + content depth
Noindexed 89 pages with zero impressions after 60 days. Expanded the top-50 ranking pages with deeper data tables and embedded calculators. Tracked share-of-voice against three competitors.
Execution
The piece of work the team underestimated was the data architecture. We spent the first three weeks of Month 1 mapping the variable data per template, what made each page genuinely unique, not just templated. For the integration-led pattern, every page included: integration depth scorecard (4 dimensions), implementation timeline benchmark, common-pitfall section drawn from client implementation tickets, and pricing implications.
That data layer is what made the program durable against Google's Helpful Content Update cycles. Two months after our 1,800-page program launched, Google rolled out HCU-aligned ranking adjustments that pummeled thinner programmatic sites. Our pages mostly held. The exceptions, 89 pages we noindexed in Month 7, were the ones where the unique-data layer had stretched thin.
12
Pre-engagement, 14 active blog posts + a handful of integration pages
640
Across 4 template patterns, 9 months post-launch
By Month 6 the engagement numbers told the operating story. Average time-on-page across the programmatic universe was 3:18, higher than the client's existing blog content average. Pages-per-session from organic was 2.4, vs 1.6 from paid. Both signals that the content was load-bearing, not thin.
Results
(See the full headline-results grid at the top of this page.)
What we learned
Programmatic SEO works when the unique-data layer is real. The same program template against a thinner data model would have been disposable by Month 9, Google's HCU rollouts in 2025-2026 punished exactly the patterns that thin programmatic relies on.
The other lesson: the editorial review process matters as much as the data. Every batch of 100 pages went through a 2-day editorial pass before publish. Two batches were materially rewritten. Skipping that step would have shipped a faster program at a lower quality bar, and we believe it would have been a manual-action risk inside 6 months.
The boring engineering, the database schema, the unique-data layer, the editorial pass, is the entire program. Anyone who tells you programmatic SEO is fast and cheap is selling you a manual action.