Bulk Emails from a chat input — without Redis, queues, or worker services

I built a feature into my portfolio site that lets me paste a list of recruiter emails and a job description directly into a chat box.

Once I type my unlock passphrase, it automatically:

• generates a tailored email for each recruiter,
• attaches my resume,
• sends the emails,
• and streams live progress back into the same chat bubble.

The fun part is the architecture behind it.

There’s no Redis.
No BullMQ.
No QStash.
No separate worker service running somewhere.

It’s just:

• Next.js on Vercel
• Neon Postgres
• and after() from Next.js 15.

That’s it.

The idea

I originally started building it because I was tired of manually rewriting the same outreach emails over and over again while applying to jobs.

Most “AI job application tools” feel overly automated and spammy, so I wanted something smaller and more controlled:

• I still choose the recruiters
• I still provide the job description
• I still manually trigger it
• but the repetitive work disappears

The end result feels more like an assistant inside my portfolio chat than a mass-email bot.

Triggering the bulk flow

The detection logic lives directly inside the chat route.

If the message contains multiple email addresses and matches my existing outreach heuristic, the app switches into “bulk pipeline” mode.

const rows = buildRowsFromText(trimmed);

if (rows.length >= 2 && hasCurrentOutreachContext(trimmed)) {
  if (!authed) return lockResponse();

  const { runId } = await startBulkPipeline({
    rows,
    jobDescription: trimmed,
  });

  after(() => drainRun(runId));

  return NextResponse.json({
    reply: "📤 Sending applications...",
    pipelineRunId: runId,
  });
}

The important bit here is after().

In Next.js 15+, after() allows work to continue after the response has already been sent back to the client.

So the user instantly gets a response with a pipelineRunId, while the actual email processing continues in the same serverless invocation.

No worker queues.
No background containers.
No separate infrastructure.

Just the existing runtime continuing execution after the response flushes.

Honestly, this was the feature that made the whole architecture click for me.

Storage layer

I used two tables in Neon:

pipeline_runs

Stores batch-level state:

• status
• total jobs
• sent count
• failed count
• original job description

pipeline_jobs

Stores one row per recipient:

• email
• derived company name
• status
• attempts
• error messages

The processing loop atomically claims one queued job at a time:

UPDATE pipeline_jobs
   SET status = 'sending',
       attempts = attempts + 1
 WHERE id = (
   SELECT id
     FROM pipeline_jobs
    WHERE run_id = $1
      AND status = 'queued'
 ORDER BY created_at ASC
    LIMIT 1
 )
RETURNING *;

This makes retries safe and keeps the pipeline idempotent even if Vercel retries the invocation.

Generating the emails

For every claimed row, the flow is:

1. Extract the company name from the email domain
   ([e-mail] → “Stripe”)

2. Call Groq using llama-3.3-70b-versatile in structured JSON mode

3. Generate:
   

{
  "subject": "...",
  "body": "..."
}

1. Convert the plain text body into proper HTML:

• paragraphs
• bullet lists
• clickable links
• readable spacing

1. Send through Gmail SMTP using Nodemailer

2. Mark the row as sent

I also intentionally made the fallback behavior conservative.

If someone uses a Gmail or generic email address, the system falls back to “Hiring Team” instead of hallucinating fake company names.

Small detail, but it makes the emails feel way more natural.

Live progress in the chat UI

The response includes a pipelineRunId.

The frontend attaches that ID directly to the assistant message, and a <PipelineProgress /> component renders underneath the same chat bubble.

It polls:

GET /api/lab/pipeline/[runId]

every ~1.5 seconds until the run finishes.

I considered SSE/websockets, but honestly polling was simpler and more reliable for Vercel Hobby deployments.

Sometimes boring engineering decisions are the correct ones.

Tradeoffs

This setup definitely has limits.

Function timeout

Vercel Hobby gives ~60 seconds.

Each email takes roughly:

• LLM generation
• SMTP send
• DB updates

About 3–4 seconds total per row.

So realistically one invocation comfortably handles ~10–15 emails.

For my use case (“apply to a few recruiters at a time”), that’s completely fine.

If I ever needed larger batches, I’d probably chunk the drain process and self-fanout recursively.

Gmail SMTP limits

Gmail caps daily sends.

Again, acceptable for personal usage.

Switching to Resend or SendGrid would basically be changing one file.

after() durability

This is probably the biggest tradeoff.

If the serverless invocation dies midway through processing, remaining rows simply stay in queued.

Right now there’s no recovery daemon.
No retry cron.
No dead-letter queue.

And honestly?

I haven’t needed one yet.

Why I skipped BullMQ, QStash, and Inngest

I actually started with BullMQ.

Then I remembered:

• BullMQ wants Redis
• Redis wants a worker process
• worker processes don’t really fit Vercel well

I tried QStash too.
It worked.

But it also felt like I was introducing another service for a scale problem I didn’t actually have.

Same with Inngest.

Eventually I realized:

• the runtime already exists
• the database already exists
• Next.js already provides after()

So I stopped overengineering it.

The entire system is roughly ~250 lines.

No orchestration layer.
No infra maze.
No queue dashboards.

Just a simple pipeline that solves the actual problem.

And honestly, that ended up being the right architecture.