Two platforms and a fleet of production automations

What was the problem?

A newsroom organization accumulating automations one at a time.

Each had its own owner, its own alerting, and its own failure mode. None of them were discoverable by anyone who had not built them. Someone in one market would ask for a scraper that already existed in another, and the honest answer was that nobody could easily tell.

The tell is the cost curve. When the hundredth automation costs more to add than the first, you do not have an automation problem, you have a platform problem. Adding the hundred-and-first job was going to make things worse, not better.

The consolidation bet

The obvious alternative was to keep going: add jobs as they were requested, write a wiki page listing them, and let each one carry its own alerting. That is cheaper this quarter and it loses on a two-year horizon, because a wiki describing a hundred systems is a document nobody trusts within a month of writing it.

I argued for a single self-service layer instead, and wrote the PRD for it. Four decisions carried the design.

A registry, so jobs are discoverable. The failure was never that a job did not exist. It was that nobody could find out whether it existed. Discovery is the feature.

Subscriptions, so consumption is opt-in. The pattern being replaced was broadcast: a job emails a list, the list grows stale, and people filter it into a folder they stop reading. Letting people subscribe to what they want inverts that, and it produces a usage signal you can act on. A job with no subscribers is a candidate for deletion, which is information you cannot get from a broadcast.

SSO, so access is not a spreadsheet. Per-job access management does not survive staff turnover in nine markets.

Digests, so output arrives where people already look. The best automation nobody opens is worth nothing. This is the same lesson as the adoption section below, applied to plumbing.

The result runs hundreds of automated jobs behind one interface.

The second platform

The same shape, applied to a different repetition. Every data-driven story was rebuilding its own interactive from scratch: an election result, a bill tracker, a shipping map, each one a bespoke build with a bespoke deploy.

We built one authoring path instead, to a spec I wrote: raw data goes in, an embeddable single-page app comes out, and it lands in a published article. Reusability was the explicit design goal, so the tenth embed costs a fraction of the first. That is the entire argument for the system.

Operating a fleet

This is the part of the work that most product resumes omit, and it is the part I would most want to be asked about.

• Model migrations across a live fleet, with rollback criteria defined before the migration
• Cost and performance tuning as a standing concern rather than a project
• Production debugging, including stale function versions raising alerts for work that had already succeeded

On the migrations: the decision that mattered was defining rollback criteria before starting, not during. Once a migration is underway and something looks slightly worse, every judgment call is made by someone who is invested in the migration succeeding. Writing down in advance what “worse” means, and what would make us revert, is the cheapest possible insurance against that bias.

On debugging: the failure class I found most instructive was stale function versions raising alerts for work that had already succeeded. The output was correct and the alarm was real, which is the worst combination, because it trains people to ignore alerts. An alert that cries wolf is worse than no alert, and I would rather delete a noisy check than let it erode trust in the rest.

The honest note: I under-invested in observability early here, the same mistake I made on the measurement platform. Twice is a pattern, and it is the thing I now front-load.

Scope

Markets

9 markets plus topical publications.

Automated jobs

Hundreds of them, running behind the self-service layer.

Monitoring sources

hundreds of RSS sources feeding editorial lead-list and monitoring dashboards, mapped to reporter beats with a daily refresh.

Built on top

Dashboards, production AI agents, and structured data hubs.

Why publisher-side work matters for retrieval

Worth stating, because it connects this work to the measurement work rather than sitting beside it.

Whether an editorial page can be retrieved and cited by an AI engine is decided by the publisher, not the engine. Three things determine it, and I spend my week on all three: whether a page carries machine-readable claims about what it is and what it concerns; whether a large corpus is tagged well enough that a specific relevant piece can be found among hundreds of thousands of adjacent ones; and whether semantic search over that archive actually surfaces the right story.

Most people working on AI visibility have only seen it from the brand’s side. I spend my week on the other end of the citation.

Adoption

I run office hours and training across markets, onboarded an engineer onto the stack, and mentor on it.

That is not a soft addendum to the engineering. A platform nobody adopts is a hobby. Internal AI tooling mostly dies of non-adoption rather than of technical failure, and having taught more than 500 people to work with AI, I know what the confusion actually sounds like before it becomes a support ticket.

What I would do differently

I would have written the registry first. The consolidation shipped in an order that put the job-running machinery ahead of the discovery layer, which meant the first users still had to be told what existed. Discovery was the actual product and I sequenced it second.

I would have set a deletion policy at launch. Subscriptions give you a usage signal, and I built the signal without deciding in advance what to do with it. A platform that only ever accumulates jobs recreates the original problem more slowly.

I would front-load observability. Stated above, and it is the same lesson as the measurement platform. The pattern is that I optimize for shipping the capability and treat knowing whether it is healthy as a follow-up, and follow-ups slip.

Stack

MindStudio, AWS Amplify, AWS Lambda, AWS S3, AWS CloudFront, DynamoDB, Google Apps Script, Claude and Claude Code, Apify, Playwright, Arc XP / Composer, RSS pipelines, Microsoft Copilot.