Rakensin App Store -sovelluksen yksin, mitä opin?

Kaiken alku, matkalaskuahdistus

Olen varmaan kuten moni muu kiroillut matkalaskujen tekemistä, kilometrikorvauksia ja päivärahoja. Pelkkä ajatus ahdistaa.
Ja usein kun joku asia ärsyttää tai ahdistaa, siinä ei ole yksin.

Kun sitten syksyllä taas mietin ja ahdistelin omia kilometrikorvauksia ja päivärahoja keikoilta, mietin että tähän on pakko olla joku parempi ratkaisu. Joka lähtee ihmisestä eikä käyttöliittymästä.

Olen aina ihaillut Applen tyyliä tehdä asioita. Käyttöliittymiä ja tuotteita, jotka lähtevät siitä miten ihminen toimii, ei miten ihmisen halutaan toimivan. Ja jätetään pliis Android vs Apple -keskustelu pois tällä kertaa 🙂

Sen tekeminen on paljon haastavampaa kuin mitä kukaan joka ei ole tehnyt käyttöliittymäsuunnittelua ja tuotteita voi ymmärtää.
Harva tajuaa kuinka paljon ajattelua ja suunnittelua vaatii tehdä jotain joka tuntuu helpolta.
Mielestäni Jony Ive ja Steve Jobs onnistuivat siinä hyvin Applella.

Mutta asiaan.

Aloin miettimään mikä olisi tapa, jossa matkalaskun tekemisestä saisi niin helppoa ettei se aiheuttaisi yhtä isoa ärsytystä kuin olemassa olevat tuotteet. Päädyin puheeseen. Jos pystyisi puhumaan matkan vapaasti, samalla tavalla kuin kertoisi kaverille, sovellus tulkitsisi ja laskisi verottajan ohjeistuksen mukaan oikean korvauksen. Ja tekisi siitä PDF-tiedoston jonka voisi lähettää tilitoimistolle.

Voisiko sen oikeasti tehdä noin helpoksi? Ja mitä se vaatisi?

Tekoälykoodaaminen

Kun tekoäly ilmestyi pari vuotta sitten, mun ensireaktio oli tuskallinen. Näin edessäni tulevaisuuden, jossa ihmiset lopettivat kirjoittamisen, ulkoistivat oman ajattelun ja luovan työn ja, kaikesta kauheinta, toi mukanaan epäilyksen tekoälystä kaikkiin kirjoitettuun tekstiin.

Mieti heitä, jotka oikeasti taistelevat tekstin edessä tuntikausia jotta saavat jotain kirjoitettua, ja sitten muut heti olettavat että tekoäly on generoinut sen. Kamalaa. Toki tätä pelkoa ei näytä hirveän moni jakavan, mikä on hieman surullista.

Koska tekoälyä nyt ei ilmeisesti voi pysäyttää, ajattelin että voi sillä varmaan tehdä jotain järkevää. Ja koska olin kuullut jostain ihme vibe-koodauksesta, päätin tarkistaa mistä on kyse.

Vibe-koodaus oli ilmiö jossa kuka tahansa pystyi promptaamalla luomaan koodia. Siihen löytyi erilaisia järjestelmiä joten aloin tutkimaan ja päädyin sattumalta Cursor-nimiseen tuotteeseen.

Mitä tiesin koodauksesta etukäteen?

Hyvin vähän. Vaikka olen perustanut erilaisia teknologiastartupeja aikoinaan, koodaus oli aina koodarien hommaa. Näin sen silloin myös hyvänä asiana olla ymmärtämättä syvemmin, johtuen mahdollisuuksien eikä rajoitusten näkemisestä.

Monesti jos ymmärtää jotain liian hyvin, on todennäköistä että näkee aina kaikki haasteet ja monimutkaisuudet mahdollisuuksien sijaan. Loistavien tuotteiden rakentaminen vaatii tiettyä naiiviutta. Mahdollisuuksien näkemistä.

Tästä edellä mainittu Steve Jobs oli hyvä esimerkki. Hän halusi tehdä tietyt asiat juuri omalla tavalla ja oman näköisenä. Ja kun tuotepäälliköt ja kehittäjät valitteli, hän jyräsi, ei aina ihan tyylikkäästi. Mutta siitä syntyi sitten suhteellisen hyviä tuotteita, jotka ”eivät olleet mahdollisia”.

Joten tein tietoisen päätöksen ymmärtää ainoastaan perusasiat, mutta hyvin rajatusti. Pelkäsin että alkaisin itsekin näkemään esteitä mahdollisuuksien sijaan. Haluan nyt myös korostaa että tämä ei ole hyökkäys ohjelmistokehittäjiin, vaan yleisinhimillinen piirre, jossa syvä ymmärrys voi estää innovaatioita ja tekemistä.

Sen näkee startupeissa ja aloittelevilla yrittäjillä verrattuna kokeneisiin. Kokeneet näkevät vaan sen kamalan työtaakan ja kaikki mutkat matkan varrella, kun taas aloittelevat eivät edes ole tietoisia siitä kuinka hankalaa on tehdä hyvä tuote ja varsinkin tuoda se markkinoille.

Maailman muuttaminen vaatii naiiviutta.

Olisiko Cursorista potentiaalinen alusta mun projektille?

Cursorin IDE

Kun latasin Cursorin, edessäni oli niin sanottu IDE eli integroitu kehitysympäristö. Ohjelmisto joka tarjoaa koodin kirjoittamiseen, kääntämiseen, testaamiseen ja virheenjäljitykseen tarvittavat työkalut yhdessä paketissa.

Ja kun sen näkee ekan kerran, sydän lyö pari ekstralyöntiä. Musta ruutu joka tuijottaa sinua ja odottaa että kirjoitat sille jotain järkevää.

Tässä kohtaa mietin että mihin olen lähdössä. Viimeksi kun olin nähnyt vastaavaan näköisen ruudun oli 2018 mun koodarin laptopilla. Ei muuta kuin hommiin.

Ostin aluksi Cursorin 20 euron kuukausipaketin. Cursorissa on se hyvä puoli, että voit valita mitä tekoälyalustaa käytät koodatessa. Voit käyttää tiettyihin juttuihin Clauden Sonnet tai Opus -mallia, joihinkin Cursorin omaa tai vaikka Codexia. Cursorissa voi myös valita Auto, joka valitsee tehtävän mukaan automaattisesti parhaimman, ainakin heidän mukaansa.

Lopputulos pienen tutkimuksen jälkeen oli että Cursor on nyt se alusta jolla rakennan tämän. Mutta mistä lähteä tekemään?

Projektin käynnistys, kun yksinkertaisesta tulikin monimutkainen

Tiesin suurin piirtein pään sisällä mitä halusin, mutta ensimmäinen kysymys oli tietysti millä kielellä pitäisi koodata ja miksi.

Halusin luoda appin joka löytyisi sekä App Storesta että Play Storesta. Tiesin myös etten halua luoda kahta erillistä appia, koska se tarkoittaisi kahta koodipohjaa jonka kanssa pitäisi säätää. Siinä menettäisin nopeasti kontrollin ja siitä kasvaisi luultavasti todella iso päänsärky tulevaisuudessa. Olisi parempi jos kaikki olisi yhdessä paikassa ja ainoastaan näille kahdelle alustalle ominaiset jutut olisivat eri.

Eli pitäisi luoda yksi koodipohja joka sitten niin sanotusti wrapattaisiin molemmille alustoille. Pohjaksi pitäisi kehittää web-sovellus. Web-sovelluksen muuttaminen mobiilisovellukseksi tarkoittaa verkkosivun paketoimista natiiviin kuoreen, jolloin se toimii puhelimessa kuten tavallinen sovellus ja se voidaan ladata sovelluskaupoista.

Wrappereiden ongelma on että et välttämättä pääse käsiksi Applen ja Androidin natiiviominaisuuksiin ilman erillisiä lisäosia. Päätin silti tehdä sen tiettyjen natiiviominaisuuksien kustannuksella. Siitä tulisi riittävän hyvä ja se tekisi tehtävänsä toivon mukaan tarpeeksi hyvin.

Päätin käyttää Capacitor-nimistä wrapperia. Se on moderni silta web-koodin ja natiivialustan välillä.

Teknologiavalinnat: ensimmäinen päänsärky

Olin valinnut perusteknologian, mutta mites loput? Sovellus vaatisi tietokannan, käyttäjäautentikaation, sähköpostijärjestelmän salasanan unohtamiseen, puheentunnistussoftan ja vaikka kuinka monta muuta valintaa.

Jo tässä vaiheessa verenpaine alkoi nousemaan. Koska minulla ei ollut ketään keneltä oikein kysyä, teknologiavalinnat tuntuivat aluksi ylitsepääsemättömältä esteeltä. Vaikka tekoälykoodauksesta puhutaan monen asiantuntijan toimesta helppona, väitän että se on vain osa totuudesta.

Samalla sekunnilla kun päätät tehdä tuotteen laajaan jakeluun, sinulla ei ole varaa tehdä ihan mitä vaan ja sitten vain korjata. Edessä olisivat molempien sovelluskauppojen hyväksymisprosessit sekä potentiaalisten maksavien käyttäjien raivo.

Googlasin asian ja selitin ongelmani sekä ChatGPT:lle että Claudelle ja sain sieltä ehdotuksia miten edetä. Hyväksi todettuja vaihtoehtoja löytyy nykyään paljon, joten sain lopulta valittua palikat joita käyttäisin. Supabase olisi selkäranka.

Tietämättömyyden päänsärky ja hallinnan menettämisen tunne riivasi minua koko projektin ajan. Koska et loppupeleissä tiedä tai osaa, joudut luottamaan täysin niihin neuvoihin joita tekoäly antaa. Ja se tuntui monesti pelottavalta.

Seuraava päänsärky: projektin dokumentaatio ja rakenne

Muistin startup-ajoilta miten koodarit aina jankuttivat dokumentaatiosta ja versionhallinnasta, ja aina joskus kuulin sanan GitHub rivien välistä. Ja taas istuessani läppärin edessä tuijottaen Cursorin mustaa ruutua, kylmä hiki puski paidan läpi.

Se mitä monet eivät kerro aloittelijoille on, että koodia syntyy alussa valtava määrä ja se monesti jopa toimii hyvin. Mutta jos joku kysyisi parin kuukauden päästä miksi asiat on tehty tietyllä tavalla, en osaisi vastata muuta kuin että tekoäly ehdotti niin.

Tutkin ja kyselin jälleen kerran tekoälyltä ja tajusin että GitHub oli jonkinlainen Dropbox joka tallensi koodin pilveen. Silloin se oli ensinnäkin turvassa jos kone hajoaisi. Mutta sen hienous oli kaikkien muutosten seuranta. Joka kerta kun tein korjauksia tai muutin jotain, lähetin sen GitHubiin napin painalluksella. Versionhallinta oli nyt hoidossa.

Design: projektin yksittäinen suurin haaste

Jos joku kysyy mistä vaiheesta tuli eniten harmaita hiuksia, se ei ole itse koodaus vaan design. Minulle on tärkeää että käyttöliittymä on helppo ja että sovellus näyttää mukavalta ja ilmavalta. Koska kyseessä on jotain tylsää, matkalaskut, koin tärkeänä tuoda modernia ja kevyttä ilmettä siihen, joka myös viestisi helppoutta.

Yksi asia joka ei ole muuttunut tekoälyn myötä on designin ja koodin välinen kuilu. Se on ollut olemassa niin kauan kuin digitaalisia tuotteita on tehty, ja se on edelleen olemassa. Palkkasin designerin joka teki sovelluksen näkymät ja flowt Figmassa. Lopputulos näytti hyvältä. Värit olivat oikein, fontit istuivat, kaikki elementit olivat juuri oikeassa kohdassa. Sitten piti siirtää se koodiksi.

Ensimmäinen yritys oli käyttää Figman ja Cursorin välistä integraatiota joka lupasi tehdä tämän automaattisesti. Olin aivan fiiliksissä kun kuulin tästä, koska tiesin designhaasteista. Tunnin sisään menetin kaiken uskon.

Käytännössä se ei toiminut. Työkalu otti kuvakaappauksia näkymistä ja yritti tulkita niitä, ja vaikka pakotin sen lukemaan kuvia ja koodia ja promptailin pää hiessä, lopputulos ei muistuttanut alkuperäistä. Pakottaminen ja säätäminen ei auttanut. Se meni vain monimutkaisemmaksi. Tässä kohtaa projektia kämpästäni kuului paljon tuskanhuutoja.

Lopulta päädyin käyttämään Lovable-nimistä työkalua porttaukseen, ja siitä se lähti toimimaan, ainakin paremmin kuin integraatiolla.

Tekoäly-design versus Designer design

Mutta kokemus opetti jotain tärkeää. Designin siirtäminen koodiksi on edelleen yksi tuotekehityksen hankalimmista vaiheista, eikä tekoäly ole sitä täysin ratkaissut. Se on lähempänä ratkaisua kuin ennen, mutta kuilu on edelleen olemassa.

Syitä on useita. Designer ajattelee pikseleinä ja visuaalisina suhteina. Koodi ajattelee logiikkana, komponentteina ja reunatapauksina. Designer on miettinyt miltä asia näyttää kun kaikki menee hyvin. Koodi joutuu miettimään mitä tapahtuu kun teksti on liian pitkä, kun kuva ei lataudu, kun käyttäjä tekee jotain odottamatonta.

Nämä ovat fundamentaalisesti eri tapoja katsoa samaa asiaa. Staattinen design ei myöskään kerro kaikkea. Figma-näkymä on kuva. Oikea sovellus on liikkuva, reagoiva, elävä asia. Miten elementti animoituu? Miten lista venyy kun siinä on kolme kohdetta verrattuna kolmeenkymmeneen? Näihin kysymyksiin ei ole vastausta kuvassa.

Pitkän taistelun ja usean kompromissin jälkeen sain sovelluksen toimivaksi ja sen näköiseksi että sitä kehtaisi näyttää ja käyttää.

Refaktorointi: koodi olikin huonosti strukturoitu

Noin puolessa välissä projektia huomasin kuinka rivejä kertyi Cursoriin ja koodia tuli lisää ja lisää. Jostain syystä tunsin levottomuutta kun katselin koodia. Muistelin miten koodarit aina puhuivat refaktoroinnista ja puhtaasta koodista. Olikohan minun koodi sellaista? Eihän mulla tietenkään ollut hajuakaan.

Annoin projektitiedot ja pyysin sekä ChatGPT:tä että Claudea kertomaan kaiken mitä mun projektissa oli huonoa ja väärin. Sieltä tuli selvät sävelet molemmilta. Aivan liian keskitettyä koodia yhteen paikkaan. Koko sovellus lepäsi yhden päätiedoston harteilla, ja se oli ilmeisesti valtava riski.

Sovelluksesta piti tehdä modulaarisempi eli se piti pilkkoa pienempiin kokonaisuuksiin. Pyysin Cursoria tekemään selkeän arkkitehtuurisuunnitelman koko sovelluksesta. Siitä syntyi tiedosto jossa koko projekti oli jaettu eri osiin.

Sitten alkoi refaktorointi. Koko sovellus purettiin osiin. Ruudulla sattui ja tapahtui enkä voinut muuta kuin katella ja toivoa että tekoäly saisi ratkaistua tämän ilman että kaikki kaatuisi ja aiheuttaisi bugihelvettiä.

Pari päivää katselin kun se raksutti ja toivoin sormet ristissä parasta. Aina kun yksi refaktorointi oli tehty piti testata että kaikki toimi. Uusi päivitys puhelimeen, paina nappeja, käy läpi flow, etsi virheitä, yritä kaataa sovellus. Ja uudestaan sata kertaa.

Lopulta refaktorointi saatiin maaliin. Sen jälkeen pyysin Cursoria tekemään selkeän arkkitehtuurin ja erilaisia dokumentteja jotka pitäisivät projektin kasassa. Muun muassa uusi sääntö oli että mikään koodinpätkä ei saisi olla pidempi kuin muutama sata riviä.

Testaus: miten kerätä palautetta ulkopuolisilta?

Kun rakentaa minkä tahansa tuotteen, tulee itse sokeaksi. On lähes mahdotonta tietää mitä ulkopuoliset ajattelevat tai miten he tulkitsevat tiettyjä ratkaisuja tai sanamuotoja. Jos ei ole ikinä lanseerannut tuotetta, ei voi tietää kuinka brutaalia käyttäjäpalaute voi olla ja minkälaisissa asioissa tulee väärinkäsityksiä.

Sen takia on äärimmäisen tärkeää kerätä testidataa ennen kuin julkaisee yhtään mitään. Tämä osa prosessista tuntuu myös hyvin ahdistavalta, koska joudut nyt kuulemaan kaikki tavat joilla sun oma sovellus ei toimi tai ei ole ymmärrettävä. Oman pään sisällähän kaikki on kivaa, täydellistä ja hyvin harkittua.

Sekä Applella että Androidilla on omat tavat hankkia testidataa. Applella TestFlight ja Androidilla vastaava.
Apple vaatii kehittäjätilin joka maksaa 99 dollaria vuodessa. Google vaatii omansa, kertamaksu 25 dollaria. Hinnat ovat kohtuulliset mutta se mitä niiden takana odottaa ei ole.

Applen puolella sovelluksen testaamiseen oikeilla laitteilla käytetään TestFlightia. Se on työkalu jolla voi jakaa sovelluksen testikäyttäjille ennen julkaisua. Itse työkalu on kohtuullinen mutta se vaatii Xcodea, Applen omaa kehitysympäristöä jota en ollut koskaan avannut. Xcode on iso, hidas ja täynnä asetuksia joiden merkitystä ei ymmärrä ennen kuin jokin menee pieleen. Opettelu vei aikaa ja promptailua.

Androidin puolella vastaava työkalu on Android Studio ja jakelu tapahtuu Google Play Consolesta. Sama tilanne: en ollut koskaan käyttänyt kumpaakaan ja käyttölogiikka piti opetella alusta.

Testikäyttäjiä sain lopulta joitakin ja heidän palautteensa oli arvokasta. Onboardaus eli se ensimmäinen kokemus kun avaa sovelluksen ensimmäistä kertaa oli kohta johon tuli eniten korjauksia. Myös yksittäisiä bugeja löytyi joita en ollut itse huomannut. Ilman testikäyttäjiä ne olisivat päätyneet julkaistuun versioon.

Yksi raskaimmista vaiheista oli kaikki tähän liittyvä hallinnollinen työ. Developer accountit, sertifikaatit, provisiointiprofilit, kuvakaappaukset jokaiselle näyttökoolle, tietosuojaselosteet, ikäluokitukset, käyttöoikeussopimukset, yritystiedot.

Listaa olisi voinut jatkaa pitkään. Tekoäly ei poista kaikkea tätä työtä. Se auttaa selvittämään ohjeistuksia ja kirjoittamaan dokumentteja, mutta jokainen kohta pitää silti käydä itse läpi ja hyväksyä. Ja siihen meni päiviä.

Ja mitä tämä sitten maksoi?

Kysymys jota moni kysyy ensimmäisenä.

Työaikaa kului reilut kaksi ja puoli kuukautta osa-aikaisena muun työn ohessa. Täysipäiväisesti arvioituna se olisi ollut ehkä kuukausi, mutta sovelluskauppojen hyväksymisprosessit, dokumentaation etsiminen, testaus, design ja iteraatiot hidastavat. En pitänyt tarkkaa kirjaa tunneista mutta kokonaisuus oli selvästi isompi kuin odotin. Pienen nysväyksen määrä on lähes loputon.
Rahaa kului pari tuhatta euroa. Se jakautui karkeasti näin.

Cursor-tilaus vaihtui nopeasti perustasolta 200 dollarin kuukausipakettiin koska tekoälycreditit loppuivat kesken lähes heti kun pääsi vauhtiin. Se oli yllätys mutta ei shokki kun ymmärsi kuinka paljon pyyntöjä kehitystyö tekoälylle oikeasti tuottaa.
Developer accountit ovat kiinteitä kuluja. Apple vie 99 dollaria vuodessa, Google kertamaksun 25 dollaria. Pieniä summia mutta pakollisia.

Pilvipalvelut pyörivät kympeissä kuukaudessa. Ei merkittävä kuluerä tässä vaiheessa.

Eniten rahaa meni designerille. Se oli myös parhaiten käytetty raha koko projektissa. Ilman ammattimaisesti tehtyä designia sovellus olisi näyttänyt siltä miltä tekoälyn generoima käyttöliittymä näyttää ilman ohjausta. Toki silläkin saa ihan hyvän näköistä kamaa nykyään kunhan jaksaa promptailla ja iteroida, mutta suosittelen silti aina oikean designerin kanssa työskentelyä.

Kokonaisuutena pari tuhatta euroa ja muutama kuukausi työtä. Halusin testata onko mahdollista tehdä itse se, mikä ennen olisi ollut mahdotonta. Vastaus on kyllä, mutta se ei tarkoita että se on helppoa.

Niin, ja unohdin mainita. Nyt kun tuote on kaupassa, ei työ ole loppu vaan vasta alkamassa. Nyt pitää alkaa markkinoimaan, myymään, korjaamaan bugeja, jatkokehittämään ja kaikkea muuta mitä tuotteen elinkaareen liittyy. Tuotehan ei ikinä ole valmis.

Tästä artikkelista olen jättänyt pois paljon asioita koska halusin pitää sen jotenkuten tiivistettynä. Lataa sovellus tästä ja pääset samalla eroon matkalaskujen tekemisen tuskasta. Sovelluksen nimeksi laitoin pienen pohdinnan jälkeen Sillä Selvä 🙂

Jos organisaatiossasi pohditaan mitä kuka tahansa voi tehdä tekoälyn kanssa ihan konkreettisesti, ilman että siitä tulee jargonia tai liian teoreettista, ota yhteyttä.

En ole tekoälyasiantuntija enkä konsultti joka on lukenut aiheesta kirjan. Olen tällainen tavallinen tallaaja joka teki sen itse, maallikkopohjalta, ja oppi kantapään kautta. Kerron mielellään kokemuksistani.

Jos se kuulostaa relevantilta, lähetä tästä tarjouspyyntö niin jutellaan.