← Blog

When to automate: a Telegram-to-Notion bot in a day

· 5 min read

Contents
  1. How it works
  2. Evaluating the build approach
  3. Option A: n8n or Zapier
  4. Option B: Write a microservice and deploy it (Render, Fly, etc.)
  5. Option C: Lovable
  6. My requirements for the MVP
  7. The build
  8. Making it reusable
  9. What comes next

I get tagged in our "Envoy - Product & Dev" Telegram group whenever someone raises an issue. Every time, I do the same thing: copy the message, open Notion, navigate to the Kanban board, create a ticket. Once or twice a day, every day.

The workflow is predictable and it interrupts focus. That is enough to justify automation. Not because I hate busywork, but because predictable workflows that break flow are the easiest wins to capture.

The goal: let someone file a ticket on the go, inside Telegram, without opening Notion. In one day, I shipped a Telegram bot that creates Notion tickets, a small admin page to map chats to databases, and a workflow that handles group chat edge cases.

#How it works

Someone tags the bot on a message in a Telegram group. The app extracts the message text and metadata, looks up a mapping for that chat (which Notion database to use), creates a page in Notion, and replies with a confirmation and ticket link. The first version does not need to be clever.

#Evaluating the build approach

I have built similar workflows before at Ninja Van. Back then, even a "simple" bot took a day or two because you have to do everything manually: read docs, write the service, set up hosting, handle keys, deploy, debug in production.

This time I wanted to push build speed as far as possible while keeping overhead low. Here is how I evaluated the options:

#Option A: n8n or Zapier

Pros:

  • Fast to connect APIs.
  • Good for linear workflows.
  • Low code.

Cons:

  • You still end up managing quirks and edge cases, especially with Telegram group chat behaviour.
  • Harder to build a proper admin surface (for example mapping multiple Telegram channels to different Notion databases) without it becoming a mess of zaps and conditional blocks.
  • Pricing and limits can become annoying once usage grows.
  • I'll still have to spend time debugging and "building", which could take more than a day.

#Option B: Write a microservice and deploy it (Render, Fly, etc.)

Pros:

  • Maximum control.
  • Easy to evolve into a "real" internal tool.
  • Debuggability and observability are fully yours.
  • More scalable in the long term if lots of logic needs to be added on.

Cons:

  • More operational overhead: hosting, secrets, deploy pipeline, logs, restarts.
  • Longer time to first working MVP.
  • You own maintenance forever, even if the tool is tiny.

#Option C: Lovable

Pros:

  • Fastest path to a working end-to-end app, including UI and deployment.
  • Handles a lot of setup that normally eats time (project structure, basic data models, wiring).
  • The agent flow now asks clarifying questions, which reduces wrong turns.
  • There is no vendor lock-in: you own the code and can self-host the supabase / frontend if you wish.

Cons:

  • It is still a black box in parts, especially when debugging gets non-trivial.
  • You are constrained by how the platform wants to structure the app.

Given my requirements, Lovable was the best fit. As a side note: I've been building a ton on Lovable over the last few months, so it's become my go-to for micro projects like this.

#My requirements for the MVP

I kept the bar intentionally low:

  • Ship an MVP fast.
  • Minimal overhead to maintain.
  • Easy to iterate.

If it worked reliably for one of the group chats, it was already a win. And I can easily scale this to each group later on.

#The build

My workflow for micro projects like this: write a short PRD in ChatGPT (speed and direction, not perfection), then feed it into Lovable. This prevents the worst failure mode with AI code generation — confidently implementing the wrong thing.

The interesting part was not the happy path. It was the edge cases.

Telegram's API is straightforward in isolation, but it gets finicky in group contexts. Messages arrive in different shapes depending on whether it is a mention, a reply, or a forward. Reply routing matters — you want to reply to the original message, not just post a new one, and in topic-based groups you need to preserve thread context. Privacy mode prevents the bot from seeing non-command messages unless it is mentioned.

These are the failures that take the most time to debug when building quickly. In the past, that meant reading Telegram docs, tailing logs, tunnelling with ngrok, and working backwards. Here, Lovable read the logs and pointed out the missing pieces, which cut debugging time significantly.

After about half an hour of teething issues, it worked reliably.

#Making it reusable

I kept a small admin view with channel mappings (Telegram group → Notion database) and error traces. This makes it a reusable internal tool, not just my personal automation.

#What comes next

The baseline works. The next upgrades are obvious: handle follow-up replies and append them to the same ticket, send a daily digest, auto-triage by type and urgency.

Longer term, this can evolve into a proper AI concierge for internal operations. But that only matters if the boring parts — capture, routing, visibility — are already reliable.

Update (March 2026): This bot was the starting point for a much bigger shift. I've since written about building full AI agents for Voltade using OpenClaw, including one that handles customer support and ticket creation across 28 WhatsApp groups. I also wrote about why this kind of AI-native service is replacing SaaS as a business model.

More from Blog