Metode · Slik bygger vi systemer

Vi beviser at koden virker.

De fleste byråer håper at koden deres virker. Vi kjører matematisk verifisering, drift-deteksjon mellom spec og kode, og 8+ destruktive tester per funksjon — før en eneste linje når produksjon. Derfor får ikke systemene våre panikk klokken tre om natten.

Pipeline · Spec → Allium → Plan → Impl → Playwright → TLA+
Verifisering
TLA+ formell · Allium drift · Playwright destruktiv
Stack
.NET · ASP.NET Core · React · Blazor · TypeScript · SQL Server · Postgres · SQLite · Docker Swarm · Azure · Semantic Kernel
Testdekning
1:1 funksjonell + 8 destruktive per flate
AI-augmentert
Claude Code · spec-register · auto-hooks
I drift
6 systemer live på live4.se · alle demo-åpne

"Vi bruker smidige metoder" er det mest meningsløse man kan si om programvareutvikling i 2026. Alle sier det. Ingen kan vise hva det betyr. Det er ikke en prosess — det er en plakett du henger på veggen etter en daglig stand-up.

Metoden vår kan granskes. Den etterlater artefakter — spec- filer, Allium-rapporter, TLA+-modeller, Playwright-rapporter — som du kan lese og argumentere mot. Den fanger race conditions før de når produksjon, drift mellom spesifikasjon og implementasjon før noen lurer på hvorfor kode og dokumentasjon ikke stemmer overens, og ulogiske tilstandsoverganger før en sluttbruker finner dem for oss.

Pipelinen er ingen hemmelighet. Den kjøres på hver ikke-triviell endring i hvert system vi eier. Under står hva hver fase gjør, hvorfor den finnes, og hva det betyr i praksis.

Vi bygger ikke flere funksjoner enn kunden trenger. Det som bygges har beviselig logikk bak seg.

Pipelinen i seks faser.

Hver fase produserer artefakter som kan leses av mennesker og granskes av maskiner. Ingen fase-hopp, ingen snarveier. Fasene kjøres i rekkefølge på hver ikke-triviell endring — enten det er et nytt felt i et skjema eller en ny domenemodell.

Fase 01

Spesifikasjon.

Vi skriver hva systemet skal gjøre før vi skriver hvordan. Én spec-fil per feature, gjennomgått før en linje kode skrives. Pluss en avklaringsrunde som fanger huller som ellers hadde dukket opp i produksjon.

/specify · /clarify
Fase 02

Formell spec (Allium).

Specen formaliseres i Allium — et avhørsspråk for spesifikasjoner. Inkonsistenser og tvetydigheter dukker opp som åpne spørsmål før implementasjon. Senere sammenlignes spec mot kode for drift-deteksjon.

/allium:elicit
Fase 03

Plan + oppgaver.

Specen brytes ned til en plan og en oppgaveliste med avhengighetsgraf. Deretter kjøres en analysefase som auto-anvender alle anbefalte tiltak. Implementasjon starter mot en fullt instrumentert tegning, ikke en hash av idéer.

/plan · /tasks · /speckit.analyze
Fase 04

Implementasjon.

Kode skrives mot planen — ikke i abstrakt forstand, men oppgave for oppgave. Backend-først som prinsipp, ikke slagord: all autorisering, audit, soft-delete og idempotens er enforced server-side. Frontend er et tynt visningslag.

.NET · React · EF Core · SSE
Fase 05

Nettlesertester.

1:1 funksjonell dekning — bygger du tolv funksjoner skriver du tolv tester. Pluss åtte destruktive tester per flate: XSS, SQL-injection, auth-bypass, race conditions, ugyldig input, grenseverdier. Alle i Playwright. Ingen "happy path".

Playwright · Funksjonell + destruktiv
Fase 06

Formell verifisering (TLA+).

Tilstandsmaskiner modelleres i TLA+ og invarianter bevises matematisk. TLC-modellcheckeren finner race conditions, deadlocks og tilstander ingen har tenkt på. Det som kommer ut av den fasen er ikke en test som "bestod" — det er et bevis.

TLA+ · TLC · Invarianter

Det de fleste gjør. Det vi gjør.

En ærlig sammenligning mot det vi møter når vi overtar et system bygget av noen andre. Ikke et angrep — bare en kalibrering av hva "produksjonsklar" faktisk betyr.

Test

Manuell klikking før release.

Vanlig byrå. Noen klikker gjennom systemet, ser at ingenting eksploderer, og trykker deploy. Edge cases oppdages av kunden.

Manuelt · Lykkelig tenkning
Test

1:1 funksjonell + 8 destruktive.

Vi. Hver implementert funksjon har minst én Playwright-test. Pluss åtte destruktive tester per flate som prøver å bryte systemet på de seks vanligste måtene det kan brytes på.

Playwright · Granskbart
Spec

Specen lever i et Confluence-dokument.

Vanlig byrå. Specen skrives én gang, deretter glir den fra koden. Seks måneder senere kan ingen svare på hvorfor det virker som det gjør.

Drift · Glemsel
Spec

Allium-drift mellom spec og kode.

Vi. Spec og kode sammenlignes automatisk. Drift dukker opp som åpne spørsmål, ikke gjetninger. Specen er kildekode — versjonert, gjennomgått, alltid i synk.

Allium · Driftdeteksjon
Tilstand

Race conditions oppdages i produksjon.

Vanlig byrå. En tilstandsmaskin skisseres på whiteboard, deretter kodes den på sparket. Race conditions fanges av uheldige brukere en torsdag ettermiddag.

Whiteboard · Håp
Tilstand

TLA+ beviser invarianter.

Vi. Tilstandsmaskiner modelleres formelt, invarianter bevises. TLC finner klyngen av tilstander som logikken ikke håndterer — før det blir en produksjonshendelse.

TLA+ · Beviselig

Stacken — hva vi velger og hvorfor.

Få teknologivalg, gjort én gang, fordypet i ti år. Vi bytter ikke stack hver sprint. Vi bytter når det finnes en faktisk grunn — og da begrunner vi det skriftlig.

Backend

.NET · ASP.NET Core.

Moden, rask, gratis runtime med sterkt typesystem. EF Core med SaveChanges-interceptors som fanger audit-trail sentralt — ingen kode kan smyge unna. Vi har skrevet .NET siden versjon 1.1.

.NET · EF Core · ASP.NET
Frontend

React · Blazor der det passer.

React som default for nye frontends — server components, suspense, native streaming. Blazor WASM for PWA der C# ende-til-ende er verdt det. Aldri SPA-religion: vi velger per system.

React · Blazor WASM · TypeScript
Database

SQLite. Også i produksjon.

SQLite på NFS rommer flere prosjekter uten tenant_id-styr. Backups er filer du kan zippe. Ingen driftskostnader for en separat databaseserver. Vi bytter til PostgreSQL den dagen lasten krever det — sjelden tidligere.

SQLite · WAL · NFS
AI

Egen-hostet LLM som fail-open.

Lokal modell i Docker Swarm-klyngen. Er AI-en nede, fortsetter systemet å virke uten blokkerere — auto-kategorisering blir manuell, ingenting krasjer. GDPR-vennlig fordi data aldri forlater klyngen.

Lokal LLM · Semantic Kernel · RAG
Drift

Docker Swarm på Azure.

Vi eier hele kjeden: arkitektur, database, frontend, drift. Egen Swarm-klynge på live4.se. Ingen managed-tjenester med uklar prising. Du vet nøyaktig hva som kjøres og hvor.

Docker Swarm · Azure · live4.se
Verktøy

Claude Code · spec-register.

AI-augmentert utvikling med deterministiske hooks. Spec-register som kilde for hva som bygges neste. Pipeline-hooks som blokkerer feature-arbeid uten spec. AI-en følger en metode vi har skrevet ned, gjennomgått og versjonert.

Claude Code · Hooks · Subagents

Hele kompetansebredden.

Vi velger få teknologier per system — men listen over det vi behersker er lengre enn som så. 25+ års leveranser gir en bred base å lene seg på når problemet ikke passer standardløsningen.

Backend

.NET-økosystemet.

.NET 6–10 · C# · ASP.NET Core · .NET Aspire · EF Core · Dapper · MediatR · Quartz.NET · SignalR · gRPC · GraphQL · REST · Clean Architecture · CQRS · DDD · multi-tenant SaaS · microservices · Node.js

Frontend

Web og mobil.

TypeScript · JavaScript · React · React Native · Expo · Next.js · Vue · Svelte · Blazor WASM · Blazor Server · HTMX · Tailwind · Bootstrap · jQuery · HTML · CSS · WordPress · Android (Java) · iOS (Obj-C)

Databaser

Relasjonelt, dokument, søk.

SQL Server · T-SQL · PostgreSQL · pgvector · pg_trgm · MySQL · MongoDB · Redis · SQLite · Elasticsearch · indeksoptimering · backup-strategier · execution plans · skjemamigreringer

AI & formell verifisering

Agenter, RAG, beviselig logikk.

Semantic Kernel · Microsoft Agent Framework · Azure OpenAI · Ollama · lokale LLM-er · Claude Code · Cursor · GitHub Copilot · RAG · embeddings · hybridsøk (pgvector + pg_trgm) · TLA+ · Allium · spec-drevet utvikling · custom skills

Cloud (Azure)

Tjenester vi bruker.

App Service · Functions · Container Apps · Service Bus · Event Grid · SQL · Storage · Key Vault · API Management · Entra ID · Monitor · App Insights

Containere & infra

Drift, virt, nettverk.

Docker · Docker Swarm · Docker Compose · Kubernetes · Linux (Ubuntu/Debian) · Windows Server · Active Directory · DNS · IIS · Nginx · virtualisering · GPU-farm

CI/CD & test

Pipelines og kvalitetsporter.

Azure DevOps · GitHub Actions · BitBucket · Bicep (IaC) · xUnit · NUnit · Playwright · Testcontainers · k6-stresstester · kodegjennomgang · pull requests · Git/GitHub

Sikkerhet & identitet

Auth, GDPR, tilgjengelighet.

OAuth2 · OpenID Connect · JWT · WebAuthn · Passkeys · GDPR · Zero Trust · audit-trail · soft-delete · idempotency-keys · WCAG 2.1 AA

Integrasjoner & data

Betaling, kommunikasjon, data governance.

Stripe · Swish · Twilio · Mailjet · Google APIs · Fortnox · SCORM · OpenTelemetry · Prometheus · Grafana · data governance · datakatalog · metadatahåndtering · begrepsmodellering · datakvalitet

Den lange forklaringen.

For den som vil ha det tekniske dypet — her er hva hver fase faktisk produserer, hvorfor den finnes, og hvordan den henger sammen med den neste. Overordnet: pipelinen er en kjede av artefakter der hver fase tar inn et dokument fra forrige fase og produserer et nytt dokument som neste fase kan lese. Ingen muntlige overleveringer. Ingen "jeg tror vi snakket om dette på onsdagsmøtet".

Allium — drift som datapunkt.

Allium er et avhørsspråk: du skriver en spesifikasjon, så kjøres en elicitering som finner huller, tvetydigheter og inkonsistenser. Den produserer åpne spørsmål som må besvares før vi går videre. Senere kjøres en destillering som sammenligner den ferdige koden mot specen — drift vises som tre kategorier: spesifisert-men-ikke-implementert, implementert-men-ikke-spesifisert, og atferdsdrift. Hver post får en individuell beslutning: fiks nå, defer (spor i spec) eller dismiss med begrunnelse. Ingen gruppebeslutninger om at "vi tar det senere" — hvert funn har en eier og en dato.

TLA+ — bevis, ikke tester.

En test som består viser at én eksekvering virket. Den sier ingenting om de eksekveringene du ikke testet. TLA+ modellerer systemet som et tilstandsrom og kjører en uttømmende gjennomgang — TLC-modellcheckeren prøver hver mulig sekvens av hendelser og finner de tilstandene der invarianter brytes. For saksbehandling: kan en sak være både stengt og pågående samtidig? For SSE: hva skjer hvis klienten reconnecter midt i en oppdatering? For idempotens: hva skjer hvis samme idempotency-key sees i to requests samtidig? TLC svarer matematisk, ikke sannsynlighetsbasert.

Destruktive tester — seks kategorier.

Funksjonelle tester verifiserer at lykkesmønsteret virker. Destruktive tester verifiserer at systemet ikke faller når noen prøver å bryte det. Vi kjører minst åtte destruktive scenarier per flate, fordelt over seks kategorier.

Input-validering bombarderer felt med for lange strenger, ugyldige tegn, null og tomme verdier. Autorisering prøver å lese og skrive ressurser som brukeren ikke eier. Injection-kategorien mater XSS i tekstfelt og SQL-injection i søkeparametre. Race conditions tvinger to klienter til å endre samme ressurs i samme sekund. Grenseverdier tester maksimumslengder, maksantall og paginering på siste side. Tilstandskorrupsjon sender endringer i feil rekkefølge eller mot allerede slettede ressurser.

Ingenting av dette er teoretisk. Hver kategori har fanget reelle bugs i produksjonssystemer vi har bygget — før de ble sluppet.

AI-augmentert utvikling — uten AI-religion.

Claude Code brukes som verktøy, ikke som erstatning. Pipelinen over er ikke AI-generert — den er dokumentert, versjonert og enforced via deterministiske hooks. Hookene blokkerer feature-arbeid uten spec, krever avklaring før plan, kjører Allium-elicitering før implementasjon, og nekter å slippe en feature uten både Playwright- og TLA+-validering. AI-en følger metoden — den oppfinner den ikke. Resultatet: AI-fart med menneskelig gjennomgang av arkitekturbeslutninger.

Denne metoden tar lengre tid den første uken. Den sparer måneder når systemet er ett år gammelt.

Vi er ikke rett valg for alt.

Vi kommer tilbake med en vurdering av tilpasningen — og hvis det ikke er oss dere trenger, sier vi det rett ut.

Skriv en linje til oss om hva dere prøver å bygge.

Skriv til oss