DEV Community

Cover image for Yo Vibe Coders, Stop Building FE Slop and Use Telegram Groups Instead
Ryo Suwito
Ryo Suwito

Posted on

Yo Vibe Coders, Stop Building FE Slop and Use Telegram Groups Instead

#ai #webdev #programming #productivity

We know. We KNOW. AI has been slopping you React frontends faster than you can say npm install. Tailwind components, shadcn copy-paste, v0 screenshots, the whole pipeline. Bro your "frontend" is just vibes and dependencies at this point 😮‍💨

But real talk — do you actually need a web interface, or do you just need something to interact with your backend?

Sit down. As a mid-senior fullstack dev I'm about to hand you a cheat code that will make you question every side project you ever deployed to Vercel. Grab a pen and paper fella because I'm only saying this once.

Your frontend is a Telegram group.

No seriously. Put the laptop down. Let that marinate.

The Stack (No Brainer Edition)

Here it is. The whole thing:

  • FastAPI — your backend. clean, fast, you already know it.
  • SQLite — your database. one file. on your disk. done.
  • ngrok — exposes your localhost to the world. free tier exists.
  • Telegram Bot — your entire frontend, UX, notification system, and auth layer.

Infra cost? Your potato PC and ngrok. That's it. Cope that your electricity doesn't go out randomly.

If you're feeling fancy, slap it on a $5 VPS and you're running a production-grade hobby setup. Whatever. Point is there's no AWS bill coming at the end of the month to ruin your weekend.

No Docker compose files with 9 services. No CI/CD pipeline. No node_modules folder eating 400MB of your SSD. No "deployment failed" notification at 2am.

Just:

uvicorn main:app --reload
ngrok http 8000
Enter fullscreen mode Exit fullscreen mode

and you're live. genuinely.

Groups Are Pages, Actually

Here's the mindset shift that breaks your brain in a good way.

Every Telegram group your bot is invited to = one page of your app.

🗂️  #dashboard   →  /bind overview
📦  #orders      →  /bind orders  
🔥  #logs        →  /bind monitor
💸  #billing     →  /bind finance
Enter fullscreen mode Exit fullscreen mode

How does the bot know which "page" it's on? chat_id. That's it. Every group has a unique chat_id. Your bot receives a message, checks the chat_id, looks up which service is bound to it, and routes accordingly.

You just built URL routing with zero code. Telegram handed it to you.

And look what you get for FREE on top of that:

  • Auth — Telegram users ARE their accounts. no JWT, no OAuth, no "forgot password" flow. they exist, they're in the group, they're authed.
  • Push notifications — just sendMessage to the group. that's a notification.
  • File handling — images, PDFs, CSVs. upload, download, just works.
  • Buttons — inline keyboards. no CSS. no click handlers. no state management. just a list of strings with callbacks.
  • Mobile + Desktop — Telegram runs everywhere. your "responsive design" is Telegram's problem now.
  • Audit log — the chat history IS your activity log. everything your bot ever posted, timestamped, searchable. for free.
  • Collaboration — multi-user? just invite them to the group. that's your RBAC.

You didn't build any of this. It was just there.

One Bot, Many Microservices (The Accidental Architecture)

Okay now it gets unhinged.

You can take this further. Same bot instance, different groups, each group bound to a completely different microservice.

Telegram
   │
   ├── group #A  (chat_id: 111) ──►  Service A  :8001
   ├── group #B  (chat_id: 222) ──►  Service B  :8002
   └── group #C  (chat_id: 333) ──►  Service C  :8003

         bot = your API gateway
Enter fullscreen mode Exit fullscreen mode

Your bot is literally just a router. It doesn't know what the services do. It just translates Telegram events into HTTP calls and Telegram messages back. Each service is dumb — it just returns "what to say." Clean separation. No service knows about Telegram at all.

And here's the kicker: your services are independently everything. Independent SQLite. Independent FastAPI instance. Independent deployment. You want to update the billing service? You restart :8002. The rest of your "app" doesn't flinch.

People pay real money for infra that does this — service discovery, routing, isolation. You got it by thinking about group chats differently. Congrats on your accidental microservices architecture. Put it on your CV.

Clear Chat = Refresh Page

This one is my favorite.

You know how sometimes your UI just feels cluttered? Too much state on screen, too many old messages, overwhelming?

You're an admin. Just clear the chat history.

Zero consequences. The bot doesn't care. FastAPI doesn't care. SQLite DEFINITELY doesn't care. The actual state of your app lives in your database. The chat is just the render buffer. Wipe it whenever.

It's like having a terminal you can clear without killing the process.

Compare this to a real frontend where "resetting UI state" is a whole ticket. localStorage cleanup, cache busting, Redux resets, "why is stale data still showing up." Two days of your life gone.

Or you could just... clear chat. as admin. in 2 taps.

Go Build Something

Look. This is for your hobby projects. To save you from Vercel bills, from npm hell, from building a whole React app for a thing your wife, neighbor, and dog are the only users of.

Share the groups with whoever needs access. That's your user management. That's your multi-tenant solution. You need more than that? Hire a proper team then. Okay? Good.

Now close this tab and go /bind something.

FastAPI + SQLite + ngrok + one Telegram bot. That's the stack. Touch grass after shipping.

Top comments (0)