Customer story
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
Featured, the company behind HARO and Connectively, runs three PR-tech brands with a seven-person team by replacing what used to be an eight-person manual coordination layer with durable orchestration on Inngest. Rather than a durable timer, a cron sweep re-checks question deadlines every 15 minutes so publisher-moved deadlines require no special handling. Each question runs as a single sequential pipeline of 60-150 durable steps rather than fan-in/fan-out across parallel runs, with an iterative loop selecting diverse, non-redundant expert answers. Critical guarantees, like preventing duplicate notifications, are enforced with a Postgres uniqueness constraint rather than in workflow code, and most functions intentionally don't retry, instead failing a run outright if it can't clear a quality bar, since a bad auto-published article is worse than a late one. The result: 2,500 articles a month, 42 answers per question on average, and enough headroom for a fourth brand acquisition.
Table of contents
How Featured runs three brands with a seven-person teamFrom deadline to published articleWhat "reliable" actually means for this pipelineWhat a seven-person team can run on durable orchestrationClick, click, doneQuestions this post answers
Why would you use a cron sweep instead of a durable sleeping timer to trigger a workflow at a deadline?
A cron sweep that re-reads current state every few minutes handles deadline changes for free, while a durable timer holds the deadline it was created with and must be canceled and rescheduled if that deadline moves. Featured's Inngest pipeline uses a 15-minute cron sweep for exactly this reason: publishers frequently push deadlines back, and the sweep just re-reads the current deadline on every pass instead of tracking stale state. daily.dev surfaces patterns like this for engineers designing deadline-driven or reschedulable workflows.
How do you prevent duplicate notifications in a workflow that might retry or run concurrently?
Enforce it with a database constraint rather than workflow logic. Featured uses a uniqueness constraint in Postgres, one notification per expert per published article, so a duplicate write is simply refused regardless of what the orchestration layer does. The principle: orchestration decides what happens and when, while the database decides what's allowed to happen at all. developers hardening idempotency guarantees can find this database-first pattern on daily.dev.
Why would a workflow system intentionally avoid retrying failed steps?
Because retrying can be worse than failing when the risk is producing bad output rather than just being late. Featured's article pipeline mostly disables retries on purpose: the real fear isn't a delayed article but a low-quality one getting auto-published under a client's masthead, so a run that can't meet the quality bar marks itself failed and stops instead of retrying into a mess. teams weighing retry-everything defaults against fail-fast design can explore this trade-off on daily.dev.
Share this post