Den vanligaste reaktionen vi möter i dag är inte skepsis mot AI, utan en rimlig fråga: om verktygen är så bra, varför bygger vi inte det här själva? Svaret är att ni förmodligen kan. Frågan är vad ni får sluta göra under tiden.
Prototypen är inte problemet
Att komma till något som fungerar på en laptop går fort nu. En utvecklare med Claude och en eftermiddag kommer längre än ett helt team gjorde för två år sedan. Den delen av arbetet har krympt så mycket att den knappt syns i en projektplan.
Det som inte har krympt är allt runt omkring: att bestämma vad som ska byggas, att komma åt systemen, att hantera det som går fel och att någon ska svara när det gör det klockan sju på morgonen.
Det som tar tid
Besluten. Vilket flöde ska vi börja med, vad räknas som klart, vem godkänner? Det tar möten, och de mötena går inte att prompta fram.
Integrationerna. Affärssystemet har en API-dokumentation från 2019, någon måste få fram ett testkonto och fältet som heter kundnummer betyder två olika saker i två system. Det är här veckorna går.
Gränsfallen. Det är enkelt att få rätt i åttio procent av fallen. De sista tjugo är arbetet, och det är också de som avgör om någon vågar använda lösningen.
Förvaltningen. Modeller ändras, API:er uppdateras, en integration slutar svara. Någon måste äga det, varje vecka, inte bara den månad projektet pågår.
Två rimliga vägar
Den ena är att bygga internt och räkna med att det tar kalendertid från annat. Då är vårt bästa råd att välja ett flöde, sätta ett slutdatum och vara ärliga med vad som stannar upp under tiden.
Den andra är att låta någon annan göra det första bygget och lämna över. Vi gör ofta det: bygger flödet, dokumenterar det och överlämnar koden och konfigurationen. Många kunder förvaltar sedan själva, vilket är precis som det ska vara.
Det ärliga svaret
Vi tjänar inte pengar på att ni inte kan bygga saker. Vi tjänar pengar på att ni slipper lägga ett kvartal på att komma dit ni ville från början. Är tiden inte ett problem är det helt rimligt att göra det själva, och då är det bästa vi kan bidra med ett samtal om var fallgroparna ligger.
Behöver ni gå snabbare än kalendern tillåter, titta på Discovery Sprint: två veckor, en plan, fast pris. Eller hör av er så pratar vi igenom vad som är rimligt att hinna till våren.
Räkna i kalendertid, inte i timmar
Den vanligaste felbedömningen är att räkna arbetstid i stället för kalendertid. Bygget tar kanske tre dagar. Att få testkontot tar två veckor, eftersom det ligger hos någon som har annat att göra, och den som ska godkänna ramarna är bortrest.
Vår erfarenhet är att kalendertiden mest beror på hur snabbt beslut fattas, inte på hur snabbt någon kodar. Det är den enda delen som inte har blivit snabbare av AI.
Vad ni bör behålla själva
Behåll ägandeskapet över reglerna. Vad agenten får göra, vad som kräver godkännande och vilka påståenden som aldrig får skickas till kund är verksamhetens beslut, inte leverantörens.
Behåll också kunskapen om varför flödet ser ut som det gör. Dokumentationen ska gå att läsa av någon som inte var med. Det är den enda försäkringen mot att vara beroende av en enskild person, vare sig den sitter hos oss eller hos er.
Tre frågor att ställa internt först
Vem äger flödet? Om svaret är ”flera” blir första veckorna möten, inte bygge. Utse en person som får bestämma hur det ska fungera.
Vad får vänta? Ett AI-projekt tar tid från något annat. Säg högt vad det är, annars blir det den löpande förvaltningen som får stryka på foten, och det märks först efter tre månader.
Vad gör vi om det fungerar? Den vanligaste överraskningen är inte att det misslyckas, utan att det fungerar och att ingen har bestämt vem som ska förvalta det. Bestäm det innan ni börjar.