For a first app, answer “just do it now” when the work finishes in a few seconds while the person waits, and answer “a queue” when it runs longer than that or has to repeat for many items. Answer “a cron job” only when the work happens on a clock with nobody waiting, like a nightly cleanup or a weekly email.
Most of what a first app does belongs in the first bucket. Saving a form, loading a page, logging someone in: these take well under a second and nobody needs machinery for them. The moment your builder is asking is usually the moment it just met a task that is not like that. Processing ten uploaded photos through an AI, sending a hundred emails, building a big report. Those are the tasks the other two answers exist for.
What each answer means in plain words
“Just do it now” means the work happens inside the request itself. The person clicks, the server does the job, the server answers, the page updates. Simple, and right for anything quick. The catch is that hosting like Vercel gives each request a hard time limit, measured in minutes on the free plan, and a browser tab that shows a spinner for that long looks broken long before the limit hits. Work that might take longer than a person is willing to stare at a spinner does not belong here.
A queue is a service that holds a list of jobs and hands them out to be done one at a time, a little later, with nobody waiting. Your server accepts the click, writes “ten photos, in progress” somewhere, drops ten small jobs on the queue, and answers the person immediately. The queue then calls your server back once per job. Each callback is a fresh, short request that finishes well inside the limit. Upstash’s QStash, one popular queue for apps on Vercel, describes itself as serverless messaging and scheduling that guarantees delivery and retries on failure, which is the whole point: a job that fails gets tried again instead of silently vanishing.
A cron job is a timer. You tell the hosting “at this time every day, call this address,” and it does. Vercel’s own cron jobs work by sending a request to your app on the schedule you set, and on the free Hobby plan they may run once a day and land anywhere within the scheduled hour. That is fine for a nightly tidy-up. It is the wrong tool when a person is waiting, because a timer does not know about the person.
The two things that flip the answer
First, how long the work takes, honestly. Not how long it takes on a good day with one item. How long it takes with the most items a real user might throw at it, and with the AI being slow. If that number is more than a few seconds, “just do it now” will produce the exact symptom you are probably already seeing: a spinner that never stops, a timeout error, and a user who clicks again and doubles the mess. That is a queue.
Second, whether anyone is waiting. If a person clicked and wants a result, the work should start now, in the background if it must, and show progress. If nobody clicked, and the work is “every night” or “every Monday,” that is a cron job. A cron job that then finds a lot of work to do can hand each piece to the queue, so the two combine well rather than compete.
There is a third case worth naming. Sometimes the slow thing is one long answer from an AI, like writing a whole itinerary. That is a single stream of text rather than batch work, and the better fix is to show the words as they arrive rather than to queue anything. If your builder asks about a queue for that, the honest answer is that it needs streaming, which is a different fix altogether.
What a wrong pick costs
Choosing “just do it now” for slow work is the mistake that costs you users. Half-finished batches, duplicate processing when people retry, and an app that feels broken at the moment it is doing the most for someone. It is also the mistake that is cheapest to correct: the code that does the work stays, and your builder wraps it so the request returns at once and the queue runs the pieces.
Choosing a queue for quick work is a small waste. One more service in your account, a little more to reason about, and a delay of a second or two where none was needed. Not fatal, but not free.
Choosing a cron job when a person is waiting is the odd one, and it happens when a builder reaches for the tool it knows. The person clicks at 2pm and the job runs at midnight. Users do not forgive that.
What to tell your builder
Paste this back, if your task is the slow kind:
“Accept the request right away, put each item on a queue that calls the app back one item at a time, save progress as it goes, and show the person a progress bar instead of a spinner.”
If the task is quick, tell it to just do the work in the request. If the task runs on a schedule with nobody waiting, tell it to use a cron job. One sentence each, and let it get on with it.
You can learn more, and get the full prompts and the decision tables, in our course: Lesson 18, The Eternal Spinner. The first lesson is free, no card.
In the next ten minutes, do the honest timing test. Give your app the biggest input a real person would, and watch the clock. Under a few seconds, you are done and can say so. Over that, paste the sentence above and ask your builder to explain, before it writes anything, what happens if a person clicks the button twice.