Para ahí: don't poll

Building the subscription-expiry logic, Cline suggests the textbook answer: schedule a recurring task that checks every user’s subscription state each hour and blocks the expired ones ▸ 4:54. Juan’s response, mid-suggestion: “no, para ahí, para ahí” ▸ 5:29.

His counter-design is lazy evaluation: update the countdown while the person is in the canvas, and block only at the moment they hit zero ▸ 5:32. The reasoning comes in two blows. First, economics: imagine someone bought a day pass, left, and never came back, why should the server wake up every hour, forever, to check on a user who isn’t there? ▸ 9:06. Second, and subtler, testability: “para probar eso yo no me voy a poner a esperar una horita a ver si ya se activó esta vaina” ▸ 6:09. An architecture you can’t exercise on demand is an architecture you won’t verify.

la IA propone el patrón de libro; el dueño paga el servidor →

Note what makes the pushback possible. Cline’s suggestion isn’t wrong; hourly reconciliation is a legitimate pattern at scale. It’s wrong for a two-person SaaS on Firebase’s free tier the day before launch, and that context lives only in Juan’s head. The AI optimizes for the general case; the owner holds the constraint that decides.

This is the working relationship entry 55-1 described, functioning under deadline pressure: let the AI draft the plan, but read the plan like someone who pays the hosting bill. The cheapest infrastructure is the job that never runs, and the fastest test is the one that doesn’t need a clock…