Miksi sovelluskehityksen hintaa on vaikea arvioida?

Jos ei ole aiemmin ollut mukana sovellusprojektissa eikä ostamassa sovelluskehitystä, on kehityksen hintaa on vaikea arvioida. Mikään sovellusprojekti ei ole täysin samanlainen, kuin toinen. Pienikin ero muuten samankaltaisen sovelluksen vaatimuksissa voi kuitenkin vaikuttaa merkittävästi työn määrään ja sitä kautta hintaan.

Mitä sovelluskehityksen hinta yleensä sisältää?

Sovelluskehityksen hinta muodostuu useasta eri osasta, joista varsinainen kehitystyö on vain yksi. Kokonaiskustannuksiin vaikuttavat jo projektin alkuvaiheessa tehtävät päätökset, kuten mitä ollaan rakentamassa, mitä sovelluksen täytyy tehdä ja toisaalta mitä ei lähdetä tekemään, minkälaisella teknologiavalinnalla lähdetään liikkeelle ja mikä on kehitystiimin rakenne.

Tässä vaiheessa tehdään tärkeimmät päätökset - miten päästään liikkeelle siten, ettei räjäytetä pankkia "turhaan" kun pienemmälläkin kokonaisuudella oltaisiin saatu täysin markkinakelpoinen tuote. Ja toisaalta, jos yritetään venyttää penniä joka kohdassa, saatetaan saada tuote, joka ei oikeasti täytä edes minimivaatimuksia riittävästi ollakseen oikeasti käyttäjälle hyödyllinen sovellus.

Katsotaan seuraavaksi kuluja tarkemmin eriteltynä.

1. Teknologia ja tiimi

Sovelluskehitystiimin palkka on suurin yksittäinen sovelluskehityksen kulu. Koodin "olemassaolo", julkaisu, tietokannat tai muut eivät nykypäivänä maksa kovinkaan paljoa. Edelleen, tällä AI-aikakaudella, kalleinta on saada hyvä sovellus suunniteltua ja koodi kirjoitettua.

Moni on edelleen siinä uskossa, että sovelluksia ei alle 100 000 € saa. Tämä oli enemmän totta vuosikausia sitten, kun koodatiin merkki merkiltä perinteisellä tavalla, koko tiimin voimin, monta vuotta. Tämä tarkoitti sitä, että projektissa oli mukana projektipäällikkö, arkkitehti, käyttöliittymäsuunnittelija(t), sekä kehittäjä(t) "front-end", että "back-end"-puolelle (karkeasti, fronttikehittäjä koodaa sen, mitä käyttäjä näkee, bäkkärikehittäjä sen mitä käyttäjä ei näe, vaan miten tietoa tallennetaan ja miten se kulkee sovelluksen sisällä).

Tälläisiä sovelluksia on paljon. 5-10 projektitiimin jäsentä eri vaiheissa projektia, joka kestää 2-3 vuotta.. Tämä on kallista ja edelleen arkea tietyissä projekteissa, kuten toisaalta kuuluukin. Kun lähdetään uudistamaan verohallinnon tai Traficomin sovelluksia ja rajapintoja, jossa on käytännössä koko Suomi käyttäjinä, tietoa talletetaan ja siirretään valtavasti ja tietoturvaan on kiinnitettävä erityistä huomiota, projekti on jo lähtiessään todella laaja. On loogista, että nämä sovellukset maksavat, ne kestävät ja niihin osallistuu paljon ihmisiä. Myönnettäköön, julkispuolella on paljon parannettavaa sovellusprojektien budjetoinnista ja ostamisesta.

Mutta entäs ns. keskivertosovellukset? Uudet startupit, pk-yritysten omat työkalut, mobiilisovellukset?

Varsinkin nykyään, kun Low-codella ja AI-avusteisella koodaamisella ollaan saatu kehitysaikaa huomattavan paljon lyhyemmäksi, eikä projekteihin aina tarvita kaikkea tuota tiimiä, vaan pärjätään esim. rakenteella projektipäällikkö, suunnittelija/arkkitehti ja kehittäjä. Näillä teknologioilla on yleistä, että sama kehittäjä tekee sekä näkyvän, että näkymättömän osan sovelluksesta (edellä mainittu front ja back).

3 ihmistä varattuna 6 kuukaudeksi on hyvin erilainen lasku, kuin edellinen traficom laskenta. Tämä on syy, miksi sovellukset ovat enemmän ja enemmän saavutettavia monenlaisille yrittäjille ja yrityksille. Vähemmän kehittäjiä, vähemmän aikaa = pienempi kustannus.

2. Suunnittelu ja määrittely

Sitten varsinaiseen projektiin. Tässä vaiheessa ollaan päätetty, mitä teknologioita käytetään ja minkälainen tiimi arviolta tarvitaan.

Suunnittelu ja määrittely ovat ensimmäinen kuluerä sovellusprojektissa. Tässä vaiheessa selvitetään, mitä ollaan rakentamassa, kenelle sovellus on tarkoitettu ja mitkä toiminnot ovat aidosti tarpeellisia. Käytännössä suunnittelu voi tarkoittaa esimerkiksi työpajaa, speksausta (määrittelyä ja rajausta), jossa sovellusidea puretaan konkreettiseksi kokonaisuudeksi.

Meillä tätä alkuvaiheen suunnittelua tehdään kahdessa osassa:

1. Sovellustyöpaja. Työpajassa sovellusidea kirkastetaan ja muutetaan konkreettiseksi suunnitelmaksi. Kahden tunnin työpajan ja sen puhtaaksikirjoituksen jälkityönä asiakas saa dokumentin, jonka avulla sovellusprojekti voidaan toteuttaa tehokkaasti – meidän tai muun kumppanin kanssa. Työpajassa listataan käyttäjän tarpeita, toiminnallisuuksia ja niiden yksityiskohtia, sekä piirretään alustavaa ajatusta käyttöliittyämästä. Oma idea konkretisoituu työpajassa selkeäksi paketiksi, jota on helppo jakaa ja esitellä eteenpäin.

Työpajan hinta on 1 470 € alv 0, joka hyvitetään kokonaisuudessaan, jos projekti etenee toteutukseen meidän kanssa.

2. Prototyyppivaihe. Tämä on sovellusprojektin ensimmäinen vaihe, eli se vaihe kun projekti on ostettu ja aloitettu. Tässä vaiheessa sovellus oikeasti suunnitellaan. Mietitään tietokantaa (mitä tietoja kerätään, miten tallennetaan, mitä käyttäjä voi ja ei voi tehdä, käyttäjäsäännöt), miltä sovelluksen eri näkymät näyttävät, miten kävijä kulkee sivulta toiselle. Tässä kohtaa piirrellään auki, miltä sovellus näyttää sisältä ja ulkoa.

Tämä on tärkeä vaihe, koska vaikka teemme prototyyppejä AI-avusteisesti, joka on todella nopeaa, tässä ei vielä käytetä "oikeaa tietoa". Ei tietokantaa, ei juurikaan logiikkaa. Tässä vaiheessa on nopea vielä tehdä muutoksia ja päätöksiä. Tämä vaihe tuotoksineen on käytännössä se, jonka pohjalta kehittäjät lähtevät tekemään varsinaista toteutusta.

3. Sovelluksen kehitys

Sovelluksen kehitys on projektin itsestään selvin kuluerä. Tässä vaiheessa itse sovellus rakennetaan: tehdään näkymät, toiminnallisuudet, tietokanta ja sen säännöt, kirjautumisplolut,  integraatiot, maksuliikenne, kaikki, mitä kyseinen sovellus tarvitsee. sekä tarvittava testaus ja viimeistely.

Tässä palataan alun määrittelyn ja suunnittelun tärkeyteen. Dokumentin tekstin muokkaus on nopeaa. Prototyypin muokkaaminen on nopeaa. Kehittäjän tekemä sama toiminnallisuus kolmatta kertaa uusilla ideoilla - tämä on hidasta ja kallista. Tätä yritetään välttää mahdollisimman paljon hyvällä suunnittelulla.

Kuten aiemmin mainittu, kehitystyön määrä ja kustannus riippuvat suoraan siitä, kuinka laaja ja monimutkainen sovellus on. Yksi todella laaja käyttötapaus voi työmäärältään olla lopulta melko sama, kuin 5-6 helpompaa toiminnallisuutta yhdessä.

4. Julkaisu ja käyttöönotto

Julkaisu ja käyttöönotto tarkoittavat vaihetta, jossa valmis sovellus viedään tuotantoon ja käyttäjien saataville. Tämä voi tarkoittaa sovelluksen julkaisemista web-versiona (www.sovellus.fi) tai sovelluskaupoissa, tai molemmissa.

Sovelluksen julkaisu ei ole suuri kuluerä itsessään, webbiin sovelluksen saa näppärästi, mutta sovelluskauppoihin julkaisu on hieman työläämpää.

Mobiilisovelluksissa sovelluskaupat edellyttävät kehittäjätiliä. Applen App Store vaatii vuosimaksullisen kehittäjätilin, joka maksaa 99 USD vuodessa. Google Play -kaupassa kehittäjätili maksetaan kerran, ja kertamaksu on 25 USD. Nämä maksut menevät suoraan Applelle ja Googlelle, eivät kehityskumppanille. Nämä tilit avaa ja kulut maksaa sovelluksen ostaja ja omistaja, eli asiakas.

Toinen "työläämpi" vaihe liittyy julkaisuprosessiin. Tässä on molemmilla sovelluskaupoilla omat "checklistansa", jonka vaiheet on tehtävä, ennen kuin sovellus voidaan laittaa arviointikierrokselle ennen julkaisua. Tähän liittyvät mm. maksutietojen ja veropapereiden täyttämistä, tietosuojaselosteita, screenshotteja ja kuvauksia sovelluksesta jne. Tämä ei ole vaikeaa, vie vain hetken aikaa.

5. Alustamaksut ja tekniset palvelut

Jotta sovellus toimii ja on käyttäjien käytettävissä, se tarvitsee taustalle palvelimen ja tietokannan. Low-codella, kuten FlutterFlowlla, maksetaan myös lisenssimaksua kehitysympäristöstä, jossa sovellus tehdään. Vähän kuin Squarespace tai vastaavat. Näistä kuluista syntyvät niin sanotut alustamaksut.

Tyypillisiä kuluja ovat esimerkiksi palvelin- tai pilvipalvelumaksut ja tietokantapalvelut. Käytännössä nämä ovat kuukausi- tai käyttöperusteisia maksuja, jotka määräytyvät sen mukaan, kuinka paljon sovellusta käytetään ja kuinka paljon dataa siihen tallennetaan.

Tekstin lisääminen, muokkaaminen, siirtäminen ja poistaminen ovat hiekanmurusia tietokannassa, mutta esimerkisi pitkien, korkealaatuisten videoiden hostaaminen maksaakin jo helposti enemmän. Käytännössä tietokantamaksu on sitä, että maksat siitä, että joku, kuten Microsoft, Amazon, tai esm. Supabase (tietokanta), säilyttävät sovelluksesi dataa.

Pienessä tai keskisuuressa sovelluksessa alustamaksut voivat olla tyypillisesti noin 50–200 € kuukaudessa. Näitä ei kannata pelätä, jos sovelluksen tietokannassa on siirryttävä esim. kalliimpaan pakettiin, tarkoittaa se sitä yleensä, että sovelluksella on kasvavaa käyttöä ja asiakkaita, joten rahaakin luulisi tulevan enemmän, ja tietokanta tavallaan kasvaa toiminnan mukana.

6. Ylläpito ja jatkuvat kulut

Sovelluksen julkaisu ei tarkoita, että työ ja maksut päättyy siihen. Ohjelmistoja täytyy päivittää, korjata ja joskus myös mukauttaa muuttuneisiin vaatimuksiin. Tätä kutsutaan ylläpidoksi.

Ylläpito voi sisältää esimerkiksi bugien korjaamista, tietoturvapäivityksiä sekä teknisten riippuvuuksien päivittämistä. Jos sovellus on mobiilisovellus, myös käyttöjärjestelmien uudet versiot voivat edellyttää muutoksia.

Kustannukset vaihtelevat sen mukaan, kuinka aktiivisesti sovellusta kehitetään ja kuinka laaja se on. Pienessä sovelluksessa ylläpito voi tarkoittaa muutamia satoja euroja kuukaudessa tai satunnaista tuntityötä tarpeen mukaan. Laajemmissa kokonaisuuksissa ylläpiton kustannukset kasvaa luonnollisesti. Mitä monimutkaisempi sovellus on, sitä enemmän on myös mahdollisia päivitys- ja korjaustarpeita.

7. Jatkokehitys

Sovellus"projekteista" puhuminen on siinä mielessä haastavaa, että sovelluskehitystä ei pidä ajatella kertakuluna, vaan osana omaa yritystä, joka jatkuvasti kehittyy ja johon varataan resurssia. Jatkokehitys tarkoittaa uusia ominaisuuksia, olemassa olevien toimintojen muokkaamista tai vaikka käyttöliittymän selkeyttämistä.

Kun sovellus otetaan käyttöön, aletaan usein toden teolla nähdä, mitä pitäisi vielä parantaa tai lisätä. Käyttäjiltä tulee palautetta, kilpailijat julkaisevat uusia ominaisuuksia, tulee uusia omia ideoita ja markkina muuttuu. Ei kannata jäädä sovelluksen kanssa laakereilleen makaamaan.

Tämä ei siis toimi niin, että laitetaan sovellus liveksi ja heitetään koodarit pihalle. Mieti vaikka Metaa tai Hubspottia. Kyllä sielläkin parhaillaan joku kirjoittaa sovellukseen uutta koodia, korjaa teknistä velkaa tai suunnittelee seuraavia toiminnallisuuksia.

Jatkokehitys on siitä turvallista ja ennustettavaa, että tarpeet ja toiminnallisuudet saadaan suunniteltua ja hinnoiteltua hyvissä ajoin ennen aloitusta. Eli jos teet jatkokehitystä projekteina, tiedät tarkalleen mitä tehdään, milloin tehdään ja kauan maksaa. Osa meidänikin sovelluksista elävät ns. ylläpito-jatkokehitys-yllpito-sykliä, jossa osana ajasta ollaan ns. katsomassa että sovellus toimii ja tehdään pieniä muutoksia olemassa oleviin asioihin, kehitetään lisää, ja sitten siirrytään taas ylläpitoon.

Mitkä kulut yllättävät ostajan useimmin?

Useimmiten yllätys ei ole itse sovellusprojektin hinta, vaan se, mistä kaikesta lopulta maksetaan. On helppo ymmärtää, että itse sovelluksen koodaaminen maksaa. Sen sijaan harvempi tulee ajatelleeksi, että etenkin sovellusmaailmassa hyvin suunniteltu on puoliksi tehty.

Toisaalta, erityisesti jatkuvat kulut, kuten alustamaksut ja ylläpito, tulevat monelle uutena asiana. Vaikka kuukausisumma ei olisi suuri, se ne tulee silti yllätyksenä usealle. Tämä johtuu ehkäpä juuri siitä, että sovellusta ollaan ostamassa projektina, eikä jatkuvana satsauksena yrityksen kilpailukykyyn tai kehittämiseen.

Miten kustannuksiin voi vaikuttaa?

Suurin yksittäinen tekijä kustannusten hallinnassa on hyvä suunnittelu. Kun sovelluksen tavoite, laajuus ja rajaukset on mietitty kunnolla ennen kehitystyön aloitusta, projektin aikana tulee vähemmän yllätyksiä.

Usein kustannukset kasvavat silloin, kun suunta muuttuu kesken toteutuksen. Uusia ideoita syntyy, ominaisuuksia lisätään tai jo tehtyä joudutaan muuttamaan. Muutokset eivät ole väärin, mutta ne vaikuttavat suoraan työmäärään ja sitä kautta hintaan.

Toinen tapa vaikuttaa kustannuksiin on rajata ensimmäinen versio selkeästi. Kaikkea ei tarvitse rakentaa kerralla. Kun aloitusversio pidetään maltillisena, projekti pysyy hallittavana ja jatkokehitys voidaan tehdä myöhemmin tarpeen mukaan. Hyvin suunniteltu ja selkeästi rajattu projekti on lähes aina edullisempi kuin sellainen, jossa suunta elää koko ajan.