Mitä ohjelmistokehitys maksaa?

2.1 Tuntihinta

Ohjelmistokehittäjän tai tiimin tuntihinta voi hyvin yleisesti olla:

• Halpa freelanceri (Itä-Eurooppa / Aasia): 20–40 €/h
• Freelancer Suomessa / Länsi-Euroopassa: 60–110 €/h
• Pieni ohjelmistotalo (2–10 hlö): 80–130 €/h
• Konsulttitalo, sertifioidut prosessit, SLA:t, vastuu: 120–180+ €/h

Tuntihinta ei ole sattumaa. Se sisältää mm. palkan, verot, lomat, yrityksen riskin, projektijohdon, takuutyön ja sen,
että joku on oikeasti tavoitettavissa kun asia hajoaa perjantai-iltana.

Virhe, jonka ostajat usein tekevät: vertaillaan vain tuntihintaa, ei tuottavuutta.
Hidas kehittäjä 40 €/h voi tulla kalliimmaksi kuin kokenut kehittäjä 110 €/h,
jos sama tehtävä vie 30 h vs 6 h.

2.2 Laajuus

Hintaa ohjaa erityisesti tämä kysymys:
Kuinka paljon uutta logiikkaa ja dataa järjestelmän pitää hallita?

Esimerkiksi:

• Onko kyseessä pelkkä markkinointisivu, jossa on lomake?
• Vai monimutkainen liiketoimintasovellus, joka laskee hintoja, hyväksyy tilauksia ja synkronoi varastoa kolmesta eri järjestelmästä?
• Tarvitaanko kirjautuminen, käyttäjäroolit, laskutus, raportointi, audit trail, integraatiot (ERP, CRM, maksut, varasto, logistiikka)?

Jokainen ”liiketoimintasääntö” (esim. ”jos asiakas kuuluu ryhmään X, laskutus menee polkua Y”) maksaa.
Logiikka maksaa enemmän kuin ulkoasu.

2.3 Integraatiot

Mitä enemmän integraatioita, sitä kalliimpi projekti.
Syyt:

• jokainen ulkoinen järjestelmä voi muuttua ilman varoitusta
• pitää rakentaa virheenkäsittely
• pitää hoitaa tietoturva (API-avaimet, salaus, lokeihin ei saa vuotaa dataa)

Tyypillisesti yksi integraatio (valmis API, dokumentaatio ok, ei räätälöintiä)
maksaa luokkaa 2 000–10 000 € rakentaa ja testata.

Jos integraatio on huonosti dokumentoitu tai vanha (esim. vanha ERP SOAP-rajapinnalla),
kustannus voi moninkertaistua.

2.4 Laatuvaatimukset

Mitä tapahtuu jos järjestelmä kaatuu?

• Jos vastaus on ”ei haittaa, korjataan maanantaina”, kustannus on alhaisempi.
• Jos vastaus on ”me menetämme rahaa minuuteissa, järjestelmän pitää pysyä pystyssä ja audit-lokit pitää olla kunnossa tilintarkastajaa varten”, kustannus nousee nopeasti.

Toisin sanoen:

• Prototyyppi, sisäinen käyttö, ei arkaluonteista dataa → halpa.
• Tuotantopalvelu, henkilödata, maksutiedot, juridinen vastuu → kallis.

Tämä vaikuttaa suoraan vaadittuun testaukseen, dokumentaatioon, monitorointiin,
fallback-mekanismeihin, tietoturva-auditointeihin ja sopimuksiin.

2.5 Projektinhallinta

Pelkkä koodi ei riitä. Joku:

• priorisoi
• dokumentoi
• päättää speksit
• sanoo ei ominaisuuspyynnöille, jotka rikkovat kokonaisuuden

Jos tätä ei tee ostaja itse, myyjä tekee sen ja laskuttaa siitä.
Tämä voi olla 10–30 % projektin hinnasta ja se yllättää monet.

2.6 Ylläpito

Uutta ohjelmistoa ei ”osteta ja unohdeta”.

• Kirjastot vanhenevat
• Tietoturvapäivitykset tulevat ulos jatkuvasti
• Selainten ja iOS/Androidin päivitykset rikkovat vanhaa koodia
• Liiketoiminta muuttuu ja vaatii pieniä muutoksia

On realistista varata ylläpitoon 10–20 % kehityshinnasta per vuosi.
Tämä on jatkuva kustannus, ei kertaluonteinen.

3.1 Laske itse

Projektin hinta ≈ (arvioidut kehitystunnit) × (tuntihinta)

Missä arvioidut kehitystunnit sisältää:

• suunnittelu 10–20 %
• varsinainen toteutus 50–70 %
• testaus ja korjaus 15–25 %
• julkaisu ja dokumentaatio 5–10 %

Jos jokin arvioidaan ”400 h toteutusta”, todellinen projekti ei ole 400 h.
Todellinen voi olla 600 h, kun lasketaan kaikki ympärillä oleva työ.

3.2 Esimerkkejä

4.1 Projektin ohjaus ostajan puolella

Sinun puoleltasi pitää olla joku, joka päättää mitä
ohjelmistokehitys-tiimi tekee seuraavaksi:

• mitä ominaisuus tekee
• miten sen pitää toimia
• mikä on tärkeää nyt ja mikä voidaan jättää myöhemmäksi

Jos tätä ei tee kukaan, kustannus nousee,
koska tiimi rakentaa väärää asiaa ja joutuu purkamaan ja tekemään uudestaan.
Tyypillisesti tämä on suurin kustannusten räjäyttäjä.

4.2 Muutokset kesken projektin

Jos speksi muuttuu, hinta muuttuu. Tämä ei ole ”lisälaskutus”, tämä on matematiikka:

• Jos 30 h ominaisuus vaihdetaan 80 h ominaisuuteen, se vie 50 lisätuntia.

Projektit kaatuvat usein siihen, että ostaja ei ymmärrä,
että prioriteettimuutos on budjettipäätös.

4.3 Testaus oikeilla käyttäjillä

Jos softa koskee työntekijöitä tai asiakkaita, testaus heidän kanssaan on kriittinen vaihe.
Tämä vie tunteja. Jos se jätetään väliin, virheet siirtyvät tuotantoon,
mikä maksaa myöhemmin enemmän.

4.4 Käyttöönotto ja koulutus

Ohjelmisto, jota kukaan ei osaa käyttää, ei tuota arvoa.
Käyttöohjeet, videot, koulutus, tuki → nämäkin pitää tehdä.
Ne vievät tunteja.

5.1 Pura ominaisuudet tuntiarvioksi

Pyydä eriteltävät työt (esim. kirjautuminen 20 h, raporttisivu 30 h, integraatio 60 h).
Jos saat tarjouksen pelkkänä ”kokonaisuus 15 000 €”,
et voi arvioida mitään.

5.2 Kysy kuka tekee työn

Seniori vai juniori? Oma tiimi vai alihankkija?
Tämä vaikuttaa laatuun, ennustettavuuteen ja siihen,
kuka on vastuussa kun ongelma tapahtuu.

5.3 Kysy ylläpitomallia

Kuka vastaa korjauksista tuotannossa 6 kuukauden päästä?
Mikä on vasteaika? Mikä maksaa erikseen?

5.4 Kysy omistajuutta

Kenelle koodi kuuluu?
Saatko lähdekoodin itsellesi ja voitko vaihtaa tekijää myöhemmin ilman lukittumista?