Yrityssovelluksen kehittämisen hinta

Sovelluksen hinta on työmäärä kertaa tuntihinta, ja vain työmäärään voit vaikuttaa. Tässä kolme kokoluokkaa, mitä kussakin jää pois, viisi budjetista unohtuvaa erää ja julkaisun realistinen kesto.

Julkaistu 1.9.2026 · Päivitetty 9.9.2026

Mustafa Tarabya, VectaAI:n perustaja, DT Nova Tmi. Yhteystiedot ja suora numero.

Lyhyt vastaus: mobiilisovelluksen hintaa ei kannata kysyä eurona vaan kahtena lukuna: työmäärä ja tuntihinta. Työmäärä on ainoa, johon voit itse vaikuttaa, ja se ratkeaa laajuudesta. Käytännössä yrityssovellukset jakautuvat kolmeen kokoluokkaan: yhden käyttötapauksen sovellus ilman käyttäjätilejä, sovellus jossa on käyttäjätilit ja yhteys yhteen omaan järjestelmään, ja sovellus jossa on maksut, useita rooleja tai useita integraatioita. Ero luokkien välillä on moninkertainen, ei prosentuaalinen. Lisäksi budjettiin kuuluu kaksi erää, jotka unohtuvat lähes aina: julkaisutyö kauppoihin ja vuosittainen ylläpito. Meidän hintamme ovat kokonaisuudessaan hinnastossa ilman tarjouspyyntöä.

"Paljonko mobiilisovellus maksaa" on kysymys, johon rehellinen vastaus on toinen kysymys: mitä sovelluksen pitää tehdä. Sama kysymys esitettynä talonrakentamisesta kuulostaisi oudolta, mutta ohjelmistoissa sitä pidetään normaalina, koska ostaja ei näe, mistä työ koostuu.

Tämä sivu tekee kolme asiaa. Se erittelee, mistä sovelluksen työmäärä oikeasti syntyy. Se antaa kolme kokoluokkaa ja kertoo, mitä kussakin jää pois. Ja se kertoo, kauanko App Store -julkaisu oikeasti kestää, koska se on aikataulun tavallisin yllätys. Jos et ole vielä varma tarvitsetko sovelluksen lainkaan, lue ensin mobiilisovellus vai mobiilisivusto.

Mistä työmäärä syntyy

Neljä tekijää selittää valtaosan erosta halvan ja kalliin sovelluksen välillä. Ne kannattaa tuntea, koska niistä neuvotellaan.

Käyttäjätilit. Kirjautuminen, salasanan palautus, käyttäjän tietojen poisto, roolit. Tämä on yksittäisistä ratkaisuista suurin: sovellus ilman tilejä on olennaisesti eri kokoinen työ kuin sovellus, jossa on tilit. Kysy itseltäsi, tarvitaanko tunnistautumista vai riittääkö laitekohtainen tila.

Palvelinpuoli. Jos tieto pitää säilyä ja näkyä muualla kuin puhelimessa, tarvitaan palvelin, tietokanta ja hallintanäkymä. Hallintanäkymä unohtuu määrittelyistä säännöllisesti, mutta jonkun pitää päästä katsomaan ja korjaamaan tietoja — ja se on oma käyttöliittymänsä.

Integraatiot. Jokainen yhteys ulkopuoliseen järjestelmään on oma projektinsa: rajapinnan selvittäminen, virhetilanteet, testaus. Yksi integraatio on hallittava, kolme kertoo, että projekti on kokoluokkaa suurempi kuin miltä se näyttää.

Alustojen määrä. iOS ja Android voidaan tehdä yhteisellä tekniikalla, jolloin suuri osa koodista on jaettua. Testaus ja julkaisu ovat silti kaksi erillistä prosessia. Yksi alusta ensin on lähes aina järkevämpi aloitus, ja oikea valinta on se, jota asiakkaasi käyttävät — älä arvaa sitä, katso sivustosi kävijätiedoista.

Kolme kokoluokkaa ja mitä kussakin jää pois

Kokoluokka	Mitä sisältää	Mitä jää pois	Karkea työmäärä
Yksi käyttötapaus	Yksi selkeä toiminto, tiedot laitteessa tai valmiissa palvelussa, ei tilejä	Käyttäjätilit, hallintanäkymä, integraatiot, maksut	Muutamia työviikkoja
Tilit + yksi integraatio	Kirjautuminen, palvelin ja tietokanta, hallintanäkymä, yhteys yhteen omaan järjestelmään, push-viestit	Maksut sovelluksessa, useat roolit, offline-synkronointi	Kuukausia
Maksut, roolit tai useita integraatioita	Tilaukset tai ostot, useita käyttäjärooleja, useampi järjestelmäyhteys, raportointi	—	Selvästi kuukausia, vaiheistettuna

Työmäärä on tässä tarkoituksella karkea, koska tarkkuus syntyy vasta määrittelystä. Hinnan saat kertomalla työmäärän tuntihinnalla. Pyydä tarjouksessa molemmat luvut erikseen — jos saat vain kokonaissumman, et voi vertailla etkä neuvotella laajuudesta. Suomalaisen kehitystyön tuntihinnat vaihtelevat toimijoittain paljon, ja sama sovellus voi maksaa kaksi kertaa eri verran pelkästään tuntihinnan takia.

Neuvottelusääntö: älä neuvottele tuntihinnasta, neuvottele työmäärästä. Tuntihinnan tinkiminen tuottaa yleensä nuoremman tekijän tai kiireisemmän aikataulun. Laajuuden karsiminen tuottaa saman lopputuloksen halvemmalla. Konkreettinen tapa: pyydä tarjous kolmessa osassa — välttämätön, hyödyllinen ja myöhemmin. Ensimmäinen osa toteutetaan, kaksi muuta odottavat, kunnes tiedät käytöstä jotain.

Erät, jotka unohtuvat budjetista

Määrittely ennen koodia Näkymät, käyttötapaukset, virhetilanteet. Tämä tehdään joka tapauksessa — kysymys on vain siitä, tehdäänkö se etukäteen halvalla vai kesken toteutuksen kalliilla. Muutos määrittelyvaiheessa maksaa murto-osan siitä, mitä sama muutos maksaa valmiiseen sovellukseen.
Kauppojen aineisto Kuvakaappaukset oikeissa koossa, kuvaustekstit, avainsanat, tietosuojaseloste, ikäluokitus, tilausehdot jos myyt tilauksia. Tämä on oma työnsä eikä se sisälly kehitykseen automaattisesti. Kysy tarjouksesta erikseen, kuka sen tekee.
Kehittäjätilit Sovelluskauppojen kehittäjätilit ovat maksullisia ja ne ovat sinun nimissäsi — älä anna toimittajan julkaista sovellusta omalla tilillään, koska silloin et omista julkaisua.
Testaus oikeilla laitteilla Simulaattori ei paljasta kaikkea. Vanhemmat puhelimet, huono verkko, pieni näyttö, käyttöjärjestelmän eri versiot. Varaa tähän aikaa, koska tässä vaiheessa löytyvät ne viat, jotka muuten löytää asiakas.
Vuosittainen ylläpito Apple ja Google julkaisevat uuden käyttöjärjestelmän vuosittain ja muuttavat sääntöjään useammin. Sovellus, jota ei kosketa kahteen vuoteen, alkaa hajota itsestään ja voi pudota kaupasta. Budjetoi ylläpito prosenttiosuutena toteutuksesta, älä nollana.

Kauanko App Store -julkaisu oikeasti kestää

Olemme julkaisseet App Storeen 21 iOS-sovellusta, ja ne näkyvät julkisesti kehittäjäsivullamme. Sen perusteella voimme sanoa yhden asian suoraan: itse tarkistus on nykyään yleensä nopea, mutta ensimmäinen julkaisu venyy lähes aina hylkäyksistä, jotka eivät liity koodiin lainkaan.

Tyypilliset syyt ensimmäisen version hylkäykselle ovat puuttuva tai puutteellinen tietosuojaseloste, tilausehtojen esittäminen väärin, puuttuva linkki käyttöehtoihin sovelluksen kuvauksessa, kuvakaappaukset väärässä koossa tai väärillä laitteilla, sekä toiminnallisuus, jonka tarkoitusta tarkistaja ei ymmärrä ilman selitystä. Jokainen näistä tarkoittaa korjausta ja uutta tarkistuskierrosta.

Käytännön aikataulusääntö: varaa ensimmäiseen julkaisuun viikkoja, älä päiviä, ja tee kaupan aineisto valmiiksi samaan aikaan kuin koodia, ei sen jälkeen. Päivitysten julkaisu on tämän jälkeen huomattavasti nopeampaa, koska suurin osa aineistosta on jo hyväksytty. Jos aikataulusi on sidottu johonkin ulkoiseen päivään — messut, kampanja, kausi — laske takaperin vähintään kuukausi julkaisulle.

Auki laskettu esimerkki: milloin sovellus maksaa itsensä takaisin

Hinta on merkityksetön luku yksinään. Merkityksellinen luku on se, kuinka monta kuukautta menee ennen kuin sovellus on tuottanut enemmän kuin maksanut. Laskun rakenne on aina sama, ja voit tehdä sen ennen kuin pyydät yhtään tarjousta.

Kirjoita ylös neljä lukua. Ensimmäinen: mitä sovellus säästää tai tuottaa kuukaudessa. Jos se säästää työaikaa, kerro säästetyt tunnit tuntikustannuksella. Jos se tuottaa myyntiä, arvioi lisämyynti katteena, ei liikevaihtona. Toinen: toteutuksen hinta. Kolmas: ylläpito kuukaudessa. Neljäs: kuukausittainen nettohyöty eli ensimmäinen luku miinus kolmas.

Jaa toteutuksen hinta nettohyödyllä. Tulos on takaisinmaksuaika kuukausina. Jos se on alle vuoden, päätös on helppo. Jos se on kahden ja kolmen vuoden välillä, mieti pienempää ensimmäistä versiota. Jos se on yli kolme vuotta, sovellus on todennäköisesti väärä työkalu tähän ongelmaan — teknologia ehtii muuttua ennen takaisinmaksua.

Huomaa, mihin lasku on herkin: nettohyötyyn, ei hintaan. Kaksinkertainen arvio hyödystä puolittaa takaisinmaksuajan, ja hyödyn arviointi on juuri se osa, jossa optimismi elää. Siksi kannattaa laskea kahdella oletuksella: sillä, jonka uskot, ja sillä, joka on puolet siitä. Jos päätös kestää molemmat, se on hyvä päätös.

Vaiheistaminen on halvin yksittäinen keino

Sama sovellus rakennettuna kerralla ja rakennettuna kolmessa vaiheessa maksaa suunnilleen saman verran, mutta riski on täysin eri. Vaiheistetussa mallissa maksat ensimmäisestä osasta, näet käytön, ja päätät seuraavan vaiheen sisällön sen perusteella mitä opit. Kerralla rakennetussa mallissa päätät kaiken silloin, kun tiedät vähiten.

Käytännössä tämä tarkoittaa, että ensimmäisessä versiossa on yksi käyttötapaus toteutettuna kunnolla, ei viisi puolittain. Toinen vaihe lisää sen, mitä käyttäjät oikeasti pyytävät. Kolmas vaihe on se, joka jää usein kokonaan tekemättä — ja se on säästö, ei epäonnistuminen.

Sovi vaiheistus myös sopimukseen. Jos toimittaja hinnoittelee vain koko paketin, kysy erikseen ensimmäisen vaiheen hintaa. Vastaus kertoo, kuinka joustava yhteistyö tulee olemaan.

Miten pyydät vertailukelpoisen tarjouksen

Sovellustarjouksia on lähes mahdotonta vertailla, jos jokainen toimittaja määrittelee laajuuden itse. Kirjoita siis sama määrittely kaikille. Siihen kuuluu viisi asiaa: mitä käyttäjä tekee sovelluksessa (lista näkymistä), tarvitaanko käyttäjätilit, mihin järjestelmiin pitää olla yhteys, kummalle alustalle ensin, ja mitä tapahtuu julkaisun jälkeen eli kuka ylläpitää.

Pyydä tarjous eriteltynä: määrittely, toteutus, kaupan aineisto ja julkaisu, ylläpito vuositasolla. Tämä paljastaa erot, joita kokonaissumma piilottaa. Valmis pohja löytyy sivulta tarjouspyyntöpohja, ja toteutuksen laajuutta kuvataan sivulla sovelluskehitys.

Kysy myös kaksi asiaa, jotka eivät näy hinnassa mutta ratkaisevat myöhemmin: kenelle lähdekoodi kuuluu ja kenen nimissä kehittäjätilit ovat. Meillä lähdekoodi, tunnukset ja julkaisu ovat asiakkaan, eikä ylläpito ole määräaikainen — sen voi irtisanoa kuukaudessa. Tämä on syytä tarkistaa kaikilta, koska se määrää, voitko vaihtaa toimittajaa.

Milloin sovellusta EI kannata teettää

Käyttötapausta ei osaa sanoa yhdellä lauseella. Jos et pysty kertomaan, mitä käyttäjä tekee ensimmäisen puolen minuutin aikana, määrittely ei ole valmis, ja projekti muuttuu kalliiksi keskusteluksi. Kirjoita lause ensin.

Sama asia hoituu mobiilisivulla. Jos et tarvitse push-viestejä, offline-toimintaa tai puhelimen antureita, sovellus on kalliimpi tapa tehdä sama. Tarkista tämä ennen kuin pyydät tarjouksia.

Ylläpidolle ei ole budjettia. Sovellus ilman ylläpitobudjettia on kertakulu, joka muuttuu ongelmaksi noin vuoden kuluttua. Jos rahaa riittää vain toteutukseen, tee pienempi sovellus ja jätä ylläpitovara.

Käyttäjämäärä on arvaus. Jos et tiedä, kuinka moni lataisi, aloita verkkopohjaisesta ratkaisusta ja mittaa puoli vuotta. Sen jälkeen tiedät, kannattaako sovellus, ja määrittely on parempi.

Sovellus on markkinointiprojekti ilman toistuvaa käyttöä. Kertaluontoinen kampanjasovellus ladataan harvoin, ja sen ylläpito jää roikkumaan. Kampanjaan riittää verkkosivu.

Usein kysyttyä

Miksi hinta-arviot vaihtelevat niin paljon?

Koska laajuus vaihtelee, ei koska joku hinnoittelee väärin. Kaksi tarjousta samasta "sovelluksesta" voivat tarkoittaa täysin eri työtä: toisessa on käyttäjätilit ja hallintanäkymä, toisessa ei. Vertailukelpoisuus syntyy vain siitä, että kaikki vastaavat samaan kirjalliseen määrittelyyn.

Onko halvempi tehdä iOS ja Android yhtä aikaa?

Halvempi kuin kaksi erillistä natiivitoteutusta, kyllä. Halvempi kuin yksi alusta, ei. Testaus, julkaisu ja kauppojen vaatimukset ovat kaksinkertaiset joka tapauksessa. Yleensä kannattaa aloittaa siltä alustalta, jota asiakkaasi käyttävät, ja lisätä toinen vasta kun ensimmäinen tuottaa. Katso iOS-sovellus ja Android-sovellus.

Paljonko ylläpito maksaa vuodessa?

Se koostuu kehittäjätileistä, käyttöjärjestelmäpäivitysten vaatimista korjauksista ja mahdollisesta palvelinkustannuksesta. Suuruusluokka riippuu sovelluksen koosta ja integraatioiden määrästä. Meidän ylläpitomme hinnat ovat julkisina hinnastossa, ja ne on eritelty niin, että näet mitä kuukausimaksu sisältää.

Voiko sovelluksen tehdä halvemmalla ulkomailta?

Tuntihinta voi olla matalampi, mutta kokonaiskustannus riippuu siitä, kuinka paljon määrittelyä ja korjauskierroksia tarvitaan. Aikaero, kieli ja kulttuurierot lisäävät molempia. Arvioi kokonaisuutta, älä tuntihintaa — ja varmista aina, kenellä on lähdekoodi ja kehittäjätili.

Mitä MVP tarkoittaa käytännössä?

Pienin versio, joka tuottaa käyttäjälle sen hyödyn, jonka takia sovellus tehdään. Se ei tarkoita keskeneräistä eikä huonoa — se tarkoittaa rajattua. Hyvä tapa löytää raja: kirjoita ominaisuudet listaksi ja poista kaikki, joita ilman ensimmäinen käyttäjä saa silti hyödyn. Se, mitä jää jäljelle, on ensimmäinen versio.

Lue seuraavaksi

Lue myös: iOS-sovellus App Storeen · Android-sovellus Google Playhin · yrityksen tietoturva · varmuuskopiointi · hakukoneoptimoinnin hinta · Verkkokaupan perustaminen: hinta, vaihtoehdot ja todellinen kululista · Tietosuojaseloste-malli pienyritykselle · Liiketoimintasuunnitelman pohja ja laskelmat