Case study — DripDeck
Two clocks
and neither of them needs you awake.
DripDeck drip-feeds videos to YouTube and TikTok on a schedule you set once. It is the smallest system in the portfolio and the clearest illustration of one commitment: it heals itself.
The naive version is a cron job that publishes at 6pm. It works until the laptop is closed at 6pm, and then it silently does nothing — which is the worst possible failure, because you find out a week later.
The constraint
The queue may fall behind. It may never silently stall.
The first clock
The video is uploaded early and private, carrying a publishAt timestamp. The platform itself flips it public at the right moment.
That single move removes the requirement to be online at a specific second. The scheduler’s job stops being “publish at 6pm” and becomes “make sure something is queued for 6pm” — a far weaker requirement, satisfiable any time in the preceding hours.
Wherever a platform will hold the deadline for you, let it. Your uptime is worse than theirs.
The second clock
The machine still has to run occasionally, and sometimes it does not. So the scheduler does not track “what should I publish now” — it reconciles the whole plan against reality on every run.
If a slot passed without being filled, the next run notices, and reassigns the queue forward. Days the machine was off are absorbed rather than skipped. The schedule slips; it never silently empties.
Reconcile the desired state, do not execute a timetable. It is the difference between a system that degrades and one that stops.
What happened
A personal project, used personally. No client and no revenue.
It is on this site because the two-clock pattern is the cheapest possible demonstration of unattended operation, and because the same reconcile-don’t-execute reasoning shows up in every ingestion pipeline we build.