Teknisk gæld, gjort synlig og målbar.
Så modernisering, oprydning eller at lade stå bliver en oplyst beslutning — ikke et dyrt gæt.
En fokuseret måling af, hvad der faktisk bruges — eller en samlet indsats for hele kodebasens sundhed.
Runtime dødkode-analyse
Vi måler, hvilken kode der faktisk kører i produktion — så I ved præcist, hvad der trygt kan fjernes.
Modernisering & kodesundhed
En sammenhængende indsats for hele kodebasen — ydelser, pakker, effekt og metode samlet ét sted.
Find den kode, I aldrig bruger — med bevis fra jeres kørende produktion.
De fleste kan se, hvordan koden ser ud. Vi viser, hvad den faktisk gør — hvilke dele der kører i produktion, og hvilke der aldrig bliver kaldt. Så bliver oprydning og modernisering en beslutning på bevis.
Kode lever i en verden, der hele tiden forandrer sig
Software bygges til virkeligheden, som den ser ud lige nu. Men den verden står aldrig stille: forretningen skifter retning, kunderne ændrer adfærd, regler og krav bliver nye, features udfases, integrationer forsvinder, og systemer omkring jeres bliver skiftet ud. Hver eneste af de forandringer kan efterlade kode, der stille holder op med at blive brugt — uden at nogen sletter den.
Koden ser stadig rigtig ud; den bliver bare aldrig kaldt længere. Og fordi årsagen ligger uden for koden — i en verden, der har bevæget sig — kan man ikke finde svaret inde i koden. Man kan kun se det ved at måle, hvad der faktisk kører.
Præanalyse
Vi kortlægger systemet: størrelsen, arkitekturen, den kode der skal holdes uden for analysen (fx nyudvikling, der endnu ikke bruges af kunder), den statiske del og eventuelle særtilfælde — som særlige biblioteker, der kræver særlig håndtering. Det er præanalysen, der gør resten estimerbar.
Analyseomfang estimeres i præanalysen
Vi tilpasser værktøjet til jeres kodebase og kører en let måling inde i jeres kørende produktion. Den registrerer kun, hvilken kode der bliver kaldt — aldrig jeres data eller forretningsindhold — og løber i baggrunden med minimal påvirkning af driften. Det aktive arbejde ligger i tilpasningen, løbende validering af klassificeringen og slutanalysen af, hvad der er dødt, og hvad der er brugt vedligehold på.
Oprydningplanlægges efter analysen
Vi starter med det mest sikre, i små trin der kan rulles tilbage, og gør jeres eget team i stand til selv at fortsætte, så ubrugt kode ikke vokser tilbage. Fordi fjernelse typisk skal forbi ledelsen og på roadmappet, er forankring i teamet en del af arbejdet.
På en større .NET-løsning i normal drift viste analysen:
Færre linjer at forstå, teste og patche — og færre steder, fejl kan gemme sig.
Mindre kode betyder mindre, der kan gå galt, og mindre at stå til regnskab for over for revision.
I moderniserer og tester kun det, I faktisk bruger — ikke kode, ingen længere kalder.
Budgettet går til den kode, der understøtter forretningen, frem for til kode ingen bruger.
Gør systemet billigere og mindre risikabelt at ændre.
Vi går fra symptom til årsag til den mindste indsats, der skaber målbar effekt — så modernisering styres af behov og bevis, ikke af antagelser.
Hvad mærker I?
Ændringer tager for lang tid, releases er usikre, driften fejler, eller I er afhængige af enkelte nøglepersoner.
Hvad viser data?
Vi finder årsagen i data — hvor koden er tungest at ændre, hvad der faktisk bliver brugt, og hvor risikoen samler sig.
Hvad starter I med?
Den mindste, mest afgrænsede indsats, der fjerner usikkerhed — et gennemgang, en analyse eller en pilot, før noget større.
Hver ydelse nedenfor viser hvornår den passer, hvad vi gør, den konkrete leverance og de KPI'er, effekten kan måles på.
Tre niveauer — fra at forstå til at forbedre
Hvert område kan købes i tre niveauer. Start så småt som muligt, og gå kun videre, når resultatet og forretningscasen berettiger det.
Forstå og afgræns
Kort analyse eller workshop. Vi bekræfter problemet, måler udgangspunktet og giver jer et grundlag at beslutte ud fra.
Bevis effekten
Afgrænset forløb på ét område. Vi gennemfører forbedringen og dokumenterer resultatet før og efter.
Skalér og forankr
Længere forløb. Vi ruller forbedringen ud og gør den til en fast del af jeres måde at arbejde på.
Clean Architecture
Når ændringer spreder sig på tværs af systemet, og arkitekturen gør test og modernisering unødigt dyr.
Clean Code & Refaktorering
Når systemet virker, men hver ændring er langsom, usikker eller afhængig af enkelte personer.
.NET-modernisering
Når gamle runtimes, frameworks eller afhængigheder begrænser support, sikkerhed, performance og rekruttering.
REST / Backend
Når API'er og integrationer er svære at ændre, uens opbygget eller ustabile under belastning.
Test & Quality
Når manglende tillid til tests gør releases langsomme og refaktorering farlig.
Developer Experience & Delivery Flow
Når udviklere spilder tid på ventetid, builds, lokale miljøer og manuelle releases.
Security, livscyklus & forsyningskæde
Når teknisk gæld også er sikkerheds- og compliance-gæld — gamle platforme og uklart ejerskab af komponenter.
Overvågning & driftsgæld
Når fejl er dyre at diagnosticere, og driften kompenserer for manglende indsigt med manuel viden.
Hvert område kan leveres i de tre niveauer ovenfor — fra en kort analyse til et fuldt forløb. Vi går i dybden med det, der er relevant for jer, i dialogen.
Afgrænsede leverancer med et klart resultat.
Konkrete, købbare forløb frem for åbne konsulenttimer. Hver pakke starter med et problem, arbejder mod et målbart resultat og ender med en klar beslutning: stop, fortsæt eller invester videre.
Afgrænsede leverancer med et klart resultat. Start med den mindste pakke, der fjerner jeres vigtigste usikkerhed — mål effekten, og skalér først, når beviset er der.
Engineering Health Check
Et hurtigt, tværgående sundhedstjek af kodebase, arkitektur og leveringsflow.
Teknisk gæld: udgangsmåling & business case
En ledelsesegnet kortlægning, hvor teknisk gæld kobles til kapacitet, risiko og økonomi.
Legacy-refaktoreringssprint
Et afgrænset, praktisk forløb på ét konkret brændpunkt i koden.
.NET-moderniseringsanalyse
En teknisk og forretningsmæssig vurdering af moderniseringsbehovet.
Clean Architecture-workshop
En faciliteret workshop, hvor nøglepersoner skaber et fælles billede af arkitektur og retning.
Embedded senior-konsulent
Et længere hands-on engagement inde i jeres team — både levering og opbygning af teamets egen evne.
For jer, der vil have et samlet forløb frem for en enkelt pakke. Begge følger samme princip: mål udgangspunktet, prioritér, implementér, mål effekten — og beslut det næste skridt.
30-dages forbedringsforløb
Fra diagnose til 1–2 dokumenterede forbedringer på én måned — velegnet som pilot før et større program.
90-dages moderniseringsforløb
Et sammenhængende forløb, der flytter et system eller team mærkbart på tre måneder.
Vi beviser effekten på jeres egne tal.
Før og efter, målt på jeres egne data — ikke på lånte benchmarks. Så I kan se, hvad indsatsen reelt flyttede.
Målet er ikke flest mulige målinger — men få, troværdige tal, der besvarer tre spørgsmål: Var problemet reelt? Gjorde indsatsen en forskel? Er næste skridt berettiget?
Vi måler få, troværdige tal — på jeres egne data
Vi vælger målingerne ud fra jeres konkrete problem, ikke ud fra hvad et værktøj kan tælle. Typisk 1–3 hovedtal per indsats, med en kendt datakilde og en aftalt måleperiode fra start.
Afhængigt af problemet kan det være leveringshastighed, stabilitet, kodesundhed eller reelt kodeforbrug. Vi fastlægger altid udgangspunktet, før vi ændrer noget — så effekten kan bevises, ikke påstås.
Hver forbedring dokumenteres som et lille eksperiment: hvad var hypotesen, hvad ændrede vi, hvad var konstant, og hvad ændrede målingen sig til. I får en rapport i dette format, udfyldt med jeres egne tal.
Sådan ser rapporten ud — udfyldt med jeres egne målinger
| KPI | Udgangsmåling | Efter | Forbedring |
|---|---|---|---|
| Lead time for change | — | — | — |
| Andel releases der fejler | — | — | — |
| Genarbejde | — | — | — |
| Kritiske brændpunkter | — | — | — |
Rapportering skal føre til prioritering — ikke blive endnu et dashboard. Derfor har hver rytme ét fast publikum og ét beslutningsspørgsmål.
Månedligt
En kort statusrapport til ledelsen: skal fokus eller ressourcer justeres?
Kvartalsvist
Til ledelse og forretning: hvilke gældsinvesteringer skal finansieres næste kvartal?
Ved hver fase
Til beslutningstagerne: stop, fortsæt, justér eller skalér — på et målt grundlag?
Sådan arbejder vi — og derfor holder ændringerne.
Små, kontrollerede forbedringer med målbar effekt, forankret hos jeres eget team, så gælden ikke bare vokser tilbage.
Det centrale princip er progressiv commitment: kunden investerer mere, efterhånden som evidensen bliver stærkere og usikkerheden mindre.
En omskrivning kan være den rigtige beslutning, men det skal være resultatet af evidens — ikke standardreaktionen på en vanskelig kodebase. Vi foretrækker inkrementel modernisering, hvor eksisterende forretningslogik, integrationsviden og fungerende adfærd bevares, mens de områder der reelt begrænser forretningen forbedres.
Sådan arbejder vi i praksis
- Kortlægger brændpunkts, afhængigheder, livscyklus-risici og change patterns før løsningsvalg.
- Skelner mellem kode der er gammel, og kode der faktisk er dyr eller risikabel at ændre.
- Bruger strangler-, modulariserings- eller migrationsmønstre når de reducerer risiko.
- Bevarer reversibilitet og tilbagerulning-muligheder i de tidlige faser.
Kunden kan forvente
- En begrundet anbefaling om hvad der bør bevares, forbedres, isoleres eller erstattes.
- Synlige afvejninger mellem omskrivning, refaktorering, migrering og bevidst at bevare den nuværende løsning.
- Faseopdeling med stop/go frem for én stor irreversibel investering.
- At forretningskontinuitet vægtes lige så højt som teknisk elegance.
Hvordan det dokumenteres
- Brændpunkt- og afhængigheds-map.
- arkitekturbeslutninger med alternativer og trade-offs.
- Migration waves / incremental køreplan.
- Risiko-, effort- og impact-vurdering pr. kandidat.
Uhensigtsmæssige mønstre vi undgår
- “Alt er legacy, så vi starter forfra”.
- Platformskifte uden konkret business driver.
- Rewrite uden nye fejl udgangsmåling eller migrationsstrategi.
- At erstatte kendt teknisk gæld med ukendt ny kompleksitet.
Teknisk gæld reduceres mest robust gennem små ændringer med klart scope, kort feedback-loop og kendte tilbagerulning-muligheder. Det reducerer både teknisk risiko og den kommercielle risiko for kunden.
Sådan arbejder vi i praksis
- Afgrænser forbedringen til et modul, flow, afhængigheds-set eller konkret bottleneck.
- Arbejder i små batches med tests, gennemgangs og hyppig integration.
- Synliggør fremdrift, blockers, risici og læring undervejs.
- Stopper eller ændrer retning, hvis evidensen ikke understøtter hypotesen.
Kunden kan forvente
- Tydeligt scope og eksplicit out-of-scope.
- Korte checkpoints frem for overraskelser ved afslutning.
- Mulighed for at validere værdi før næste investering.
- Ændringer der kan forklares, testes og overdrages.
Hvordan det dokumenteres
- Iteration-/sprintmål.
- Change log og beslutningslog.
- Risiko- og blocker-status.
- Før/efter KPI'er for det afgrænsede område.
Uhensigtsmæssige mønstre vi undgår
- Store PR'er og langlivede branches.
- Flere samtidige refaktoreringer uden fælles prioritering.
- “Vi er 80 % færdige” uden et målbart resultat.
- Scope creep uden ny beslutning om tid, effekt og risiko.
Vi behandler arkitektur- og moderniseringsvalg som investeringsbeslutninger. Et teknisk valg er først stærkt, når alternativer, begrænsninger, konsekvenser og forventet resultat er synlige for både engineering og beslutningstagere.
Sådan arbejder vi i praksis
- Dokumenterer større valg som arkitekturbeslutninger eller beslutningsnotater.
- Beskriver mindst ét realistisk alternativ og konsekvensen ved at gøre ingenting.
- Knytter valget til målbare mål eller risikoreduktion.
- Angiver hvilke antagelser der skal valideres senere.
Kunden kan forvente
- Ingen “best practice” uden kontekst.
- Klar forklaring af cost, benefit, constraints og reversibilitet.
- Beslutninger der kan genbesøges, når forudsætninger ændres.
- Fælles sprog mellem udvikling, arkitektur og ledelse.
Hvordan det dokumenteres
- ADR / decision record.
- Alternativ- og trade-off matrix.
- Assumption log.
- Beslutningspunkt med ejer og dato.
Uhensigtsmæssige mønstre vi undgår
- Teknologivalg fordi noget er nyt eller populært.
- Beslutninger uden ejer eller beslutningsdato.
- Arkitekturdiagrammer uden rationale.
- At skjule usikkerhed bag præcise estimater.
Ikke al teknisk gæld skal betales. Vi prioriterer gæld, der påvirker time-to-market, stabilitet, sikkerhed, driftsomkostning, compliance eller evnen til at gennemføre strategiske initiativer.
Sådan arbejder vi i praksis
- Kombinerer tekniske signaler med ændringsfrekvens, driftshændelser, genarbejde og køreplan-behov.
- Skelner mellem lokal kodekvalitet og systemisk forretningsfriktion.
- Prioriterer områder med både stor påvirkning og høj sandsynlighed for forbedring.
- Accepterer bevidst gæld, hvor afhjælpning ikke kan forsvares økonomisk.
Kunden kan forvente
- En prioriteret gældsportefølje — ikke en lang liste af kodeproblemer.
- Forklaring af hvorfor nogle problemer bør løses nu og andre senere.
- Kobling til køreplan, risiko og kapacitet.
- En anbefalet investeringsrækkefølge.
Hvordan det dokumenteres
- Technical Debt Map.
- Impact × risk × effort prioritering.
- Cost-of-delay- og genarbejdshypoteser.
- Top-risici med ejer og anbefalet handling.
Uhensigtsmæssige mønstre vi undgår
- At bruge linting-score som forretningscase.
- “Clean-up sprint” uden prioriteret forretningsmål.
- At behandle al gæld som lige vigtig.
- At måle succes i antal lukkede debt tickets alene.
Vi ser kvalitet som en operativ egenskab: hvor hurtigt, sikkert og forudsigeligt teamet kan ændre systemet. Derfor kombineres kode- og arkitekturmålinger med flow-, test- og driftsdata.
Sådan arbejder vi i praksis
- Måler brændpunkts og kobling sammen med change frequency og defects.
- Ser på testernes kvalitet og feedbacktid — ikke coverage alene.
- Bruger DORA-/flow-signaler hvor datagrundlaget er relevant.
- Knytter stabilitet og operability til release- og ændringsadfærd.
Kunden kan forvente
- Et balanceret vurdering frem for én “quality score”.
- KPI'er der er relevante for det konkrete problem.
- Forklaring af datakvalitet og begrænsninger.
- Fokus på trends og målbare resultater frem for overfladiske målepunkter.
Eksempler på målepunkter
- Lead time for change og PR cycle time.
- Fejlrate ved ændringer, genarbejde og driftshændelser.
- Complexity/kobling i aktive brændpunkts.
- Build-/testfeedback og nye fejl safety.
Uhensigtsmæssige mønstre vi undgår
- 100 % coverage som mål i sig selv.
- Lines of code som produktivitetsmål.
- Sammenligning af teams uden kontekst.
- Målinger, der kan optimeres kunstigt uden et reelt forbedret resultat.
Når datagrundlaget gør det muligt, etableres udgangsmåling før ændringen. Efter interventionen måles samme signal igen. Det gør det muligt at skelne mellem gennemført aktivitet og reel forbedring.
Sådan arbejder vi i praksis
- Definér hypotesen og KPI'en før implementering starter.
- Fastlås måledefinition, periode og datakilde.
- Registrér væsentlige ændringer der kan påvirke resultatet.
- Eftermål, fortolk og brug resultatet som input til næste beslutningspunkt.
Kunden kan forvente
- At forventet effekt er markeret som hypotese før validering.
- At illustrative tal ikke præsenteres som kundens gevinst.
- Synlig usikkerhed og kendte confounders.
- En anbefaling om stop, fortsæt, justér eller skalér.
Hvordan det dokumenteres
- Udgangsmåling Sheet.
- Intervention / Change Log.
- After Vurdering.
- Benefits Register og Decision Memo.
Uhensigtsmæssige mønstre vi undgår
- At vælge KPI'er efter resultatet er kendt.
- At ændre definitionen mellem før og efter.
- At tilskrive hele forbedringen én intervention uden kontekst.
- At love ROI før udgangsmåling og realiseringsplan er valideret.
En leverance er ikke fuldt succesfuld, hvis kun konsulenten kan vedligeholde resultatet. Vi arbejder derfor aktivt med kompetenceoverførsel, fælles ejerskab, dokumenterede guardrails og praktiske arbejdsrutiner, som kundens team kan fortsætte.
Sådan arbejder vi i praksis
- Pairing og fælles gennemgangs frem for isoleret “black-box” levering.
- Involverer tekniske ejere tidligt i design og beslutninger.
- Dokumenterer playbooks, arkitekturbeslutninger, quality gates og driftsprincipper.
- Flytter ansvar gradvist til kundens team før afslutning.
Kunden kan forvente
- At nøglepersoner forstår både løsning og rationale.
- At nye praksisser passer ind i eksisterende engineering workflow.
- En tydelig ownership-model efter leverancen.
- At videre forbedring kan ske uden permanent ekstern afhængighed.
Hvordan det dokumenteres
- Team playbook / runbook.
- ADR- og standardsæt.
- Ejerskab/RACI for kritiske områder.
- Handover checklist og capability analyse.
Uhensigtsmæssige mønstre vi undgår
- Konsulenten som eneste person der forstår den nye arkitektur.
- Dokumentation uden praktisk anvendelse.
- Ny styring der kun virker mens projektet kører.
- Permanent afhængighed af ekstern specialist for normale ændringer.
Hvad principperne betyder kommercielt
Principperne reducerer risikoen i kundens investering. De gør det muligt at starte småt, dokumentere effekt og skalere først når der er evidens.
Før køb
- Problem og forventet beslutning afgrænses.
- Datagrundlag og centrale antagelser synliggøres.
- Scope og out-of-scope gøres eksplicit.
Under leverancen
- Progression og risiko er synlig.
- Større valg dokumenteres.
- Ændringer gennemføres i kontrollerede batches.
Ved afslutning
- Resultatet eftermåles hvor muligt.
- Business impact og resterende usikkerhed beskrives.
- Næste investering baseres på evidens.
Efter leverancen
- Kundens team ejer praksis og artefakter.
- Guardrails reducerer tilbagefald.
- KPI'er kan fortsætte som styring-signal.