Ma juhatan sind täpselt selle protsessi läbi: alates AI poolt kolme minutiga 1 000 koodirea genereerimisest kuni jooksuaegsete vigadeni, enne kui jõudsin isegi sisselogimisekraani testida. Näed, milles Thunkable on geniaalne, kus see täiesti läbi kukub ja kas see on sinu konkreetse kasutusjuhtumi jaoks tokenite eelarve väärt.
Mis on Thunkable?
Thunkable on no-code mobiilirakenduste ehitaja, mis kasutab AI-d tekstipäringutest päris iOS- ja Android-rakenduste genereerimiseks.
Erinevalt traditsioonilistest no-code platvormidest, mis tuginevad lohistatavatele plokkidele, genereerib Thunkable’i AI-ehitaja tegelikku koodi, sealhulgas JavaScripti faile, komponendi struktuure ja stiilide määratlusi.
Sa näed, kuidas AI “mõtleb” läbi sinu nõuded, jagades su päringu rakenduse struktuuriks, disainistiiliks, põhifunktsioonideks ja andmemudeliteks, enne kui kood kirjutatakse. See läbipaistvus eristab seda musta kasti AI-ehitajatest, mis varjavad tehnilisi detaile.
Milliseid probleeme see lahendab?
- Kiirus võrreldes nullist alustamisega: mitme ekraaniga rakenduse loomine koos autentimise, vormide ja andmehaldusega, mis traditsioonilises arenduses võtab päevi, valmib minutitega
- Professionaalne mobiilne kasutajaliides ilma disainioskusteta: AI mõistab mobiilseid disainimustreid ja genereerib rakendusi, mis ei näi olevat mobiiliveebid, vaid tõeliselt natiivsed
- Paindlikkus tehnilistele kasutajatele: erinevalt puhtalt no-code tööriistadest on sul ligipääs aluseks olevale React Native koodile, nii et arendajad saavad AI genereeritu ulatuses kohandada
Kuidas see end positsioneerib: kui platvormid nagu Bubble keskenduvad veebirakendustele visuaalsete toimetajatega ja Flutterflow sihib arendajaid, kes tahavad Flutter-koodi, sillutab Thunkable lõhet. See on piisavalt kiire, et mittetehnilised asutajad saaksid prototüüpe luua, kuid pakub ka koodile ligipääsu arendajatele, kes soovivad kontrolli.
Kelle jaoks Thunkable sobib?
Thunkable sobib kõige paremini tehniliselt meelestatud loojatele, kes soovivad kiirelt mobiilirakenduse prototüüpe ega karda tõrkeid lahendada või koodi piiluda, kui midagi katki läheb. Sobib ka:
- Stardiasutajatele, kes valideerivad mobiilile keskenduvaid ideid: kui ehitad turuplats, broneerimissüsteemi või teenuseportaali ning vajad funktsionaalset iOS/Android prototüüpi investoritele või varajastele kasutajatele näitamiseks, viib sind Thunkable idee testitava rakenduseni tundidega.
- Python-arendajatele, kes uurivad mobiiliarendust: sa mõistad back-endi loogikat ja API-sid, kuid Swift või Kotlini õppimine tundub MVP jaoks ülepingutatud. Thunkable genereerib loetavat ja muutmiseks sobivat React Native koodi, mis võimaldab sul mobiililiideseid kiiresti prototüüpida, keskendudes back-endi API-integratsioonidele.
- Väikeettevõtjatele, kes loovad sisemisi tööriistu: saad kirjeldada oma töövoogu lihtsas keeles, luua toimiva prototüübi ja juurutada selle veebirakenduse või natiivse mobiilirakendusena ilma arendustiimi palkamata.
Ei sobi: mittetehnilistele kasutajatele, kes ootavad nullkoodilist ja veatut kogemust. AI genereerib tihti vigast koodi ning jooksuajavigade parandamiseks tuleb kas kulutada tokeneid “Fix with AI” katsetega või redigeerida JavaScripti ise.
Kui sa ei tunne end koodi lugemise või veaotsingu juures mugavalt, ajab sagedane kokkujooksmine sind kiiresti tigedaks.
Thunkable eelised ja puudused
- AI genereerib rakendusi alla 3 minutiga
- Näitab reaalajas “mõtlemisprotsessi” generatsiooni ajal
- Vaikimisi puhas, professionaalne mobiilne UI
- Võtab vastu detailseid üle 300-sõnalisi päringuid
- Täielik ligipääs React Native koodile
- Versioonide ajalugu iga AI iteratsiooni jaoks
- Avalda iOS-ile, Androidile või veebis
- Laadi alla ehitusfailid (pole platvormi lukustumist)
- Alumine navigeerimismustrite töö sujuv
- Teema kohandamine koodi kaudu
- Teenuse päringuvormid renderduvad õigesti
- Integratsioonivõimalused: Airtable, Firebase, Google Sheets
- Tokenisüsteem hoiab AI kulud kontrolli all
- AI genereerib tihti vigast koodi
- Kohandamiseks nõuab koodi redigeerimist
- Vaikimisi kasutab kohalikku salvestust, mitte pilve
- Tokeni kulud kuhjuvad veaotsingu käigus
Proovi Thunkable’i tasuta ja vaata, kuidas AI muudab sinu mobiilirakenduse kontseptsiooni toimivaks koodiks alla 5 minutiga. Ei mingeid Swifte, ei mingeid Kotlineid, vaid sina ja tekstikast.
Thunkable funktsioonid
- AI genereerib React Native koodi päringutest
- Mitmeekraanilised rakendused alumise navigeerimisega
- Kasutaja autentimine ja rollihaldus
- Vormiehitajad rippmenüüde ja valideerimisega
- Koodi igale iteratsioonile versioonide haldus
- Avaldamine iOS-ile, Androidile või veebis
- Integratsioonid: Airtable, Firebase, Google Sheets, Xano
- Laadi alla APK/AAB failid juurutamiseks
Minu praktiline kogemus Thunkable’iga
See on minu täielik ülevaade Teenuse Päringute Portali ehitamisest Thunkable’is. Soovisin täisfunktsionaalset süsteemi kasutajate sisselogimise, juhtpaneeli ja töötava andmebaasiga. Siin on täpselt, kuidas see läks — iga klõps ja iga pettumus on kirjas.
1. Alustamine: Registreerumine ja esimesed muljed
Sattusin Thunkable’i avalehele ja esimene asi, mida nägin, oli hiiglaslik minimalistlik kutse: “Turn Your Idea into An App.”

Ekraani keskel oli suur valge tekstikast. Selle all oli neli soovitatud kategooriat, mis aitaksid sul alustada:
- Ürituste planeerimine
- Varude haldus
- Reisimine
- Meditatsioon
Märkasin, et kui klõpsad ühe neist, täidetakse tekstikast automaatselt näidiskirjeldusega.

Malli ma siiski ei tahtnud; tahtsin näha, kas AI suudab toime tulla keeruka, mitmetasandilise päringuga.
Kuid enne, kui ma sain ühtegi sõna sisestada, tahtsin konto luua. Klõpsasin paremas ülanurgas nuppu “Registreeru”.
Avariis valge aken hüppas üles, pakkudes kolme liitumisviisi:
- Jätka Google’i kontoga
- Jätka Apple’i kontoga
- Registreeru e-posti teel

Sisestasin oma e-posti aadressi ja vajutasin sinist nuppu “Registreeru e-posti teel”. Thunkable ei kasuta sellel algfaasil paroole.
Selle asemel kasutatakse “võlulingi” süsteemi. Pidin lahkuma saidilt, avama e-posti uues kaardil ja leidma The Thunkable Team saadetud kirja. Pidin klõpsama “Kinnita”. Lõpuks suunati mind tagasi Thunkable’i juhtpaneelile.
Esimene asi, mida ma peale sisselogimist märkasin, oli see, et liides oli uskumatult tühi. Puudus nii “Tere tulemast! Teeme tiiru” hüpik, puudusid õpetusvideod ja tüütav chatbot, mis lehvitas mulle.

Mida ma sellest arvasin:
Sisseregistreerimine oli kiire, kuid ma ei ole võlulingi süsteemi fänn, sest see sunnib sind vahekaarte vahetama. Kuid liides ise on ilus. See ei ole täis tuhandet nuppu ega külgriba; seal on vaid üks suur tekstikast, mis sind ootab, ja see muudab kogu protsessi väga ligipääsetavaks kellegile, kes ei tea, kust alustada.
2. Minu esimene päring ja tähemärgi piirangud
Läksin tagasi põhitekstikasti ekraanile, et sisestada oma projekti andmed. Tahtsin luua “Teenuse Päringute Portaal” koduomanikele.
See polnud lihtne päring; tahtsin täielikku töövoogu. Võtsin paar minutit, et sõnastada väga täpne päring, et näha, kas AI täidab mu juhised täpselt.

Lisasin ka üksikasjaliku andmestruktuuri kahe tabeli jaoks: “Services Table” ja “Users Table”. Määratlesin isegi rollid “Customer” ja “Admin”.
Mida ma ei oodanud, oli see, et tekstikast oli väga helde. Kleepisin kogu oma üksikasjaliku päringu, mis sisaldas ligi 300 sõna, ja see mind ära ei katkestanud.
Ma ei näinud kuskil tähemärkide lugemist ega “maksimaalse pikkuse” hoiatust. Tekst võeti lihtsalt vastu ja oodati mu tegevust. Kui olin päringuga rahul, klõpsasin kasti all servas punast nuppu “Generate App”.
Minu arvamus päringuprotsessist:
See osa oli sujuv. Tundus väga loomulik, peaaegu nagu kirjutaksin tellimust vabakutselisele. Mulle meeldis, et sain olla äärmiselt täpne andmesammaste ja rippmenüüvalikute osas, ilma et tööriist segadusse satuks.
Võrreldes teiste ehitajatega, mis pakuvad vaid üheliinilist tekstikasti, sütitab Thunkable’i suur tekstiala sind olema detailne. See paneb sind tundma, et sul on disaini üle kontroll alates esimesest sekundist.
3. AI ehitamise jälgimine: “Mõtlemise” etapp
Niipea kui vajutasin genereerimise nuppu, muutus ekraan tumedaks ja ilmus olekuteade: “Analyzing your request.”
See oli kogu kogemuse kõige huvitavam osa. Generilisele laadimisindikaatorile eelistati elavat logi AI “mõtlemisprotsessist.”

Vaatasin, kuidas AI jagas minu päringu neljaks eraldiseisvaks kategooriaks:
- Rakenduse struktuur: see valis “Bottom Navigation” paigutuse, millel on kolm põhiekraani: Home, New Request ja Profile.
- Disainistiil: see logis mu soovi “Primary blue color” ja “Professional” esteetika järele. Samuti märkis eesmärgiks “Clean, modern interface”.
- Põhifunktsioonid: see loetles komponendid, mida plaanis ehitada, sh sisselogimis-/registreerimissüsteem, teenuse päringuvorm ja juhtpaneel olekufiltriga.
- Andmestruktuur: see kinnitas, et loob kaks tabelit: users ja service_requests. See loetles isegi veerud, mida loodi, nt id, service_type ja status.

Pärast analüüsi muutus ekraan täielikuks koodiredaktoriks. Vaatasin, kuidas AI kirjutas sõna-sõnalt React Native koodi.

Ma nägin vasakpoolses külgribas failide loomist. Faile nagu App.js, theme.js ja HomeScreen.js lisandus ükshaaval. Nägin, kuidas loogika kirjutati: funktsioonid handleSubmit, fetchRequests ja toggleStatus.
Kogu protsess, alates klikist “Generate” kuni rakenduse valmimiseni, võttis peaaegu täpselt kolm minutit. Alumises nurgas ilmus väike teadetus: “Your app has been generated!” ja sinine nupp “Preview”.
Mida ma sellest arvasin:
AI “mõtlemisprotsessi” nägemine oli hämmastav. See andis mulle võimaluse kontrollida, kas see tegelikult mõistis mu päringut, enne kui koodigi kirjutama hakkas.
Pole kõige tavalisem, et no-code tööriistas tuhat rida JavaScripti silmitseda, ent see on tõeliselt lahe, kui tahad mõista, kuidas su rakendus sisemiselt töötab. See võtab AI “mustast kastist” müstilise varjundi ära.
4. Esimene pilk: genereeritud rakenduse ülevaatus
Kui ehitus oli valmis, vajutasin nuppu “Preview”. Ekraani paremas servas ilmus mobiiltelefoni emulator.

Esimene mulje oli, et rakendus näeb väga puhas ja “natiivne” välja. See ei tundunud mobiiliveebina, vaid pärisrakendusena, mille leiaks App Store’ist.
- Juhtpaneel: esimene ekraan oli “Service Requests” nimekiri. Sellel oli kena päis ja ülaservas nelja vahekaardiga lülitusriba: All, Pending, In Progress ja Completed.
- Värviskeem: see järgnes mu juhistele täiuslikult. Nupud olid professionaalse sügava sinise tooniga ja taust oli pehme hall, mis tõstis valgete kaartide esile.
- Navigeerimine: ekraani allosas oli selge menüü kolme ikooniga: “Requests”, “New Request” ja “Profile”.
- Välimus: see kaldus kindlasti “professional” stiilile. Fondid olid teravad, elementide vahe oli ühtlane ja kasutati standardseid mobiilse UI mustreid, mis tundusid väga tuttavad.
Siiski oli juhtpaneel tühi. Seal ei genereeritud ühtki “dummy data” selleks, et näha, milline päring nimekirjas välja näeb, mistõttu oli lõplikku välimust veidi raske hinnata ilma andmeid käsitsi lisamata.
Minu arvamus esimesest pilgust:
Disain oli täpselt selline, nagu ma palusin, professionaalne ja sinine. See ei püüdnud olla liiga “lööv”, mis mulle teenuseportaali puhul meeldis. Mul oli muljet, kuidas see vahekaarte ja navigeerimist käitles; see tundus väga sujuv.
Minu ainus väike kaebus on, et sooviksin, et see oleks genereerinud paar võlts teenusepäringut, et ekraan alguses nii tühi ei oleks. See oleks “wow” efekti palju tugevamaks teinud.
5. Kui vead hakkasid ilmuma: veaotsingu tsükkel
Laimuuetapi lõpp saabus sel hetkel, kui proovisin rakendusega tegelikult suhelda. Klõpsasin vahekaardil “New Request”, et näha oma vormi, ja vormi asemel ilmus mobiiliemulatori kohale erelilla kast. Seal seisis:
Runtime Error: Your app encountered an error while running. Cannot read properties of null (reading ‘id’) at Line 433, Column 50. Error location: the ‘HomeScreen’ screen.

Ma polnud koodi veel puudutanud, ja rakendus juba jookses kokku. Tundub, et Thunkable arvestab sellega.
Kasti sees oli suur nupp, millel oli kiri “Fix with AI”. Klõpsasin seda ja AI läks uuesti “Thinking” režiimi. See veetis ligikaudu 45 sekundit koodi “uuesti analüüsimisel” ja uuendas seejärel eelvaadet.

Esialgne krahh kadus ja lõpuks nägin “New Service Request” vormi. See oli täpselt selline, nagu ma kirjeldasin:
- Rippmenüü “Service Type” valikutega Plumbing, Electrical jne.
- Üsna suur tekstiala kirjelduse jaoks.
- Kuupäeva valija eelistatud kuupäeva jaoks.
- Rippmenüü “Urgency Level”.
Siis proovisin klõpsata ikooni “Profile”, et näha oma kasutajainfot, ja ilmus teine viga:
Runtime Error: Cannot read properties of null (reading ‘name’) at Line 949, Column 42.

Mida ma sellest arvasin:
See osa oli frustreeriv. AI on suurepärane disainer, aga kooderi poolest vigane. Tundus, et see pidi kõvasti vaeva nägema autentimisloogikaga. See püüdis kasutaja nime või ID-d leida enne, kui olin sisse logitud või kontot loonud, mis põhjustas kogu rakenduse kokkujooksmise.
Hoolimata, et nupp “Fix with AI” on võimas, oli veidi pettumus seda kolmel korral kasutada ainult selleks, et vaadata kolme erinevat ekraani. See pani mind tundma, et rakendus ei ole veel päris “avaekssaadu” valmis.
6. Krediidid ja tokeni piirangud: ehitamise maksumus
Kasutades nuppu “Fix with AI”, hakkasin mõtlema, kui palju see mulle maksab. Klõpsasin konto seadistustel ja leidsin jaotise “Tokens”.
Vabal plaanil nägin, et mulle on antud 1,2 k tokenit. Iga kord, kui AI genereerib uue rakenduse või proovib koodi parandada, sööb see seda limiiti.

Märkasin, et pärast esmast ehitust ja kahte “Fix with AI” katset oli mu tokenite arv langenud umbes 250 võrra.

See tähendab, et kui sul on keeruline rakendus, mis nõuab palju veaotsingut, võid päevasel ajal oma tasuta tokenid kergesti läbi põletada.
Minu arvamus krediidi piirangutest:
See on õiglane süsteem, kuid lisab ehitusprotsessile veidi stressi. Iga kord, kui vajutasin “Fix with AI”, tundsin, et kulutan raha. Parem oleks, kui AI parandused ei läheks limiidi arvele, eriti kui vead on põhjustatud AI enda koodist.
7. Disaini kohandamine: no-code vs. kõrgtasemeline kood
Tahtsin näha, kas saan disaini muuta ilma AI-d kasutamata. Klõpsasin vahekaarti “Edit”, oodates lohista-ja-allaheida toimetajat nagu tavalises Thunkable’i platvormis. Selle asemel anti mulle lihtsalt kood.
- Värvide muutmine: pidin avama faili nimega theme.js ja muutma selliseid heksakoode nagu #0000FF millekski muuks.
- Nuppude paigutuse muutmine: pidin CSS-i sarnases koodis kohandama flexbox-seadeid.
- Komponentide lisamine: kui tahtsin uut nuppu lisada, pidin koodi käsitsi kirjutama.

Neile AI-generaatidele pole veel “Disaini paneeli” liugurite või värvivalijatega. Või kasutad AI-d muudatuste tegemiseks või kirjutad koodi.
Mida ma sellest arvasin:
See oli suur üllatus. Ootasin, et AI genereerib plokkide-põhise rakenduse, mida saaksin visuaalselt redigeerida.
RAW-koodi andes ütleb Thunkable põhimõtteliselt, et see tööriist on mõeldud arendajatele, kes soovivad eelist, mitte täielikele algajatele, kes ei taha koodi kunagi näha. See teeb tööriista võimsaks, aga muudab selle kasutamise mittetehnilistele inimestele palju raskemaks.
8. Andmete ja back-end’i seadistamine: Kuhu mu andmed kadusid?
Otsustasin vaadata, kuidas andmetega käideldi. Kui vaatasin koodi, leidsin selle rea alguses:
const storageStrategy = ‘all-local’;
Ja kui uurisin sügavamalt, nägin, et rakendus kasutas platvormihaakide (‘platform-hooks’) meetodeid useQuery ja useMutation:
const { useQuery, useMutation } = require(‘platform-hooks’);
See oli alguses segane. Teenuse päringud salvestati nende haakide abil, kuid ma ei suutnud aru saada, kuhu andmed tegelikult lähevad. Kas need jäävad telefonis? Kas need saadetakse pilveandmebaasi?
Siin on, mida avastasin:
‘all-local’ strateegia tähendab, et andmed salvestatakse seadmesse lokaalselt, kuid mitte püsivalt tõelisesse andmebaasi. Tegelikkuses on tegu keeruka localStorage-lahendusega, mis näib kasutavat andmebaasi (päringute ja mutatsioonidega), kuid haldab andmeid vaid brauseris või telefoni ajutises salvestuses.
Hea: kood on juba üles ehitatud andmebaasiga töötamiseks. useQuery ja useMutation muster on täpselt see, mida kasutataks reaalse back-end’iga.
Halb: see tegelikult ei ole ühendatud Airtable’i, Firebase’i, Google Sheetsi ega ühegi pilveandmebaasiga. Kui koduomanik esitab päringu, ei näe torumees ega administraator seda, sest see salvestub vaid koduomaniku seadmesse. Andmed kaovad, kui rakenduse vahemälu tühjendada või seadmeid vahetada.
Mis juhtus, kui küsisin „Kuidas ma andmebaasi ühendan?”
Ma ei olnud kindel, kuidas reaalse andmebaasiga ühenduda, nii et kirjutasin selle küsimuse samasse vestluskasti, kuhu olin sisestanud oma esialgse päringu. Lootsin, et AI selgitab protsessi või pakub integratsiooni üles seadmist.

Asenduseks juhtus midagi kummalist. AI “Thinking” logisid (mida nägin selle töötlemise ajal) näitasid midagi huvitavat:
“The user is asking ‘How do I connect a database?’ This is not a request to modify the code, but rather a question… However, based on my instructions, I need to return complete, updated code only.”
AI oli programmeeritud väljastama ainult koodi, mitte selgitusi. Selle asemel, et vastata mu küsimusele, tõlgendas see mu päringut kui soovi koodi muuta. See veetis 13,6 sekundit “thinking” režiimis ja seejärel genereeris koodi uuesti.
Aga siin on vastupandamatu: kood, mida see mulle tagastas, oli peaaegu identne sellega, mis mul juba oli. See lihtsalt reorganiseeris mõningaid sisemisi struktuure (luues ServiceRequestContext’i, et jagada andmeid ekraanide vahel), kuid säilitas sama ‘all-local’ salvestusstrateegia.

See ei lülitanud mind pilveandmebaasi peale. See ei pakkunud Airtable’iga ühendamist. See lihtsalt… andis mulle veidi refaktoreeritud versiooni samast lokaalse salvestuse lahendusest.
AI mõtlemislogi tunnistas seda piirangut isegi:
“The appropriate response would be to explain that: 1. The current strategy is ‘local’ (no database) 2. To use a database, they need to migrate to ‘all-local’ strategy (which uses platform-hooks with useQuery/useMutation) 3. The ‘all-supabase’ strategy (cloud database with auth) is coming in a future release. However, I’m instructed to ONLY return code, nothing else.”
Tõlge: AI teadis, mida ma küsisin, kuid ei saanud midagi selgitada. See sai anda mulle ainult koodi.
Ja kuna pilveandmebaasi integratsioon ei olnud veel täielikult kättesaadav (“all-supabase” strateegia mainiti kui “tulevases versioonis tulevat”), piirdus see lihtsalt lokaalse salvestusviisiga.
Minu arvamus back-end’ist:
AI ehitaja eelistab vaikimisi lokaalset lähenemist, mis demonstreerimiseks on okei, kuid tootmises mitme kasutajaga rakenduste jaoks mitte. Mind frustreerib see, et:
- AI ei küsinud mul alguses, kuhu ma andmeid salvestada soovin (Airtable? Firebase? Google Sheets?).
- AI ei saanud oma valikuid selgitada, kui ma otse küsisin. See on programmeeritud väljastama ainult koodi, mitte pidama vestlust arhitektuuriliste otsuste üle.
- Kood näeb välja andmebaasiks valmis (kasutades useQuery ja useMutation), kuid tegelikkuses on tegu lihtsalt elegantse mähisega localStorage’i ümber.
Thunkable’i dokumentatsiooni kohaselt võiksin ma teoreetiliselt vahetada storageStrategy väärtuse ‘all-local’’lt näiteks ‘all-supabase’’le (mis kasutaks tõelist pilveandmebaasi koos autentimisega), kuid AI mõtlemislogid vihjavad, et see funktsioon on “tulevases versioonis tulemas”, ehk AI ehitajal pole pilveandmebaaside strateegiatega veel täielikku ligipääsu.
Tõeline küsimus: kas see on AI piirang või pidanuksin ma lihtsalt olema päringus täpsem? Kui ma oleksin algusest peale öelnud “Ehita teenuseportaal, mis salvestab päringud Airtable’i”, kas AI oleks sellega hakkama saanud? Kahtlustan, et vastus on võimalik, kuid AI oleks pidanud küsima, millist andmebaasi ma soovin, selle asemel et vaikimisi selgitusteta lokaalse salvestuse juurde jääda.
9. Saadaval integratsioonid: ühendame punktid
Kuigi AI neid minu jaoks ei loonud, uurisin platvormi, et näha, millised integratsioonid on saadaval, kui tahaksin need käsitsi lisada.
Leidsin, et rakenduse saab võimalusel ühendada:
- Airtable: võimsama pilvepõhise andmebaasi jaoks, millel on tabelarvutuse stiilis liides. Ideaalne teenusepäringute haldamiseks viisil, mida nii arendajad kui mittetehnilised administraatorid saavad kasutada.
- Firebase: tõeliseks kasutaja autentimiseks ja andmete sünkroonimiseks seadmete vahel. See lahendaks probleemi “andmed elavad ainult ühes telefonis” kohe.
- Google Sheets: lihtsaks andmete jälgimiseks, mida mittetehnilised kasutajad saavad avada. Kujuta ette haldurit, kes avab Google Sheetsi, et näha kõiki saabunud teenusepäringuid—koodi kirjutamata.
- Xano: skaleeritava back-end’i jaoks ilma servereid haldamata. Ideaalne rakendustele, mis peavad kasvama, ilma et peaks infrastruktuuri pärast muretsema.
- Backendless: visuaalsete andmebaaside ja kasutajahaldusfunktsioonide jaoks. Veel üks no-code back-end’i võimalus.
- Cloudinary: piltide käsitlemiseks. Mõtle piltidele katki läinud torust, mille koduomanikud saaksid teenusepäringuga üles laadida.
- Webflow: sünkroonimiseks veebisaidi CMS-iga. Kui sul on Webflow’s loodud kinnisvarahaldusveeb, võiksid teoreetiliselt sünkroonida teenusepäringud veebisaidi ja rakenduse vahel.
- RevenueCat: rakendusesiseste ostude ja tellimuste haldamiseks, kui tahad rakendust monetiseerida.
Tööriistad on seal olemas. Küsimus on: miks AI neid ei kasutanud?
Siin muutub olukord huvitavaks. Läksin tagasi ja uurisin AI mõtlemisprotsessi, kui küsisin “Kuidas ma andmebaasi ühendan?”

AI teadis neist integratsioonidest. See mainis täpselt järgmist:
“To use a database, they need to migrate to ‘all-local’ strategy (which uses platform-hooks with useQuery/useMutation). The ‘all-supabase’ strategy (cloud database with auth) is coming in a future release. However, I’m instructed to ONLY return code, nothing else.”
See ütleb mulle mitut asja:
- Integratsioonid on olemas, kuid AI ehitajal on piiratud juurdepääs neile. Thunkable toetab ilmselgelt Airtable’i, Firebase’i, Google Sheetsi ja rohkem, kuid AI ehitaja paistab olevat piiratud mõne eeldefineeritud “salvestusstrateegiaga”, nagu ‘all-local’ (seadmesalvestus) ja ‘all-supabase’ (pilveandmebaas, varsti tulemas).
- AI-l ei ole seadistamiseks vestlusliidest. Ma ei saanud lihtsalt kirjutada “Connect this to my Airtable” ja lasta AI-l raske töö ära teha. Selle asemel tuleb integratsioon käsitsi Thunkable’i dokumentatsiooni abil konfigureerida.
- AI on optimeeritud kiiruse, mitte kohandatavuse jaoks. See valis vaikimisi kõige kiirem ja lihtsam võimaluse (lokaalne salvestus), selle asemel et küsida lisaküsimusi nagu “Kuhu sa andmeid salvestada soovid?” või “Kas rakendusel on mitu kasutajat?”
Mida ma sellest arvasin:
Potentsiaal on kindlasti olemas ning see on tugevam, kui ma alguses uskusin. Mu frustratsioon ei tulene Thunkable’i võimetest. Platvormil on need integratsioonid selgelt olemas. Mu frustratsioon seisneb selles, et AI ehitaja ei pakkunud neid võimalusi vestluse etapis proaktiivselt.
Soovin, et AI oleks küsinud midagi sellist:
- Lokaalne salvestus (kiire, võrguühenduseta sõbralik, kuid andmed jäävad ühes seadmes)
- Airtable (pilveandmebaas tabelarvutuse stiilis liidesega)
- Firebase (reaalajaline andmebaas kasutaja autentimisega)
- Google Sheets (lihtne jagatav andmete jälgimine)
See üks küsimus oleks päästnud mind looma rakendust, mis näeb välja mitme kasutajaga, kuid toimib nagu ühe kasutajaga prototüüp.
10. Versioonihaldus: ülim turvavõrk
Mind avaldas tõelist muljet “Version History” tööriist. Klõpsates ülemises tööriistaribal väikest kellaikooni, avanes külgriba, mis näitas iga ühtegi versiooni rakendusest, mille AI oli loonud.

Nägin ajajoont:
- Service Request Portal with User Authentication (The one that crashed)
- “Fix null reference error” (The first fix)
- Connect database to application
Sain klõpsata ükskõik millisel neist versioonidest, et vaadata koodi või isegi rakenduse sellele konkreetsele hetkele taastada (“Restore”).
See oli uskumatult kasulik, kui mõni “Fix with AI” katse appi halvemaks muutis või uue krahhi tekitas.
Minu arvamus versioonihaldusest:
See on parim versioonihaldus, mida olen näinud mis tahes no-code või AI-tööriistas. See annab tõelise turvatunde. Sa ei karda katsetada ega lasta AI-l riskantset parandust proovida, sest tead, et saad ühe klõpsuga ajas tagasi hüpata. See muudab AI arenduse segadusseisundi palju professionaalsemaks ja kontrollitumaks.
11. Avaldamine ja juurutamine: rakenduse live’i minemine
Kui tundsin, et rakendus on piisavalt valmis seisus, uurisin “Publish” valikuid. Paremas ülanurgas oli suur nupp “Publish”.
Klõpsamine avas menüü kolme peamise valikuga:
- Publish iOS: alustab rakenduse saatmist Apple App Store’i prosessi. Nõuab Apple Developer kontot.
- Publish Android: loob APK või AAB faili Google Play poe jaoks.
- Publish Web App: see oli kõige huvitavam. See annab URL-i, nii et inimesed saavad rakendust mobiilibrauseris kasutada ilma midagi alla laadimata.

Oli ka nupp “Download”, mis võimaldas taotleda Androidi või iOS-i ehitusfailide kohalikku koopiat. See on suur eelis, sest see tähendab, et sa ei ole Thunkable’i platvormiga igaveseks lukus. Sa tegelikult omandad väljundi.
Minu arvamus avaldamisest:
Avaldamise voog on väga otsekohene. Nad ei peida “veebirakenduse” valikut hiiglasliku maksumüüri taha, mida ma hindasin. See, et saad Androidi ja iOS-i raw ehitusfaile, muudab selle tunduma pigem professionaalse tööriistana kui lihtsalt hobiülessaiamise mänguasjana. See on ehitusprotsessi väga sujuv lõpetus.
Kogemuse lõplik kokkuvõte
Peale mõne tunni selle tööriistaga kulutamist oli mul töötav prototüüp Teenuse Päringute Portaalist. Sellel oli sisselogimiskuva, funktsionaalne päringuvorm ja juhtpaneel, mis filtreeris töid staatuse järgi.
Minu lõplik hinnang:
Thunkable’i AI-ehitaja on võimas lähtepunkt kõigile, kes soovivad mobiilirakendust kiirelt luua. See on suurepärane idee visualiseerimiseks ja kasutajaliidese struktuuri minutitega, mitte päevadega, üles ehitamiseks.
Kuid see ei ole “võlurits”. Sa kohtad vigu, pead kulutama tokeneid nende parandamiseks ja võib-olla pead vaadata ka koodi, kui tahad reaalset andmebaasi ühendada.
Võrreldes teiste tööriistadega tundub Thunkable pigem professionaalse arenduskeskkonnana. See näitab sulle koodi ja annab tööriistad selle parandamiseks. Kui oled “tehniliselt meelestatud” looja, kes soovib oma järgmist projekti massiivset eelist, on see väga muljetavaldav tehnoloogialahendus.
Kui otsid nullpingutusega täiuslikku rakendust ühe klõpsuga, võivad jooksuajavead tunduda veidi üle jõu käivad. Üldiselt on tegemist no-code maailma tohutu edusammuga.
Thunkable hinnakujundus ja paketid
Thunkable pakub nelja hinnataset, mis on üles ehitatud AI tokeni piirangutele, projektide privaatsusele ja avaldamisvõimalustele.
Kõik paketid sisaldavad AI koodigeneraatorit. Erinevus seisneb selles, kui palju saad ehitada ja kuhu saad juurutada.
| Plaan | Hind | AI tokenid | Projektid | Avaldamine poodides | Sobib kõige paremini |
|---|---|---|---|---|---|
| Free | $0 | 2 000 | 3 avalikku | Ei | Platvormi testimiseks |
| Accelerator | $19/kuus | 20 000 | 5 avalikku + 1 privaatne | Ei | MVP prototüüpimiseks |
| Builder | $59/kuus | 50 000 | Piiramatu avalikku + 10 privaatset | 1 aktiivne rakendus | Esimese rakenduse lansseerimiseks |
| Advanced | $189/kuus | 100 000 | Piiramatu kõike | Piiramatu rakendusi | Agendid & tootesarjad |
Peidetud kulud, mida teada
Sinu jaoks on vaja Apple Developer (99 $/aasta) ja Google Play (25 $ ühekordne) kontosid rakenduste avaldamiseks. Thunkable ei maini seda ette, kuid ilma nendeta ei saa rakendusi poodidesse saata.
Tasulistel paketitel aeguvad AI tokenid igakuiselt (need taastuvad arveldustsükli jooksul). Kui oled Accelerator paketil ja kasutad 3 000 oma 20 000 tokenist, saad järgmisel kuul uuesti 20 000. Mittekasutatud tokeneid ei kanta üle.
Oluline: kui sinu tellimus aegub, muutuvad avaldatud rakendused lõppkasutajatele kättesaamatuks. See ei ole nagu WordPress, kus sinu veebisait jääb tühistamise järelgi üles; rakendused lähevad pimedaks, kuni uuled tellimuse.
Minu soovitus
Alusta Accelerator paketiga (19 $/kuus), kui oled ehitamise suhtes tõsine. Tasuta plaani 2 000 tokenit saavad veaotsingu käigus liiga kiiresti otsa ja sul on vaja vähemalt ühte privaatset projekti kõigi äriga seotud asjade jaoks.
Saad Thunkable’is rakenduse üles ehitada ja seejärel genereeritud React Native koodi abil manuaalselt oma Django back-end’iga ühendada. Muuda lihtsalt API endpoint’id koodifailides.
Alternatiiv Thunkable’ile
Thunkable’i AI-põhine koodigeneratsioon asetab selle kiire prototüüpimise tööriistaks, kuid kui sinu eesmärk on täppis-piksliline mobiil UI täieliku koodikontrolliga, pakub FlutterFlow veenvat alternatiivi.
| Funktsioon | Thunkable | FlutterFlow |
|---|---|---|
| Ehitamise lähenemine | AI genereerib koodi päringutest | Visuaalne lohista-ja-allaheida Flutteri vidinatega |
| Sobib kõige paremini | Kiired AI-jõul prototüübid | Täppis-piksliline UI arendajate kontrolliga |
| Koodi ligipääs | Vaata React Native koodi, piiratud redigeerimine | Täielik Flutter lähtekoodi eksport |
| Kohandamine | Muutide koodi käsitsi või esita AI-le uuesti päring | Üle 170 eelvalmistatud komponendi + kohandatud kood |
| Back-end | Vaikimisi lokaalne salvestus, piiratud pilv | Native Firebase integratsioon, kohandatud API-d |
| Õppimiskõver | Lihtne päringute esitamine, raske veaotsing | Järkulisem (nõuab Flutteri kontseptsioonide mõistmist) |
| Algushind | $19/kuus (Accelerator) | $15.60/kuus (Basic) |
| Avaldamine poodides | $59/kuus (Builder) | $15.60/kuus (Basic) |
Vali Thunkable, kui oled: mittetehniline asutaja, kes soovib valideerida mobiilirakenduse ideed. Sa tunned end harvade vigade korral mugavalt ja soovid kiireimat teed kontseptsioonist toimiva prototüübini.
Vali FlutterFlow, kui oled: arendaja, kes avastab mobiiliarendust ja soovib loetavat, eksportitavat koodi. Sa mõistad programmeerimise kontseptsioone ja soovid detailselt kontrollida UI-d, animatsioone ja back-end loogikat.
Lõplik hinnang Thunkable’ile
Thunkable’i AI-ehitaja täidab täpselt seda, mida lubab: töövõimelised mobiilirakendused minutitega tavalistest ingliskeelsetest päringutest.
AI nõuete lahtimurdmise ja React Native koodi genereerimise jälgimine on tõeliselt muljetavaldav ning versioonihaldus tähendab, et võid katsetada ilma hirmuta.
Kuid tegelikkuses veedad rohkem aega AI genereeritud vigade parandamisele kui funktsioonide ehitamisele. Jooksuajavead ilmnevad pidevalt, põletades tokeni eelarvet “Fix with AI” katsetesse, mis sageli toovad kaasa uusi probleeme.
Kuid kui ootad lihvitud, tootmises valmis rakendusi ilma koodi puudutamata? Oled pettunud.

