Low-code: genvej eller blindgyde?
Low-code passer fremragende til afgrænsede interne flows, formularer og enklere værktøjer hvor hastighed vejer tungere end særpræg. For kerneprodukter med krav til skala, performance eller et eget udtryk bliver det ofte en blindgyde, hvor licenser og begrænsninger før eller siden indhenter en. Beslutningsmodellen tager udgangspunkt i systemets levetid og hvor forretningskritisk det er, ikke i teknikken i sig selv.
Low-code vækker stærke følelser. Fortalerne ser en fremtid hvor hvem som helst bygger apps på en eftermiddag; skeptikerne ser en fælde der låser dig fast i en platform. Sandheden er at begge har ret, bare om forskellige slags projekter. Low-code er et fremragende værktøj til nogle behov og et dårligt valg til andre, og kunsten er at vide hvilket der er hvilket. Her er en saglig grænsedragning, fri for både hype og fordømmelse.
Hvor low-code leverer hurtigt og billigt
Low-code betyder platforme hvor man bygger ved at konfigurere og bruge træk og slip frem for at skrive al koden i hånden. Styrken er hastighed: En fungerende løsning kan stå klar på en brøkdel af tiden, nogle gange bygget af en person uden dyb programmeringsbaggrund.
Det gør low-code ideelt til afgrænsede, interne behov hvor hastighed vejer tungere end særpræg:
- Formularer og dataindsamling. En ansøgning, en tilmelding, et spørgeskema der hurtigt skal ud.
- Interne godkendelsesflows. En anmodning der skal igennem nogle trin og godkendes af den rette person.
- Enkle registre og værktøjer. Et internt hjælpeværktøj der løser et klart problem for en afdeling.
Fælles for dem er at behovet er standardiseret og internt. Ingen kunde ser løsningen, den behøver ikke at skalere til millioner af brugere, og den skal ikke bære et unikt brand. Jo mere et behov ligner det, desto stærkere taler det for low-code.
Murene man rammer
Problemerne med low-code viser sig sjældent i starten. De kommer når løsningen skal vokse eller strække sig ud over platformens rammer, og så kan de være dyre at opdage.
| Mur | Hvornår den mærkes |
|---|---|
| Licensomkostninger | Når brugerne bliver mange (prisen kan løbe løbsk med volumen) |
| Performanceloft | Når datamængde eller belastning vokser ud over hvad platformen kan klare |
| Integrationer | Når løsningen skal tale med systemer som platformen ikke understøtter godt |
| Fastlåsning og exit | Når I vil forlade platformen (løsningen er svær at flytte ud) |
Den lumske fællesnævner er at alle fire mure er usynlige i det små og akutte i det store. En løsning der fungerer perfekt for halvtreds interne brugere, kan blive urentabel ved fem tusind, umulig at koble til et nyt ERP-system eller nærmest umulig at flytte ud hvis platformen hæver prisen eller lukkes ned. Det er netop derfor et forretningskritisk kerneprodukt er risikabelt at bygge i low-code: Det er bygget til at vokse, og det er i væksten at murene står.
En beslutningsmodel der tager udgangspunkt i systemet
Spørgsmålet “low-code eller skræddersyet” skal ikke afgøres af tekniske præferencer, men af to egenskaber ved selve systemet: hvor længe det skal leve og hvor forretningskritisk det er.
- Kort levetid, lav kritikalitet. Et midlertidigt eller internt hjælpeværktøj. Her er low-code som regel det rigtige: hurtigt, billigt, og konsekvenserne af begrænsningerne er små.
- Lang levetid, høj kritikalitet. Et kerneprodukt der skal bære forretningen og differentiere jer. Her retfærdiggør skræddersyet udvikling sin højere startomkostning fordi I ellers bygger jeres fremtid på en andens platformsgrænser.
De fleste systemer falder tydeligt ud til den ene side når man stiller de to spørgsmål. Usikkerheden opstår i midten, og her er et nyttigt kontrolspørgsmål: Hvad sker der den dag vi rammer en af murene? Er svaret “så skifter vi værktøj, det gør ikke noget”, er low-code trygt. Er svaret “så står hele forretningen stille”, bør I bygge noget der holder.
Et scenarie: det rigtige værktøj på det rigtige sted
En virksomhed byggede to ting samme år. Det interne værktøj til at håndtere ferieansøgninger blev bygget i low-code og var klar på et par uger, og det var helt rigtigt, for det var internt, afgrænset og upåvirket af platformens grænser. Det kundevendte produkt, som var selve forretningen og skulle skalere, blev skræddersyet trods den højere omkostning.
Da produktet nogle år senere voksede kraftigt, holdt arkitekturen. En hypotetisk low-code-løsning ville derimod have ramt både pris- og performanceloftet. Pointen er ikke at det ene er bedre end det andet, men at de løste hvert sit problem og at valget blev truffet ud fra systemet, ikke teknikken.
Står I over for valget mellem low-code og skræddersyet udvikling til et bestemt system, hjælper vi hos Weapp gerne med at foretage vurderingen ud fra systemets levetid og rolle. Kontakt os med en beskrivelse af hvad I vil bygge.
Ofte stillede spørgsmål
Hvad er low-code, kort fortalt?
Low-code er platforme hvor man i vid udstrækning bygger applikationer ved at konfigurere og bruge træk og slip i stedet for at skrive al koden i hånden. Det betyder at løsninger kan udvikles hurtigt og nogle gange af personer uden dyb programmeringsbaggrund. Prisen er at man arbejder inden for platformens rammer: Det som platformen ikke understøtter, bliver svært eller umuligt at bygge.
Hvornår passer low-code bedst?
Til afgrænsede, interne behov hvor hastighed er vigtigere end særpræg: en formular, et godkendelsesflow, et enkelt internt register eller et værktøj der skal løse et klart problem for en afdeling. Her leverer low-code hurtigt og billigt. Jo mere standardiseret og internt behovet er, desto stærkere taler det for low-code frem for skræddersyet udvikling.
Hvilke mure rammer man med low-code?
Fire er de mest almindelige: licensomkostninger der vokser med antallet af brugere, et performanceloft når volumen bliver stor, integrationer til andre systemer som platformen ikke understøtter godt, og vanskeligheder med at flytte løsningen ud hvis man vil forlade platformen. De mærkes sjældent i starten, men først når løsningen skal vokse, og det er netop derfor kerneprodukter er risikable at bygge i low-code.
Hvordan vælger vi mellem low-code og skræddersyet udvikling?
Tag udgangspunkt i systemets levetid og hvor forretningskritisk det er, ikke i teknikken. Et kortlivet, internt hjælpeværktøj passer til low-code. Et langlivet, forretningskritisk kerneprodukt der skal differentiere jer, retfærdiggør skræddersyet udvikling trods en højere startomkostning. Spørg jer selv hvor systemet ligger på de to skalaer. Svaret peger som regel tydeligt i den ene retning.