Low-code eller tradisjonell utvikling?
Low-code er plattformer som OutSystems, Mendix og Power Platform, der IT bygger raskere med ferdige byggeklosser. De gjør skjemaer og arbeidsflyter raskere å lage, men bremser ved avanserte integrasjoner, egen UX og versjonskontroll. Tradisjonell utvikling gir full frihet, men tar lengre tid. Den største forskjellen er lisenskostnaden og innlåsingen i low-code.
Low-code (lavkode) presenteres ofte som en måte å bygge programvare raskere og billigere på, nesten uten håndverket. Bildet er forenklet. Low-code er et kraftig verktøy for riktig oppgave, men det innebærer en prislapp og en innlåsing som ikke vises ved første øyekast. For å velge klokt må du vite hva plattformene faktisk gjør raskere, hvor de bremser og hva de koster over tid, ikke bare ved oppstart.
Hva low-code faktisk er, og hva det ikke er
Først et viktig skille: Low-code er ikke no-code. No-code henvender seg til brukere ute i virksomheten som bygger enkle apper uten å kunne programmere. Low-code henvender seg til IT-avdelinger og utviklere. Det gjør profesjonell utvikling raskere med ferdige byggeklosser, men forutsetter fortsatt teknisk kompetanse.
I den kategorien finner du plattformer som OutSystems, Mendix og Microsofts Power Platform. Tanken er at utviklere setter sammen applikasjoner av ferdige komponenter i stedet for å skrive alt for hånd. Det går raskere for det plattformen er laget for, men løsningen er bundet til plattformens rammer.
Hva plattformene gjør raskere
Low-code er sterkest på det avgrensede og regelmessige. Interne prosessapper. Skjemaer for å registrere data. Arbeidsflyter som skal ta en sak fra A til B. Enklere grensesnitt oppå eksisterende systemer.
For slike oppgaver er tidsgevinsten reell. Det som ellers ville kreve uker med rutinekode, blir dager med konfigurasjon, og en IT-avdeling kan levere internt uten å sette i gang et fullt utviklingsprosjekt. Holder dere dere innenfor det plattformen er laget for, er hastigheten det sterkeste argumentet.
Hvor de bremser
Problemene begynner i utkanten av det plattformen er tenkt for. Tre områder går igjen:
- Avanserte integrasjoner. Skal løsningen snakke tett med andre systemer på uvanlige måter, blir det fort tungvint og noen ganger umulig.
- Egen brukeropplevelse. Vil dere ha et unikt design og en følelse som skiller dere fra mengden, setter plattformens maler grenser.
- Versjonskontroll og testing i team. Disiplinert utvikling i stor skala, med flere parallelle spor, fungerer bedre med tradisjonell kode.
Konsekvensen kan bli den dyreste: Dere bygger det enkle raskt, møter veggen når det blir vanskelig og må likevel bygge om deler i vanlig kode. Da har low-code ikke spart tid, men lagt til en runde.
Kostnaden og innlåsingen
Her ligger det som virkelig skiller low-code fra tradisjonell utvikling. Low-code-plattformer koster løpende lisensavgifter, ofte knyttet til antall brukere eller apper, og de kan vokse til betydelige beløp over tid. Den raske starten skjuler lett at kostnaden fortsetter så lenge løsningen lever.
Verre er innlåsingen. En app bygget i en low-code-plattform lever på plattformens premisser og er vanskelig å flytte derfra. Øker prisen eller endres vilkårene, har dere begrenset handlingsrom fordi alternativet ofte er å bygge alt på nytt. Med tradisjonell kode eier dere det som er bygget, og kan ta det med dere. Den friheten er prisen low-code betaler for hastigheten sin.
En kort sammenligning
| Aspekt | Low-code |
|---|---|
| Fart for enkle arbeidsflyter | Høy, dager i stedet for uker |
| Avanserte behov og egen UX | Begrenset, bremser i utkanten |
| Løpende kostnad | Lisensavgifter som vokser over tid |
| Eierskap og frihet | Låst til plattformen |
Tradisjonell utvikling er det motsatte på flere av punktene: tregere start og høyere startkostnad, men full frihet, ingen lisensinnlåsing og egen kode dere eier.
Et scenario
Tenk deg at en IT-avdeling trenger en intern app for å håndtere saker mellom avdelinger, med skjemaer, et par arbeidsflyter og ingen høye designkrav. Der kan low-code levere på en brøkdel av tiden, og lisenskostnaden er en fornuftig pris for farten. Tenk deg i stedet at det samme selskapet skal bygge et kundevendt produkt med egen identitet som skal leve i mange år. Da veier eierskap, fri UX og frihet fra lisensinnlåsing tyngre enn den raske starten, og tradisjonell utvikling blir det tryggere valget. Spørsmålet er alltid hvor sentral løsningen er og hvor lenge dere har tenkt å beholde den.
Vi i Weapp bygger med tradisjonell utvikling der eierskap og frihet teller, men hjelper gjerne til med å avgjøre om et behov er et typisk low-code-tilfelle eller ikke. Vil dere sparre om hvilket spor som passer dere? Se på tjenestene våre, eller ta kontakt.
Ofte stilte spørsmål
Er low-code det samme som no-code?
Nei. No-code er rettet mot brukere ute i virksomheten som ikke kan programmere og bygger enkle apper selv. Low-code er rettet mot IT-avdelinger og utviklere. Det gjør profesjonell utvikling raskere med ferdige byggeklosser, men krever fortsatt teknisk kompetanse. Low-code håndterer mer avanserte behov enn no-code, men når ikke fullt ut frem til en helt fri løsning.
Hva er den vanligste overraskelsen med low-code?
Lisenskostnaden. Plattformer som OutSystems og Mendix tar løpende avgifter som ofte vokser med antall brukere eller apper, og de kan bli betydelige over tid. Mange fokuserer på den raske starten og overser at kostnaden fortsetter så lenge løsningen lever, i motsetning til tradisjonell kode som dere eier.
Hva bremser low-code-plattformer?
Avanserte integrasjoner mot andre systemer, en egen skreddersydd brukeropplevelse og ting som versjonskontroll og testing i større team. Så lenge dere holder dere innenfor det plattformen er laget for, går det raskt. Så snart dere vil utenfor rammene, blir det tungvint og noen ganger umulig, noe som kan tvinge frem en ombygging i vanlig kode.
Hvor alvorlig er risikoen for innlåsing?
Den er reell. En løsning bygget i en low-code-plattform er vanskelig å flytte derfra, og appen lever på plattformens premisser. Øker lisensprisen eller endres vilkårene, har dere begrenset handlingsrom fordi alternativet ofte er å bygge alt på nytt. Ta det med i vurderingen før dere låser dere, særlig for systemer dere har tenkt å beholde lenge.
Når er low-code riktig valg, og når er tradisjonell utvikling det?
Low-code passer for interne prosessapper, skjemaer og arbeidsflyter som må på plass raskt i en IT-avdeling. Tradisjonell utvikling passer for produkter med egen identitet, avanserte behov eller lang levetid, der eierskap og frihet veier tungt. Valget står mellom fart nå og kontroll over tid, og avhenger av hvor sentral løsningen er for virksomheten.