Low-code: genväg eller återvändsgränd?

Low-code väcker starka känslor. Förespråkarna ser en framtid där vem som helst bygger appar på en eftermiddag; skeptikerna ser en fälla som låser in dig i en plattform. Sanningen är att båda har rätt – fast om olika sorters projekt. Low-code är ett utmärkt verktyg för vissa behov och ett dåligt val för andra, och konsten ligger i att veta vilket som är vilket. Här är en saklig gränsdragning, fri från både hajp och fördömande.

Där low-code levererar snabbt och billigt

Low-code betyder plattformar där man bygger genom att konfigurera och dra-och-släppa snarare än att skriva all kod för hand. Styrkan är hastighet: en fungerande lösning kan stå klar på en bråkdel av tiden, ibland byggd av någon utan djup programmeringsbakgrund.

Det gör low-code idealiskt för avgränsade, interna behov där snabbhet väger tyngre än särprägel:

• Formulär och datainsamling – en ansökan, en anmälan, en enkät som ska ut snabbt.
• Interna godkännandeflöden – en begäran som ska genom några steg och godkännas av rätt person.
• Enkla register och verktyg – ett internt stöd som löser ett tydligt problem för en avdelning.

Gemensamt för dessa är att behovet är standardiserat och internt. Ingen kund ser lösningen, den behöver inte skala till miljontals användare, och den ska inte bära något unikt varumärke. Ju mer ett behov ser ut så, desto starkare talar det för low-code.

Väggarna man slår i

Problemen med low-code visar sig sällan i början. De kommer när lösningen ska växa eller sträcka sig bortom plattformens ramar, och då kan de vara dyra att upptäcka.

Den lömska gemensamma nämnaren är att alla fyra väggarna är osynliga i det lilla och akuta i det stora. En lösning som fungerar perfekt för femtio interna användare kan bli olönsam vid femtusen, omöjlig att koppla mot ett nytt affärssystem, eller närmast omöjlig att flytta ut om plattformen höjer priset eller läggs ner. Det är precis därför en affärskritisk kärnprodukt är riskabel att bygga i low-code: den är byggd för att växa, och det är i växten väggarna sitter.

En beslutsmodell som utgår från systemet

Frågan “low-code eller skräddarsytt” ska inte avgöras av teknikpreferenser, utan av två egenskaper hos systemet självt: hur länge det ska leva och hur affärskritiskt det är.

• Kort livslängd, låg kritikalitet – ett tillfälligt eller internt stödverktyg. Här är low-code oftast rätt: snabbt, billigt, och konsekvenserna av begränsningarna är små.
• Lång livslängd, hög kritikalitet – en kärnprodukt som ska bära verksamheten och särskilja er. Här motiverar skräddarsydd utveckling sin högre startkostnad, eftersom ni annars bygger er framtid på någon annans plattformsgränser.

De flesta system faller tydligt åt ett av hållen när man ställer de två frågorna. Osäkerheten uppstår i mitten, och där är en nyttig kontrollfråga: vad händer den dag vi slår i en av väggarna? Är svaret “då byter vi verktyg, det gör inget” är low-code tryggt. Är svaret “då står hela affären still” bör ni bygga för att hålla.

Ett scenario: rätt verktyg på rätt plats

Ett bolag byggde två saker samma år. Det interna verktyget för att hantera semesteransökningar byggdes i low-code och var klart på ett par veckor – helt rätt, för det var internt, avgränsat och okänsligt för plattformens gränser. Den kundvända produkten, som var själva affären och skulle skala, byggdes skräddarsytt trots den högre kostnaden.

När produkten några år senare växte kraftigt bar arkitekturen, medan ett tänkt low-code-bygge hade slagit i både pris- och prestandatak. Poängen är inte att det ena är bättre än det andra – utan att de löste var sitt problem, och att valet gjordes utifrån systemet, inte tekniken.

Står ni inför valet mellan low-code och skräddarsytt för ett visst system, hjälper vi på Weapp gärna till att göra bedömningen utifrån systemets livslängd och roll – hör av dig med en beskrivning av vad ni vill bygga.