Key takeaway: Most "dashboard" requests are really three alerts and a daily number — a Telegram bot, Make, and Google Sheets can deliver that in four hours instead of an eight-week React build.
Half the time a client asks for a "dashboard", they don't actually want a dashboard. They want three things: tell me when X happens, let me see today's number, ping the team when Y breaks. That is not a custom internal tool with a React frontend and an eight-week timeline. That is a Telegram bot, Make, Google Sheets, and about four hours of work.
This is the pattern we reach for first. Build the $20k thing only when the $200 thing genuinely can't do the job.
The three real jobs behind "dashboard"
Before anything else, pin down what the client actually needs. In our experience it almost always collapses to some mix of these three jobs.
Notify me when something important happens. A proposal gets signed, a refund comes in, a support ticket stays open longer than the SLA. The client doesn't want to check a screen — they want a ping in the channel they already live in.
Let me check today's number on demand. How many leads came in today. What's MRR right now. How many demos booked this week. A single number, answered fast, without logging into anything.
Alert the team when something breaks. A form stops submitting. A scheduled job fails. A conversion rate falls below threshold. Again, a notification, in a place people already look.
A real dashboard is built for exploring data. These three jobs aren't exploration. They're operational awareness. Telegram handles operational awareness better than any custom UI.
The stack
Four pieces. That's the whole thing.
Webhook in. Something happens — a form submission, a Stripe event, a calendar booking, a database row. The source system POSTs JSON to a Make webhook URL.
Make as the router. Make receives the webhook and applies whatever filtering and enrichment is needed. This is the only place any real logic lives. Filter out test events, look up the client name by ID, format the message, decide whether to notify or just log.
Google Sheets as the state store. Every event gets appended to a sheet. That sheet is the state. If you want "today's number", Make reads the sheet and sums it. If you want "this week's conversions", same thing. Sheets is free, the team already knows how to read it, and it's perfectly adequate for anything under a few thousand rows per month.
Telegram Bot API as the output. Make calls the bot's sendMessage endpoint with a pre-formatted message. The team sees it in the group. Done.
Build time for the simple version: four hours, and most of that is writing the Telegram message templates so they don't look like spam.
We run this on ourselves
The most useful version of this pattern in our own studio is the proposal notifier.
When a client signs a proposal in our CRM, a webhook fires to Make. Make pulls the client name and proposal value, formats a message — "Proposal signed: [Client name] — [Project] — [Value]. Owner: [Lead]" — and posts it to our internal Telegram group. At the same time it appends a row to a Google Sheet with the date, client, value, and owner. At the end of the week, a Make schedule reads that sheet and posts the week's total to the same channel.
The team gets a real-time pulse. The owner gets public accountability. We get a rolling weekly number without anyone ever opening a dashboard. Total build time, including the message templates we tweaked twice: about three hours.
The same pattern runs our chatbot lead capture. Look at chatbot-api.php — when the conversation detects [LEAD_CAPTURED], the PHP posts a JSON payload to a Make webhook. Make routes it to Telegram so the sales team sees the lead and the full conversation the moment it happens. It also drops a row into leads.csv as backup. Same structure. Webhook in, Make in the middle, Telegram + Sheets out.
The AI Business Analyst uses the exact same pattern on its /api/leads endpoint. Email and business URL go in, Make forwards the payload to Telegram and email. No database, no admin panel, no dashboard screen. The webhook is the interface.
About to quote a $20k dashboard?
Tell us what it's really for. Half the time there's a four-hour version that does the job better.
A recipe you can copy
Here's the "notify me when a new lead comes in" build, step by step. This takes about forty-five minutes if you've never done it before.
- Create a new Telegram bot via
@BotFather. Save the bot token. - Add the bot to your team's Telegram group. Grab the chat ID — easiest is to post a message and call
getUpdatesonce. - In Make, create a new scenario starting with a Webhook trigger. Copy the webhook URL.
- In your app — in our case, the form handler or API endpoint — POST a JSON payload to that URL on every lead event.
{ "name": "...", "email": "...", "source": "..." }. - In Make, add a Google Sheets "Add a row" step after the webhook. Map the payload fields to columns. This is your state store.
- Add an HTTP module that calls
https://api.telegram.org/bot<TOKEN>/sendMessagewith JSON{ chat_id, text }. Format the text to include the lead's name, email, and source. - Optional: add a Make filter so only real leads trigger the Telegram step — test submissions go to the sheet only.
- Activate. Submit a test lead. Watch the group.
That's a functional lead-notification system. Add a daily digest by creating a second scenario on a schedule that reads the sheet, sums today's rows, and posts the total. Add an on-demand check by creating a third scenario triggered by a specific bot command.
Every extension is another small scenario, not a new architecture.
When this stops working
This pattern is great until it isn't. Three signals mean it's time to build the real thing.
Real-time collaboration. If two or more people need to look at the same view at the same time and mutate it — assign owners, change statuses, add notes that affect each other — Telegram and Sheets will turn into a mess within a month.
Permissions matrix. If different team members need to see different subsets of the data, or there's sensitive information only some people should see, you've outgrown a shared Telegram group. Sheets row-level permissions are possible but painful.
More than five stakeholders. The group chat model works beautifully up to about five people paying attention. Past that, messages get missed, threads get noisy, and the team mutes the channel. At that point you need proper state and a proper UI.
If none of those three apply, you probably don't need the $20k build. You need the four-hour one.
Build small first, always
The point isn't that Telegram bots beat dashboards. They don't, for dashboard-shaped problems. The point is that most "dashboard" requests are actually notification problems wearing a dashboard costume. Solve for the real job.
Ship the four-hour version. Run it for a month. If the team is genuinely constrained by it, then spend the $20k — with a much sharper idea of what to build.
If you want help picking the right-sized solution, we'd rather talk you out of the expensive one than sell it to you.
Right-sized ops tooling, shipped in a week.
We'd rather talk you out of the expensive build than sell it to you.
