Kuljetusala pyörii edelleen Excelillä, paperilla ja WhatsApp-viesteillä. Kuski lähtee aamulla ilman tarkkaa tietoa keikoista, asiakas soittaa toimitusajasta, ja kirjanpitäjä kirjoittaa laskut käsin Excel-tulosteen perusteella. Kun yrityksessä on viisi kuljettajaa ja sata tilausta viikossa, järjestelmä ei skaalaudu — se kaatuu hiljaa virhepäätöksiin ja unohtuneisiin laskuihin.

Tämä on case study erään pohjoissavolaisen kuljetusyrityksen logistiikkasovelluksen rakentamisesta kevään 2026 aikana.

Yhteistyökumppanin tilanne

Tilaukset tulivat puhelimitse ja sähköpostitse. Ajojärjestelijä kirjoitti ne Exceliin, soitti kuskeille, lähetti reittikartan WhatsAppissa. Kuski ajoi keikan ja palautti paperilappusen toimistolle. Kirjanpito odotti viikon, kunnes lappu löytyi pinosta. Lasku tehtiin Fennoaan käsin asiakkaan tietoja kopioimalla.

Joka vaiheessa hukkui aikaa, ja joka vaiheessa virhe oli mahdollinen. Asiakas ei nähnyt missä tilaus etenee. Ajojärjestelijä ei nähnyt mitkä keikat olivat kirjaamatta. Kuski ei nähnyt huomispäivän kalenteria. Yrittäjä ei nähnyt katetta yhdestäkään keikasta ennen kuin lasku oli lähtenyt.

Päätös: vakiotyökalu vai räätälöity?

Markkinoilla on logistiikan SaaS-tuotteita. Useimmat ovat hyviä — jos yrityksesi prosessit sopivat tuotteen oletuksiin. Kuljetusala on pirstaloitunut, ja jokaisella yrittäjällä on oma tapansa ajojärjestää, hinnoitella ja kirjata. Vakiotyökalu pakottaa muuttamaan prosessin, kun ihminen on jo tehnyt sen tuhannesti omalla tavallaan.

Lähtökohtia oli kolme:

Yhdellä SaaS-tuotteella ei näitä saa yhtä aikaa. Räätälöity oli ainoa toimiva valinta.

Teknologiavalinnat ja miksi

Pino on tarkoituksella suoraviivainen — yhden henkilön ylläpitämä kokonaisuus ei kestä viittä uutta jännittävää teknologiaa per kerros.

Frontend: React 19 + TypeScript + Tailwind CSS 4, build Vitellä. React on yleisin web-frontend-pino tällä hetkellä, ja TypeScript pakottaa virheet käännösvaiheeseen sen sijaan että ne paljastuvat kuskin tabletilla aamukuudelta.

Backend ja tietokanta: Supabase. Yhdessä paketissa Postgres-tietokanta, autentikaatio (sis. TOTP-pohjainen kaksivaiheinen kirjautuminen), reaaliaikaiset tilanmuutokset ja Edge Functions Denolla. Vaihtoehtona olisi ollut kustomoitu Node.js-backend, mutta se olisi tarkoittanut kymmeniä lisäkomponentteja ylläpitoon ilman vastaavaa hyötyä.

Tietoturva-arkkitehtuuri: Row Level Security (RLS) Postgresissa. Käyttöoikeudet eivät elä sovelluskoodissa "if user.role === 'driver'..."-tasolla, vaan tietokannan policyissä. Vaikka selaimen koodi murrettaisiin tai joku yrittäisi suoraan API-kyselyä, kanta ei palauta riviä jolle käyttäjällä ei ole oikeutta. Tämä on merkittävä turvalisä verrattuna pelkkään frontend-tason rajaukseen.

Hosting ja viestintä: Vercel (frontend), Supabase (backend), Resend (sähköposti) ja Twilio (SMS). Kaikki näistä ovat ulkoisia palveluita joista yrittäjä maksaa suoraan käytön mukaan — ei välikäsiä, ei kk-sopimuksia hallinnoitavana.

Kirjanpitointegraatio: Fennoan REST API. Asiakkuudet synkkaantuvat, lasku luodaan kun ajojärjestelijä hyväksyy kirjauksen. Token-asetukset säilyvät tietokannassa salattuna, ja varsinainen Fennoa-kutsu tehdään palvelinpuolen Edge Functionissa — selain ei koskaan näe kirjanpitoavaimia.

Toteutuksen kriittiset päätökset

Mobile-first kuljettajille

Kuski käyttää sovellusta ajoneuvon hytissä, useimmiten 10-tuumaisella tabletilla. Käyttöliittymä rakennettiin mobile-first: napit ovat sormella osuttavissa, lomakkeet täyttyvät yhdellä kierroksella, eikä kuski tarvitse näppäimistöä keikan päivittämiseen. Toimistokäyttöliittymä toimii samoilla komponenteilla mutta laajempana näkymänä isolla näytöllä.

Roolit ja näkymät erillään

Sovelluksessa on viisi roolia: ylläpitäjä, ajojärjestelijä, asiakas, kuljettaja ja alihankkija. Jokainen rooli avaa eri välilehdet alanavigaatiossa. Asiakas näkee Tilaukset ja Yritys-välilehdet. Kuski näkee Kirjaukset ja Työaika. Ajojärjestelijä Paneelin ja Kalenterin. Yhden roolin tehtävät eivät vuoda toisen roolin näkymiin — siisti pinta, vähemmän opettelua per käyttäjä.

Auditlokki kaikkeen muutokseen

Kun lasku lähtee Fennoaan, kun kirjaus muutetaan, kun käyttäjä luodaan tai poistetaan — jokainen tapahtuma kirjautuu auditlokiin. Vaadittu sekä yrityksen oman jälkeenpäinjäljityksen takia että GDPR:n osalta. Lokia ei voi muuttaa sovelluksen kautta jälkikäteen.

Pehmeä poisto + 30 päivän palautusikkuna

Tilausta tai kirjausta ei poisteta lopullisesti yhdellä klikkauksella. Poistettu rivi merkataan deleted-tilaan, säilyy 30 päivää ja sen voi palauttaa Arkisto-välilehdeltä. Tämä on suora vastaus huoliin "klikkasin väärin." Inhimillisen virheen kustannus on minuutit, ei päivät.

Kaksivaiheinen kirjautuminen ylläpitäjille

Admin- ja ajojärjestelijä-roolit edellyttävät TOTP-pohjaista kaksivaiheista kirjautumista (Google Authenticator tai vastaava). Asiakas- ja kuljettaja-roolit voivat ottaa sen halutessaan käyttöön. EU:n NIS2-direktiivi ulottuu PK-sektorille 2026 aikana — vaatimuksenmukaisuus rakennettiin sisään, ei jälkikäteen päälle liimattuna.

Mitä yhteistyökumppani saa

Tilausten kanban-näkymä korvasi Excelin. Ajojärjestelijä raahaa kuskin keikkaan, kuski näkee uuden työn kalenterissaan välittömästi, asiakas saa automaattisen sähköposti-ilmoituksen toimituksen vaiheista. Kun kuski merkkaa keikan kirjatuksi, ajojärjestelijä saa ilmoituksen ja yhdellä hyväksyntäklikkauksella lasku lähtee Fennoaan.

Konkreettisesti:

Yhteistyökumppani omistaa ohjelmiston

SaaS-ostoksen toinen puoli on aina kuukausimaksu — niin kauan kuin sitä maksat, työkalu toimii. Lopetit maksamisen, työkalu sammuu. Räätälöity sovellus on toinen kategoria: yhteistyökumppani omistaa lähdekoodin, dokumentaation, tietokannan ja kaikki ulkoiset palvelutilit (Supabase, Vercel, Resend, Twilio). Käyttömaksuja menee hostingista käytön mukaan, ei lisenssistä.

Tämä on erityisen arvokasta yrityksen exit-tilanteessa. Kun yritys myydään muutaman vuoden päästä, ostaja saa kassavirran lisäksi konkreettisen omaisuuserän — toimivan, dokumentoidun ohjelmiston joka pyörittää koko liiketoimintaa. SaaS-lisenssejä ei voi myydä, mutta omistettu ohjelmisto on osa yrityksen tasetta ja nostaa kauppahinnan kerrointa.

Hyvin dokumentoitu järjestelmä tarkoittaa myös, että toinen kehittäjä (tai uusi omistaja) voi jatkaa siitä mihin alkuperäinen rakentaja jätti. Lock-in minuun on minimoitu tarkoituksella: vakiintuneet teknologiat (React, Postgres, Supabase, Vercel), kattava docs-kansio (projektisuunnitelma, testaussuunnitelma, käyttöönottosuunnitelma, tietoturvasuunnitelma) ja kaikki kannan migraatiot versionhallinnassa. Yritys ei ole minun varassani.

Mitä tämä kertoo laajemmin

Yhden henkilön ohjelmistotalo ei ollut mahdollista vielä viisi vuotta sitten. Vakavasti otettavan logistiikkasovelluksen rakentaminen vaati tiimin: backend-kehittäjä, frontend-kehittäjä, devops, suunnittelija, testaaja. Helposti puoli vuotta ja satoja tuhansia euroja.

2026:ssa tilanne on toinen. Supabase hoitaa puolet entisestä backend-tiimistä. Vercel hoitaa devopsin. Tailwind hoitaa muotoilun. Tekoäly tukee jokaista vaihetta, jos sitä osaa käyttää oikein. Yksi henkilö ehtii toteuttaa sen mihin aiemmin tarvittiin viisi.

Tämä ei tarkoita että jokainen pieni softaprojekti pitäisi rakentaa räätälöitynä — vakiotyökalut ovat usein oikea ratkaisu. Mutta jos teidän prosessi on niin kotikutoinen että jokainen SaaS pakottaa muuttamaan sitä, räätälöity on nykyään mahdollista budjetilla joka olisi viisi vuotta sitten ollut absurdi.

Onko teillä prosessia jonka pyörittäminen on käsityötä, eikä mikään valmistuote osu siihen? Automaatiostartti alkaa kartoituksella: tunnistetaan toistuvat kohdat ja mietitään yhdessä mikä on järkevin polku eteenpäin.