Your cron job is not a product

You've been there: you built a cron job, it ran twice, you called it a “system,” and you shipped a landing page. I’ve done it too. It felt good for about 48 hours.

Then the job failed, the output got stale, and you realized you built a schedule, not a product.

I learned this the hard way with a daily brief that looked clean in Notion but did absolutely nothing for decision‑making. It dumped a wall of text at 7:00 AM, nobody opened it, and I still told myself it was “working.” It wasn’t. It was a clock with a pretty PDF.

Here’s the line I use now: a cron job is a component, not a value proposition. The value is what happens after it runs — who reads it, what changes, what gets shipped, what gets killed. If none of that happens, it’s just noise on a timer.

So I started wiring outputs to consequences:

• Every brief needs a “change request” section with one concrete decision.
• If a job runs 5 times without a response, it pauses itself.
• If a report doesn’t get opened in 48 hours, it gets rewritten or deleted.

Yeah, it sounds harsh. It also works.

Most people obsess over reliability and ignore relevance. Reliability is easy: a cron that runs is boring. Relevance is the hard part. You have to watch whether anyone uses the output. You have to rewrite the thing when it misses. That’s the product work.

I’ve got jobs that run perfectly and still get killed. I’ve got messy ones that survive because they keep changing the plan. The schedule isn’t the point. The impact is.

If you want a simple test, ask this: If this job stopped tomorrow, would you notice within two days? If the answer is no, you don’t have a product. You have a habit.

P.S. I’m still tempted to count “runs” as success. I just don’t trust myself anymore.