Välj utvecklingspartner på belägg, inte på säljpresentationen. Prata med utvecklarna som ska skriva er kod, fråga hur de hanterade projekt som gick snett, titta på hur de avgränsar arbetet och pröva dem på en liten del riktigt arbete med skriftliga acceptanskriterier innan ni binder er för ett stort projekt. För svenska beställare är avtalet lika viktigt som teamet: vem ni skriver avtal med, enligt vilken lag, hur personuppgifter skyddas och vem som äger koden. Vi ser det här från båda hållen. Vi är själva leverantör, och i vårt arbete med modernisering och räddning av AI-byggda appar tar vi över kod som andra team har skrivit. Det här är checklistan vi själva skulle använda.
Vem ska ni prata med innan ni skriver på?
Den största varningssignalen är en leverantör som placerar säljare mellan er och utvecklarna. Om era tre första möten är med kundansvariga och projektledare men aldrig med en utvecklare, fråga varför. Utvecklare ger ärliga bedömningar av genomförbarhet, tidplan och teknisk risk. Säljare säger det ni vill höra. En bra partner låter er prata direkt med dem som ska skriva er kod, också med den seniora utvecklare som ansvarar för arkitekturen.
Hur hanterade de projekt som gick snett?
Alla erfarna team har projekt som inte gick enligt plan. Fråga om dem. Hur hanterade de att omfattningen växte? Vad hände när en nyckelperson slutade mitt i projektet? Hur kom de ikapp efter en missad deadline? En partner som öppet kan berätta om misslyckanden, och om vad de ändrade efteråt, är mer pålitlig än en som påstår sig ha en felfri historik.
Hur avgränsar de arbetet?
Var försiktiga med ett fast pris efter ett enda samtal. Antingen är uppskattningen kraftigt tilltagen, eller så kommer ändringsbeställningarna senare. En bra partner lägger tid på att förstå er verksamhet innan de föreslår en lösning: de frågar om era användare, era begränsningar och vad ni menar med framgång, och de ifrågasätter krav som inte håller. En förstudie kostar en bråkdel av projektet och är det billigaste stället att upptäcka att omfattningen är fel.
Är teamet stabilt?
Personalomsättning är det som tyst sänker många outsourcade projekt. Varje gång någon roteras bort från ert projekt försvinner veckor av sammanhang. Fråga hur länge utvecklarna har varit kvar, vad som händer om er huvudutvecklare slutar, vem mer som känner till kodbasen och om dokumentation är en del av arbetet eller något som görs i efterhand.
Vad sätter de själva på spel?
Bra partner delar en del av risken. Det kan vara en första sprint med skriftliga acceptanskriterier som ni kan kliva av efter, en garantiperiod på levererat arbete eller helt enkelt att de rättar sina egna buggar utan extra kostnad. Vår variant är en garanti för första sprinten: innan vi börjar kommer vi skriftligt överens om vad den första sprinten på två veckor ska leverera. Om demon efter sprint 1 inte uppfyller acceptanskriterierna kan ni avbryta, och ni betalar inte för den sprinten. Om en leverantör inte erbjuder något liknande, fråga er varför.
Hur djup är deras tekniska kompetens?
Ställ tekniska frågor under utvärderingen. Hur testar de? Hur kör de databasmigreringar i produktion? Hur hanterar de säkerhet och uppdateringar av beroenden? Hur håller de nere den tekniska skulden? Ni behöver inte vara utvecklare för att bedöma svaren. Ni lyssnar efter konkreta besked. “Vi följer best practice” är en varningssignal; bra utvecklare tycker om att prata om sitt hantverk och ger detaljerade svar med tydliga åsikter.
Vad ska svenska beställare kontrollera i avtalet?
Använd checklistan för alla leverantörer, oavsett var utvecklarna sitter.
| Kontroll | Det ni ska be om | Varningssignal |
|---|---|---|
| Avtalspart och lag | Vem ni skriver avtal med, enligt vilken lag och var tvister avgörs. För en svensk beställare är ett svenskt bolag och svensk lag det enklaste. | Avtal med ett utländskt bolag enligt utländsk lag, eller med en mellanhand som inte gör jobbet |
| Vem som faktiskt skriver koden | Namn, senioritet och arbetsort för utvecklarna, och den seniora person som ansvarar för arkitektur och kodkvalitet. Träffa dem innan ni skriver på. | ”Teamet tillsätts efter avtalet”, eller underleverantörer som inte redovisas |
| Personuppgifter (GDPR) | Ett personuppgiftsbiträdesavtal (PUB-avtal) innan någon rör personuppgifter. Sitter utvecklarna utanför EU/EES ska den rättsliga grunden för överföringen anges, oftast EU:s standardavtalsklausuler (SCC), tillsammans med en lista över underbiträden. | Åtkomst till produktion “bara för felsökning” utan PUB-avtal, eller inget tydligt svar om var utvecklarna finns |
| Acceptanskriterier | Skriftliga acceptanskriterier för första sprinten eller delleveransen och hur de kontrolleras på demon, med betalningar kopplade till godkända leveranser. | Betalningar kopplade bara till datum eller timmar, utan definition av klart |
| Äganderätt till koden | Att immateriella rättigheter övergår till er vid betalning, skrivet i avtalet; koden i ett kodförråd ni kommer åt från första dagen; infrastrukturen i ert eget molnkonto. | Koden i leverantörens kodförråd, licens i stället för äganderätt, eller drift bara i leverantörens konto |
| Kontinuitet och avslut | En andra utvecklare som känner kodbasen, dokumentation som en del av arbetet, en tydlig uppsägningstid och full överlämning av kodförråd, inloggningar och dokumentation när uppdraget tar slut. | Lång inlåsning, eller att allt hänger på en person |
Hur svarar vi själva på checklistan?
Ni skriver avtal med Smoother Development AB, ett svenskt aktiebolag, enligt svensk lag. Vårt utvecklingsteam arbetar från Ukraina; varje team har en senior utvecklare som ansvarar för arkitektur och kodkvalitet, och en grundare ansvarar för varje projekt. Ukraina ligger utanför EU/EES, så innan någon i teamet rör personuppgifter skriver vi ett personuppgiftsbiträdesavtal med EU:s standardavtalsklausuler, och vi driftar i EU-regioner som standard. Ni äger koden när den är betald. Detaljerna finns på sidan om säkerhet och dataskydd, och hur det är att arbeta med utvecklare i olika regioner jämför vi i nearshore eller offshore.
Vad ni kan göra härnäst
Oavsett vem ni väljer, börja litet: en kodgenomlysning, en förstudie eller en första sprint med skriftliga acceptanskriterier säger mer än någon säljpresentation. Våra priser är publicerade, från utvecklare per timme till team och projekt till fast pris, på vår prissida, och vår genomgång av vad systemutveckling kostar hjälper er att jämföra offerter.
