The client problem
Worthington is a UK landscape design business with a well-established local reputation but minimal organic search presence. Their competitors were ranking for high-intent local queries ("garden designer Surrey", "landscaping costs UK") purely on content volume — blog posts answering questions that potential clients search before making contact.
The client had neither the time to write three posts a week nor the budget to commission that volume from a copywriter at a rate that would produce any measurable ROI. The solution needed to produce consistent, topical, on-brand content without requiring the client to become a content manager.
The pipeline architecture
Generation schedule
Three cron jobs trigger at 08:30, 13:00, and 18:00 daily. Each job calls the generation module with the current topic queue. Topics come from two sources: a static seed list of evergreen landscaping subjects, and a weekly market research run using OpenAI Responses with web search — which surfaces currently-ranking content, seasonal queries, and competitor gaps.
Review queue and hold period
Generated posts don't publish immediately. They enter a review queue with a 3-day hold period. The admin panel shows the client their pending posts in a simple approval interface. Three actions are available: Publish now (skips the hold), Reject with feedback (the feedback is used to regenerate), or do nothing — in which case the post auto-publishes after the hold expires. This last option matters: it means the pipeline keeps moving even when the client is busy. They only need to intervene when something is wrong.
Pricing matrix enforcement
One early problem: AI-generated cost posts were producing specific price figures that didn't match the client's actual guide prices, creating enquiry expectations that led to awkward conversations. The fix was a pricing matrix admin panel — the client configures their guide prices (per square metre, day rates, material uplifts), and the generation prompt is dynamically constructed to use only those figures, with mandatory site-condition caveats appended. AI-generated cost content is now commercially accurate by construction.
Image generation and fallback
Each post needs a hero image. The system attempts DALL-E generation with a prompt constructed from the post title and category. If the image generation call fails or is rate-limited, it falls back to a library of branded site imagery — never a missing image, never a generic stock photo that breaks brand consistency.
The image mode (AI-generated / upload your own / branded fallback) is exposed in the admin panel as a radio button, not a config file. The client can override it per-post or set a default without touching code.
Dynamic sitemap
Every time a post is published — whether by the client approving it, the hold expiring, or a manual publish — the sitemap is regenerated from the live post database. Search engines always receive a complete, up-to-date index. There's no manual sitemap step, no outdated XML, no new posts sitting outside the crawl graph for days while waiting for a sitemap refresh.
Admin management surface
The full admin panel gives the client control of everything that matters without exposing anything that could break the system:
- Post list with publish/draft toggles and status indicators
- Slug editing and canonical URL management
- Manual content override — the client can edit any generated post before it publishes
- Category and tag management
- Image upload for posts where they have a better photograph than the AI can produce
- Weekly research toggle — enables the web-search topic augmentation when they want current SEO topics; disables it when they want to stay on the seed list
- Pricing matrix table — editable guide prices per service category
None of these require touching code, config files, or a CMS admin panel with a hundred options. The interface exposes exactly the decisions the client needs to make and nothing they don't.
The UX design decision that made it work
The hold-expire auto-publish was the insight that made this usable for a non-technical client running a busy business. Every other content approval system I've seen fails because it requires the operator to actively approve everything — which means the system grinds to a halt whenever the operator is busy.
The hold period inverts the model: the default action is publish. The client only needs to engage when they want to prevent publication. This means the pipeline keeps running at full throughput during busy periods, and the client's attention is reserved for the moments where it actually matters — not consumed by approving content they'd have published anyway.