Vi börjar nästan aldrig med att säga att en kund behöver custom development.
Vi börjar med att lyssna på hur de beskriver sina system. Vad de säger – och vad de inte säger. Det finns en specifik formulering vi hör återkommande: "Det fungerar, men vi har en del manuella steg runt om." Den meningen är oftast ett tecken på att systemet har nått sin gräns – och att verksamheten har lärt sig att leva med det.
Det är en kompromiss. Och kompromisser har en tendens att bli osynliga kostnader med tiden.
Standardplattformar är inte problemet
Vi jobbar med standardplattformar varje dag. Optimizely, Microsoft-stacken, etablerade ramverk. De är välbeprövade, väldokumenterade och rätt val i en stor mängd situationer.
Men en standardplattform är designad för ett genomsnitt. Den är byggd för att passa många verksamheter tillräckligt bra – och det syns i hur funktionerna faktiskt används. Standish Groups forskning visar att 64 procent av funktionerna i ett genomsnittligt enterprise-system används sällan eller aldrig. Det är inte ett argument mot standardplattformar. Det är ett argument för att förstå vad man faktiskt köper.
Problemet uppstår inte när man väljer en standardplattform. Det uppstår när man sedan börjar forma verksamheten efter plattformens begränsningar, istället för tvärtom. När den interna processen modifieras för att passa systemet. När affärslogiken kompromissas för att undvika en kostsam avvikelse från standardflödet.
Det är det skedet vi försöker identifiera tidigt.
Tre frågor vi alltid ställer
När vi möter ett nytt projekt ställer vi tre frågor som sällan finns i en kravspec:
Vad händer i undantagen? De flesta system klarar normalflödet. Det är i undantagen – de tio procenten av fallen som inte passar mallen – som den verkliga affärslogiken bor. Om de hanteras manuellt, utanför systemet eller med workarounds, speglar arkitekturen inte verkligheten.
Vem äger systemet om två år? Tekniska beslut har lång livslängd. En lösning som är smidig att leverera idag men som skapar beroenden eller tungrodd förvaltning om arton månader är inte en bra lösning. Vi frågar alltid vem som ska äga och vidareutveckla det vi bygger.
Vad är det egentliga målet? Det låter självklart. Det är det inte. Specen beskriver vad kunden tror att de behöver. Det faktiska målet – det affärsmässiga resultatet som ska uppnås – är ofta formulerat i ett annat dokument, i ett annat rum. Att hitta det är en del av jobbet.
Den dolda kostnaden för "nära nog"
Det finns en term för det som händer när verksamheten anpassar sig runt ett system som inte riktigt passar: workaround-skatten. Data exporteras manuellt. Steg dupliceras mellan system. Kollegor utvecklar egna rutiner för att kompensera för vad plattformen inte klarar.
MuleSofts Connectivity Benchmark 2025 sätter siffror på det: genomsnittsföretaget kör 897 applikationer, men bara 29 procent av dem är integrerade. Det är inte ett tekniskt problem. Det är ett arkitekturproblem – och det kostar i form av tid, fel och beslut som fattas på fel underlag.
Om vi inte tror på en lösning, säger vi det
Vi tackar nej till uppdrag. Inte ofta, men det händer. När vi bedömer att en standardlösning faktiskt räcker – och att ett custom-projekt skulle vara dyrare och mer komplext utan ett proportionellt bättre utfall – säger vi det.
Det är inte självuppoffrande. Det är långsiktigt.
Förtroendet vi behöver för att arbeta med komplexa, verksamhetskritiska system byggs inte på att vi alltid säljer mer. Det byggs på att kunden vet att vår bedömning är äkta.
Vad det innebär i praktiken
Vi är inte ett bolag som levererar timmar mot en backlog. Vi är ett team med teknisk tyngd och affärsnärhet nog att hålla ihop hela kedjan – från arkitekturbeslut till produktionssättning till förvaltning.
Det betyder att vi kan ta ansvar. Inte bara för delarna vi levererar, utan för att helheten fungerar.
Vilken process är det i er verksamhet som systemet inte riktigt klarar av?
Den frågan är en bra startpunkt.
Dela gärna detta på
