Kort samengevat. Een Telegram-bot met een echt gebruikersbestand en een backend erachter kan in ongeveer zes weken een opgeleverde app voor iOS en Android worden — niet omdat het werk triviaal is, maar omdat de lastige productvraag (wil hier iemand op zitten?) al beantwoord is. Dit stuk is het plan per week: wat er wanneer gebouwd wordt, waar de zes weken werkelijk heen gaan, hoe je 50.000 gebruikers migreert zonder ze te verliezen, en de specifieke dingen die van zes weken vier maanden maken. Wil je jezelf eerst toetsen, dan staat op de dienstpagina van chatbot naar app een checklist.

Wil je alleen de planning, spring dan naar het plan van zes weken.

De uitgangssituatie

Stel je de positie voor waarin je zit — het is een goede. Je lanceerde een of twee jaar geleden een Telegram-bot om een idee te toetsen. Het werkte. Je hebt nu 50.000 gebruikers die hem openen, gebruiken en af en toe voor betalen. De bot doet iets echts: een sportcoach, een AI-assistent, een uitgavenoverzicht, een taalleraar, een marktplaats — de categorie doet er voor dit stuk niet toe. Wat telt is dat je hebt op een platform dat je niet bezit.

En dat platform begint pijn te doen. Gebruikers vragen om dingen die de bot niet kan. Je kunt geen pushmelding sturen zonder dat die in een gedempt kanaal belandt. Je kunt niet factureren zoals je wilt. Een wijziging in de Telegram Bot API brak vorig kwartaal een stroom en je bracht een weekend brandjes blussend door. Je bent succesvol ondanks het platform, en je voelt het plafond.

Dus je wilt een app. De vraag die elke oprichter in die positie stelt is dezelfde: hoe lang duurt het, en hoe raken we de 50k gebruikers die we al hebben niet kwijt?

Het eerlijke antwoord voor een grote groep bots is zes weken tot een gelanceerde app, plus een geleidelijke migratie die parallel loopt en eindigt wanneer jij besluit dat hij klaar is. Dit is waarom dat getal realistisch is, en waar de tijd precies heen gaat.

De doorloop hieronder is een samenstelling — het is het plan dat we in delen hebben gedraaid bij echte chatzware Flutter-projecten als Arcana (een streamende AI-chatclient opgeleverd in drie weken) en YouMi (een realtime berichtenapp die we in twee weken stabiliseerden). Geen enkele klant is "de bot met 50k", maar elke stap hier is iets wat we werkelijk hebben gedaan.

Waarom zes weken realistisch is (en wanneer niet)

Zes weken klinkt ambitieus tot je bedenkt wat je niet doet.

Je ontdekt het product niet. Je doet geen gebruikersonderzoek om uit te zoeken wat je moet bouwen — je bot is twee jaar gebruikersonderzoek. Je ontwerpt geen nieuw interactiemodel — de gespreksstroom werkt al en die houd je grotendeels. Je toetst de vraag niet — 50.000 mensen hebben die al bevestigd.

Wat overblijft is uitvoering tegen een bekende specificatie, en dat is het deel dat samendrukt. Eén Flutter-codebase komt tegelijk op iOS en Android uit (we schreven over waarom één codebase twee native trajecten verslaat), dus je betaalt hetzelfde werk niet twee keer. De backend bestaat grotendeels. De functielijst is eindig en al beproefd in productie.

Zes weken is realistisch wanneer:

  • Je bot al met een backend-API praat, niet alleen met de servers van Telegram.
  • De functieset chatgericht is plus een handvol schermen — geen uitdijende superapp.
  • Je één beslisser hebt die ontwerpen en scope kan goedkeuren zonder commissie.
  • Je bereid bent een scherpe v1 te lanceren en de lange staart na livegang toe te voegen.

Zes weken is niet realistisch wanneer de bot geen aparte backend heeft en alle logica in bot-handlers zit (tel 2 tot 3 weken op om een API te lichten), wanneer je een volledig eigen designsysteem vanaf nul nodig hebt, of wanneer "gelijkwaardigheid" stiekem vijftig randgevalcommando's betekent die elk een eigen scherm nodig hebben. Daar komen we op terug bij wat de planning opblaast.

Het plan van zes weken, week voor week

Dit is de planning die we draaien. De weken overlappen meer dan deze lineaire lijst suggereert — ontwerp begint terwijl de audit afloopt, het winkelpapierwerk begint op dag één — maar het kritieke pad ziet er zo uit.

Week 1 — Audit en functies in kaart brengen

We lopen de bot commando voor commando en stroom voor stroom door en schrijven op wat hij allemaal doet. Elk /commando, elk inline toetsenbord, elk gesprek in meerdere stappen, elke koppeling, elk betaalpad. Dat wordt de specificatie, en het is het belangrijkste stuk van het hele project.

Vervolgens koppelen we elke mogelijkheid van de bot aan het equivalent in de app en sorteren die in drie bakken:

  • Houden als chat. De gesprekskern blijft gesprek — dat is wat je gebruikers kennen.
  • Promoveren naar een scherm. Dingen die je in de chat propte omdat de bot je dwong (instellingen, geschiedenis, dashboards, profielen) worden echte schermen.
  • Schrappen uit v1. De commando's waar 2% van de gebruikers aan komt. Die gaan op de lijst voor na de lancering, niet op het kritieke pad.

In die derde bak worden de zes weken gewonnen of verloren. De uitkomst van week één is een afgetekende scope: een concrete lijst van wat er in v1 uitkomt.

Week 2 — Architectuur en de API-vraag

De app moet met een backend praten. Het gunstigste geval is dat je bot dat al doet en de app simpelweg dezelfde endpoints aanroept. We ontwerpen de clientarchitectuur rond je bestaande API — authenticatie, datamodellen, realtimekanalen — zonder de backend te herbouwen.

Heeft je bot geen aparte backend (alle logica binnen de Telegram-handlers), dan lichten we hier een dunne API-laag zodat bot en app die kunnen delen. Dat is de ene situatie die terecht tijd kost, en we signaleren die op dag één in plaats van hem in week vier te ontdekken.

Deze week worden ook de twee onderdelen vastgelegd die chatapps stilletjes laten zinken:

  • Realtime berichten — een deugdelijke WebSocket-levenscyclus: opnieuw verbinden, berichtenwachtrij, statesynchronisatie. Dit verkeerd doen is precies waarvoor we bij YouMi werden gehaald, waar gebruikers midden in een gesprek wegvielen. Het is weinig glamoureus en het is het verschil tussen een app die werkt en een app die werkt zolang er niets misgaat.
  • Pushmeldingen — APNs en FCM vroeg aangesloten, want meldingen zijn de halve reden dat je Telegram verlaat.

Week 3 en 4 — Bouw de kern

Dit is het zwaarste stuk: de app zelf. In één Flutter-codebase bouwt het team:

  • De chatinterface — soepel scrollen door duizenden berichten, rijke media, streamende antwoorden als je bot op AI draait (het incrementele Markdown-renderen dat we voor Arcana bouwden leeft hier).
  • Authenticatie — telefoon, e-mail of social login, gekoppeld aan je bestaande gebruikersidentiteiten zodat accounts meegaan.
  • De gepromoveerde schermen uit week één — dashboards, geschiedenis, instellingen, profielen.
  • Pushmeldingen van begin tot eind, op jouw schema en jouw voorwaarden.

Aan het eind van elke week krijg je een demobuild. Geen statusmail — een installeerbare build op een echt toestel. Dat is niet onderhandelbaar: wekelijkse builds zijn hoe uitdijende scope wordt betrapt terwijl hij nog goedkoop te herstellen is.

Week 5 — Migratieleidingen en voorbereiding voor de winkels

Nu het deel dat uniek is voor migreren in plaats van nieuw bouwen. Drie dingen lopen parallel:

  • Accounts koppelen. Een gebruiker opent de app en bewijst dat hij dezelfde persoon is die de bot gebruikte — meestal een met één tik vanuit de bot met een ondertekend token, of een match op telefoon of e-mail. Zijn geschiedenis en gegevens komen mee.
  • Indienen bij de winkels. Vermeldingen in de App Store en Google Play, schermafbeeldingen, privacyverklaringen, indienen ter beoordeling. De beoordelingswachtrij van Apple is de ene externe afhankelijkheid die je niet volledig in de hand hebt, en daarom begint dit nu en niet in week zes.
  • De brug in de bot. De bot zelf wordt je beste wervingskanaal. We voegen een aankondigingsstroom en deep links toe zodat de 50k gebruikers over de app horen binnen het hulpmiddel dat ze toch al dagelijks openen.

Week 6 — Lancering en het begin van de migratie

De app gaat live. Maar "lancering" betekent geen harde omschakeling — en dat is het deel waar oprichters zich het meest zorgen over maken, dus laten we precies zijn.

Je zet de bot niet uit. De bot blijft draaien. Op de lanceerdag begint hij gebruikers met een deep link naar de app te duwen, maar wie dat negeert gebruikt de bot precies zoals voorheen. Niemand wordt buitengesloten, er breekt niets, en je 50k gebruikers lopen niet weg door een gedwongen migratie.

Migratie wordt een knop die je in de weken erna verder draait: eerst een banner, dan een zachtere prompt, dan functies die alleen in de app zitten en mensen vanzelf overhalen. Veel producten houden permanent een vereenvoudigde bot als tweede ingang. Jij bepaalt het tempo; dat de app op dag één live staat is wat week zes oplevert.

Hoe je 50.000 gebruikers niet kwijtraakt

Dit verdient een eigen kopje omdat het de echte angst is, en de mechaniek is rechttoe rechtaan zodra je haar ziet.

  1. Parallel draaien, geen omschakeling. Bot en app bestaan naast elkaar. Er is nooit een moment waarop de enige optie van een gebruiker is: "download de app of verlies je toegang."
  2. De bot is het migratiekanaal. Je koopt geen advertenties om deze gebruikers te vinden — ze praten al dagelijks met je. Een deep link in de bot converteert veel beter dan welke koude installatiecampagne ook, en hij is gratis.
  3. Accounts en geschiedenis gaan mee. Tokens in de deep link of een match op telefoon of e-mail zorgen dat een gebruiker inlogt en zijn gegevens al aantreft. De app voelt als een upgrade, niet als opnieuw beginnen.
  4. Geleidelijke prikkels, geen dwang. Functies die alleen in de app zitten, betere meldingen en een prettigere ervaring trekken gebruikers mee. Ze met een harde deadline duwen duwt sommigen er helemaal uit.

Zo aangepakt is migratie geen risicovolle gebeurtenis — het is een curve die je zelf bepaalt, met de bot de hele tijd als vangnet.

Wat van zes weken vier maanden maakt

Eerlijkheid over de faalwijzen, want ze zijn voorspelbaar:

  • Geen backend om mee te praten. Zit elk stukje logica in Telegram-handlers zonder API, dan kost er een lichten 2 tot 3 weken extra. De moeite waard — het is het fundament waar al het andere op staat — maar het is echte tijd.
  • "Gelijkwaardigheid" betekent alles. Erop staan dat v1 alle 60 commando's meebrengt, inclusief die waar 2% van de gebruikers aan komt, is de meest voorkomende planningsmoordenaar. Lever de kern, voeg de staart na de lancering toe.
  • Ontwerp vanaf een leeg vel. Een eigen designsysteem dat tijdens de bouw wordt verzonnen kost weken. Een net, conventioneel ontwerp toegepast op een bekende stroom niet.
  • Besluiten per commissie. Zes weken gaat ervan uit dat iemand een scherm kan goedkeuren op de dag dat hij het ziet. Wacht elk besluit een week op een vergadering, dan bepaalt de kalender het tempo, niet de engineering.
  • Een redding, geen bouw. Ligt er een half afgemaakte app die stukgaat, dan is geërfde problemen herstellen een ander werk dan schoon beginnen — dat is de situatie van YouMi, en die wordt apart afgebakend.

Niets hiervan is een raadsel. We brengen het in week één naar boven, en dat is precies waarom we met een audit beginnen en niet met een strokenplanning.

Wat het kost

Een rechttoe rechtaan migratie op deze planning — kernfuncties behouden, chatinterface, authenticatie, pushmeldingen, publicatie in de winkels en gebruikersmigratie — komt uit in de bandbreedte € 4.000-8.000 over vier tot zes weken. Functierijke bots met betalingen, offline werken en eigen schermen kosten meer en duren langer; op AI gebaseerde bots met streaming en realtime renderen nog meer. De volledige uitsplitsing per niveau staat op de dienstpagina van chatbot naar app, en het kostenmodel legt uit hoe scope tot het eindbedrag optelt.

Het punt dat het waard is je eigen te maken: het dure deel van een app bouwen is product-market fit vinden, en die rekening heb je al betaald met je bot. De migratie is het goedkope deel. Je zet bewezen vraag om in een product dat je zelf bezit — en dat is een veel betere uitgangspositie dan de oprichter die naar een leeg Figma-bestand staart en gokt wat hij moet bouwen.

Veelgestelde vragen

Een rechttoe rechtaan bot met een werkende backend kan in ongeveer zes weken als app voor iOS en Android uitkomen. Functierijke bots met betalingen, offline werken of AI-streaming kosten doorgaans twee tot vier maanden. De planning hangt vooral af van of de bot al een aparte backend-API heeft en hoeveel van de functieset in versie één mee moet.
Niet als je geleidelijk migreert. De bot blijft naast de app draaien, dus geen enkele gebruiker wordt ooit buitengesloten. De bot zelf wordt het migratiekanaal: een deep link erin converteert veel beter dan betaalde advertenties, en accounts plus geschiedenis gaan mee, waardoor de app als een upgrade voelt en niet als opnieuw beginnen.
Meestal niet. Praat je bot al met een backend-API, dan roept de app dezelfde endpoints aan zonder herbouw. Alleen wanneer alle logica in de Telegram-handlers zit zonder aparte backend moet je eerst een dunne API-laag lichten, wat ongeveer twee tot drie weken kost.

Een rechttoe rechtaan migratie met kernfuncties, chat, authenticatie, pushmeldingen en publicatie in de winkels komt uit rond de € 4.000-8.000. Functierijke en op AI gebaseerde bots kosten meer. Doordat de bot de vraag al bewees, is het duurste deel van een app bouwen al betaald.

Ja. De meeste producten houden permanent een vereenvoudigde bot draaien als tweede ingang. De lancering is geen harde omschakeling: de bot duwt gebruikers in de loop van de tijd naar de app terwijl hij volledig blijft werken voor iedereen die nog niet is overgestapt.
Flutter levert vanuit één codebase uit naar iOS en Android, wat de tijd en kosten met ruwweg 40 tot 50 procent verlaagt ten opzichte van twee native trajecten, zonder prestatieverlies. Het is bijzonder sterk voor chatzware apps die soepel moeten scrollen, in realtime moeten bijwerken en rijke media moeten tonen.

::

Begin met de checklist

Voordat er één regel code wordt geschreven, leg je je bot langs de checklist voor migratiegereedheid op de dienstpagina. Die vertelt je eerlijk hoe dicht je werkelijk bij een schone migratie van zes weken zit — en waar de gaten je tijd gaan kosten.

Heb je een bot met echte gebruikers en voel je het plafond van het platform, plan dan een verkennend gesprek. We halen je bot door de audit, vertellen je welke weken makkelijk worden en welke lastig, en geven je een offerte met vaste scope — geen gok.