Skip to main content

Command Palette

Search for a command to run...

Stop Using AI Widgets: How I Built a Human-in-the-loop Chatbot

Why I rejected complex realtime infrastructure for simple polling. A design engineer’s guide to connecting Next.js, Redis & Telegram without the bloat

Updated
4 min read
Stop Using AI Widgets: How I Built a Human-in-the-loop Chatbot

You know exactly the kind of chatbot I’m talking about.

You land on a portfolio, the little bubble pops up with a stock sound effect, and you’re greeted by "Support Agent #4" asking for your email before you’ve even read the hero section. It’s not a conversation; it’s a lead magnet dressed up as a human.

I didn’t want that.

I didn’t want a third-party script slowing down my First Contentful Paint, and I definitely didn’t want to pay $29/month for a SaaS tool to talk to the three people who visit my site daily.

I wanted a human-in-the-loop system. User types on website → I get a ping on Telegram → I reply → User sees it on the site.

No dashboards. No "we'll get back to you." Just me, replying while I’m out trekking or debugging code.

Here is why I built a custom, "dumb" architecture using Next.js, Redis, and Telegram, and why it works better than the "smart" solutions the market tries to sell you.

Must tryout live : https://babacreates.in/


The Requirement Arbitrage

In engineering, we often grab the "industry standard" tool without asking if we actually have an "industry standard" problem.

The market builds chatbots for scale. Intercom, Drift, and Zendesk are designed for teams of 50 agents handling 10,000 concurrent users. They need WebSockets. They need complex ticket routing. They need heavy client-side JavaScript bundles to manage state.

I am not a corporation. I am one guy with a Next.js portfolio.

This creates a massive gap, a requirement arbitrage. The market solves for complexity I don't have. By rejecting their constraints (scale, multiple agents, 24/7 uptime), I can build something drastically simpler, lighter, and faster.

I don’t need a system that scales to millions. I need a system that scales to me.


The Stack: Why Telegram?

Most devs build a custom admin panel for their portfolio. They spend three weeks building a dashboard with auth, database tables, and a UI to view messages.

That’s pure procrastination.

I realized I already have a high-performance, push-notification-enabled, zero-latency admin panel in my pocket: Telegram.

By using the Telegram Bot API, I offload the entire "admin" UI.

  • Notification system? Built-in.

  • Mobile app? Native and fast.

  • Media support? Done.

My "backend" isn't a dashboard I have to log into; it's a chat thread I’m already looking at.


The "Controversial" Choice: Polling > WebSockets

If I posted this code on Twitter/X, someone would immediately comment: "Bro, why didn't you use Socket.io? Polling is so 2010."

And they’d be wrong.

WebSockets are great, but they require a persistent connection. On a serverless environment like Vercel (Next.js), maintaining a persistent WebSocket connection is a headache. You usually have to spin up a separate Node server or pay for a managed WebSocket service.

For a portfolio? That’s overkill.

I used Short Polling. The frontend simply asks the API: "Hey, any new messages?" every few seconds.

  • It’s stateless: Perfect for serverless functions.

  • It’s cheap: I’m not paying for idle connections.

  • It’s robust: If the user’s network flakily drops and reconnects, polling just works.


How It actually works

The flow is stupidly simple, which is why it’s resilient.

  1. User sends message: Next.js API route catches it.

  2. Storage: Saved to Redis (Upstash) with a TTL (Time To Live). Conversations auto-delete after a month. No database clutter.

  3. Forwarding: The API hits the Telegram endpoint.

  4. My Phone Buzzes: I see the message. I reply: "Yeah, I'm free for freelance work next month."

  5. The Webhook: Telegram hits my API with my reply.

  6. The Loop: My API saves my reply to Redis. The frontend polls it.

The user sees my reply appear on their screen. They don't know it traveled through a Russian messaging app and a serverless Redis instance. They just know I replied fast.


Design Engineering

This wasn't just a backend project. As a design engineer, the feel mattered.

I used Motion for the UI. The chat widget doesn't aggressively pop up; it rests in the corner. When you open it, it expands with a spring animation, not a linear CSS transition.

I even added a cool notification sound. Instead of a generic beep, I found a soft, organic "pop" sound. It’s subtle. It feels premium.

These details matter. A portfolio isn't just a showcase of your code; it's a showcase of your taste.


TLDR;

Most portfolios scream, "Look at my tech stack!" This chatbot quietly says, "I solve problems efficiently."

It’s not AI. It’s not a sales funnel. It’s just a direct line to me, built on the principle that the best code is usually the code you didn't have to write.

If you’re building a portfolio, stop over-engineering the things that don't matter so you can focus on the things that do. And sometimes, that means using polling instead of WebSockets.

Checkout mine : https://babacreates.in/