Fra AI-prototype til ferdig system: slik gjør du det riktig

Prototypen deres har allerede gjort en viktig jobb

Flere og flere av dem vi snakker med har laget noe selv med AI-verktøy: en fungerende prototype av en app, en portal eller et internt system. Noen har testet den på kolleger, noen har vist den til kunder, og reaksjonen er ofte den samme: dette vil vi ha.

Det er verdt å stoppe opp ved hvor verdifullt det er. Det dyreste og mest uforutsigbare i et utviklingsprosjekt er vanligvis uklare krav, misforståelser om hva som egentlig skal lages. En fungerende prototype fjerner mesteparten av den usikkerheten. Dere vet hva dere vil ha, dere har sett flyten, og dere kan peke på skjermbildene. Det er en bedre kravspesifikasjon enn de fleste dokumenter vi har fått gjennom årene.

Spørsmålet er hva veien videre bør være.

Er prototypen klar til å tas i bruk? Nei, i utgangspunktet ikke

AI-verktøyene er blitt gode til å lage ting som fungerer i demo. Men det er stor avstand mellom en demo og et system som kunder, pasienter eller ansatte skal bruke hver dag. Det som sjelden er på plass i en AI-generert prototype:

• Sikkerhet og tilgangsstyring. Hvem får se hva, sikker innlogging (gjerne BankID eller ID-porten), og beskyttelse av data i hvile og transitt.
• Integrasjoner. Kobling mot regnskapssystem, fagsystemer, registre og de andre systemene virksomheten lever av.
• Robusthet og skala. Hva skjer med 500 samtidige brukere, dårlig nett, eller data som ikke ser ut som testdataene?
• Universell utforming. Lovkrav for mange, og god praksis for alle.
• Drift og vedlikehold. Overvåking, backup, oppdateringer, og noen som svarer når noe er nede.

Ingenting av dette er kritikk av prototypen. Den skulle bevise ideen, og det gjorde den. Men den ble ikke laget for å bære ansvaret et produksjonssystem bærer.

Hvorfor vi som regel anbefaler å utvikle på nytt, med gjennomprøvd teknologi og metode

Det kan virke fristende å la noen «bare gjøre ferdig» prototypekoden. Vår erfaring, etter å ha sett mange kodebaser gjennom årene, er at det ofte blir den dyreste veien: omfanget er uforutsigbart, den tekniske gjelden følger med inn i produksjon, og hver senere endring koster mer enn den burde.

Det som som regel lønner seg, er å bruke prototypen som det den er best som, en presis kravspesifikasjon, og utvikle selve systemet med en gjennomprøvd techstack. Hos oss betyr det én fast stack og én fast måte å jobbe på, finslipt gjennom mer enn 220 leveranser. Det er ikke en begrensning, det er grunnen til at vi kan love fast pris, høy fart og løsninger som er like ryddige å drifte om fem år som ved lansering. Og fordi stacken består av kjente, standard teknologier, er koden deres: dere står fritt også den dagen dere vil videre med noen andre.

Og her er poenget som overrasker mange: med en fungerende prototype som utgangspunkt går utviklingen raskere og prisen blir mer presis enn i et vanlig prosjekt. Usikkerheten som normalt krever forprosjekt og avklaringsrunder, er allerede ryddet av veien, av dere.

Slik foregår det i praksis

1. Vi ser på prototypen sammen. Dere viser hva den gjør, vi stiller spørsmålene som avdekker det prototypen ikke viser: roller, integrasjoner, datamengder, krav til sikkerhet og drift.
2. Omfang og fastpris. Fordi prototypen viser målet, kan vi som regel gi fastpris raskt, i større prosjekter etter et kort forprosjekt.
3. Utvikling basert på vår techstack. Samme team hele veien, sprinter med demo underveis, og deler av løsningen tas gjerne i bruk før alt er ferdig.
4. Lansering og drift. Publisering, overvåking, backup og videreutvikling, med en driftsavtale som er avklart før vi starter.

Kort oppsummert

Har dere laget noe med AI-verktøy som folk vil ha? Da har dere gjort den vanskeligste delen av kravarbeidet selv. Ikke la noen flikke på prototypekoden, og ikke legg den i skuffen. Bruk den som kravspesifikasjon, og få systemet utviklet ordentlig, med sikkerhet, integrasjoner og drift, av noen som står ansvarlig for at det virker.

Vis oss gjerne prototypen deres, så gir vi et konkret estimat og et ærlig råd om veien videre. Les også om systemutvikling, hva utvikling koster, og hva MVP egentlig betyr.