A Telegram Mini App is a web app that opens inside Telegram, with the user already signed in and already in the right chat. That is the whole pitch: no new account, no download, no password reset. I build them the same way I build any production web product - Next.js and TypeScript on the front, Node.js on the back - plus a few rules that only exist inside Telegram. The most recent one I shipped was a fintech Web & Mini App under NDA, with virtual and physical cards on Next.js, Express, and MongoDB.
It starts with the bot. BotFather creates the bot and the Mini App, and the user can open it from the menu button, an inline keyboard button, or a direct t.me link with a startapp parameter - which is how I pass a referral code or deep-link into a specific screen. The app is served over HTTPS from a normal host; in development a tunnel points Telegram at localhost, so I test on a real phone, not just a desktop browser.
Auth is the part I never cut corners on. Telegram hands the app initData - user id, name, auth_date, and a hash. initDataUnsafe is exactly what it sounds like: fine for showing a name, never for trusting. The backend validates the raw initData with an HMAC signature derived from the bot token, checks that auth_date is fresh, and only then issues its own session. The bot token never leaves the server. In a fintech product, that single check is the difference between “logged in via Telegram” and “anyone with devtools can be anyone.”
Then the Mini App has to feel native, not like a website pasted into a webview. I read themeParams and Telegram’s CSS variables so light and dark follow the user’s app, use the MainButton and BackButton instead of drawing my own, add haptic feedback on the actions that matter, and respect the viewport and safe-area insets so nothing hides under the header or the home indicator. Mobile-first is not a slogan here - most sessions are one thumb on a phone.
The bot and the Mini App work as a pair. The bot sends notifications, confirmations, and receipts; the Mini App handles the screens that need a form, a list, or a checkout. Webhooks land on the Node.js backend, which stays the single source of truth for payments and state - the client asks, it never decides. Digital goods inside Telegram are paid in Stars, while physical goods and services can go through payment providers, so I settle that with the client early - it shapes the whole flow.
What I refuse: trusting initDataUnsafe, a desktop website squeezed into a webview, a checkout that lives only in the frontend, and a Mini App with no web door when the business also needs SEO or an office dashboard. If you want to ship inside Telegram, send me the one action a user should complete in the chat. I will reply with the bot flow, the Mini App screens, and what stays on the server.
Give the next product someone who stays.
Ready to get started? Send me a message - I'm available to start now and to stay. Long-term retainers, not a two-week handoff. Let's discuss your project, requirements, and the best way to move forward.