Skal et laboratorium selv bygge sit LIMS, eller købe et?

En laboratorieejer beslutter at bygge laboratoriets prøvesystem selv, med et AI-kodningsværktøj til at gå hurtigere end at ansætte en udvikler ville. Før det kan køre en eneste prøve, skal nogen stadig skrive ned, hvad laboratoriet reelt har brug for: hvilke prøvetyper, hvilke analyser, hvordan chain of custody skal holde til akkreditering, hvordan fakturering skal følge af et godkendt resultat. Det specifikationsarbejde, og den bygning og test, der følger efter, er reel tid, brugt af de mennesker, der ellers ville køre prøver eller tale med kunder.

Hvad kræver det reelt at bygge et LIMS selv?

Et AI-kodningsværktøj kan skrive kode hurtigt, men det kan ikke deltage i samtalen om, hvad laboratoriets akkrediteringsorgan forventer af en chain of custody-journal, eller beslutte, hvordan en faktura skal udløses. Nogen i laboratoriets eget team skal stadig finde ud af det, bygge det, teste det mod reelle prøveflows og rette det, der går i stykker, før noget af det er klar til at køre en eneste prøve. Intet af det sker ved siden af. Det sker i stedet for det arbejde, laboratoriet reelt er der for at udføre.

Hvor begynder en selvbygget løsning at koste mere, end den sparer?

Det samme punkt, der får et regneark til at stoppe med at fungere for et voksende laboratorium, gælder også her: når et laboratorium håndterer omkring 500 prøver om måneden, begynder manuel afstemning, uanset om det sker i et regneark eller i et hjemmelavet system, at koste mere tid, end det sparer. Et par spørgsmål plejer at afsløre det før det punkt nås. Hvad sker der, når to teknikere arbejder i systemet samtidig, og den ene overskriver den andens indtastning? Hvad sker der mandagen efter en travl feltweekend, når bunken allerede ligger i systemet, før nogen har set på den? Og når en akkrediteringsrevisor beder om en chain of custody-journal bygget i et værktøj, kun en person forstår, hvem svarer så, hvis den person er på ferie, eller er stoppet?

Hvad kræver en selvbygget løsning stadig, under AI'en?

Et AI-kodningsværktøj fjerner behovet for at ansætte en udvikler. Det fjerner ikke behovet for at specificere, teste, sikre og holde det, der bliver bygget, kørende, eller den tid, det tager fra de mennesker, der gør det ved siden af deres almindelige arbejde. Veracodes analyse fra 2025 af AI-genereret kode fandt, at tæt på halvdelen af den indeholdt en sikkerhedsfejl, og Stack Overflows udvikler-undersøgelse fra 2025, med svar fra mere end 49.000 udviklere, fandt, at 66 procent kalder AI-output, der er 'næsten rigtigt, men ikke helt', deres største frustration ved værktøjerne. Til et internt udkast er næsten rigtigt ofte godt nok. Til en journal, en revisor kan bede om at se et år senere, er det ikke.

At håndtere kundeprøver og akkrediteringsjournaler trækker også de dele af at drive software ind, som AI ikke rører ved: hosting, backup, adgangsstyring, og i mange tilfælde en formel certificering som ISO 27001, der typisk tager tre til tolv måneder første gang og derefter et årligt tilsyn for at beholde. En undersøgelse fra 2026 blandt mere end 800 virksomheders softwarebyggere, lavet af Retool, fandt, at over en tredjedel allerede havde erstattet et SaaS-værktøj med noget bygget internt, mens sikkerheds- og compliance-bekymringer samt løbende vedligeholdelse blev nævnt blandt de største grunde til, at de projekter går i stå, før de når produktion. Som rapporten selv udtrykker det: tid sparet på at bygge noget kan blive opvejet af tid tabt på at vedligeholde det.

Hvad får et laboratorium fra et formålsbygget system, som en selvbygget løsning ikke giver?

Et kommercielt testlaboratoriums reelle krav rækker langt ud over at holde styr på prøver. Analytikere har brug for overblik over arbejdsbyrden og struktureret indtastning af resultater, afvigelser skal markeres og løses uden at forlade systemet, og rapporter skal se ud, som hver kunde forventer. Kundekonti skal have deres egen prisaftale, uanset om det er en erhvervskunde, en privatkunde eller en forsikringssag, og fakturaer skal følge automatisk, når et resultat er godkendt. Milva Labs kommercielle LIMS er bygget som ét system, der dækker hele den liste: den kommercielle side af at drive laboratoriet og de interne laboratorieprocesser sammen, med sin egen kundeapp indbygget.

• Overblik over arbejdsbyrde og struktureret resultatindtastning for hver analyse, ikke kun en prøvestatus
• Afvigelser markeres og løses uden at forlade systemet
• Kundespecifikke rapportskabeloner, bygget ud fra laboratoriets egne data
• Kundekonti med deres egen prisaftale, til erhvervs-, privat- og forsikringskunder
• Chain of custody bygget, mens prøven bevæger sig, ikke rekonstrueret til en revision
• Et system hele teamet kan vedligeholde, ikke kun den, der byggede det

Valget handler ikke rigtig om, hvorvidt et AI-værktøj kan skrive fungerende kode. Det kan det godt. Valget er, om de mennesker, der driver laboratoriet, skal bruge det næste år på at specificere, bygge og vedligeholde software, eller bruge det på at køre prøver og udvide kundelisten. For de fleste laboratorier, der vejer den afvejning, viser det sig, at det ligetil svar er at købe det af en virksomhed, hvis eneste opgave er at bygge LIMS-software. Vores gratis kommercielle tjek er en to-minutters måde at se, hvor manuelt arbejde, selvbygget eller ej, allerede koster laboratoriet tid.