The Background Jobs System I Built and Why I Removed It

By Neel Vora

This post walks through how I built background Jobs System I Built and Why I Removed It, and where it fits in the rest of my work.

Large government platforms with heavy traffic taught me that anything slow needs to run in the background - patterns I now apply to AI workloads.

At one point I needed a way to run recurring maintenance tasks for my portfolio.

Examples included:

• Cleaning old analytics events
• Generating scheduled summaries
• Running health checks
• Resetting temporary RAG data

So I designed a small background job system using Vercel cron.

The cron setup

I created endpoints like:

• /api/jobs/daily
• /api/jobs/hourly

Each one ran logic that used Supabase to clean or update certain records.

Vercel supports cron through its dashboard. It worked well until deployment conflicts began showing up.

Why I removed it

My site is very active during development, and the cron system triggered at the wrong times during builds.

The main issues were:

• Conflicts during redeploys
• Delayed builds caused by pending cron invocations
• No need for long term scheduled automation yet

The takeaway

The architecture is sound. The timing was not.

I plan to reintroduce a more robust background job system later using something like Fly.io machines or Supabase functions.

Keep exploring

From here you can:

• Visit /neel-vora for more background about me and my work.
• Browse more posts on the blog.