Metod · Så bygger vi system

Vi bevisar att koden fungerar.

De flesta byråer hoppas att deras kod fungerar. Vi kör matematisk verifiering, drift-detektion mellan spec och kod, och 8+ destruktiva tester per funktion — innan en enda rad når produktion. Det är därför våra system inte rasar i panik klockan tre på natten.

Pipeline · Spec → Allium → Plan → Impl → Playwright → TLA+
Verifiering
TLA+ formell · Allium drift · Playwright destruktiv
Stack
.NET · ASP.NET Core · React · Blazor · TypeScript · SQL Server · Postgres · SQLite · Docker Swarm · Azure · Semantic Kernel
Testtäckning
1:1 funktionell + 8 destruktiva per yta
AI-augmenterad
Claude Code · spec-register · auto-hooks
I drift
6 system live på live4.se · alla demo-öppna

"Vi använder agila metoder" är det mest meningslösa man kan säga om mjukvaruutveckling 2026. Alla säger det. Ingen kan visa vad det betyder. Det är inte en process — det är en plakett att hänga på väggen efter en daglig stand-up.

Vår metod går att granska. Den lämnar artefakter — spec-filer, Allium-rapporter, TLA+-modeller, Playwright-rapporter — som du kan läsa och argumentera mot. Den fångar race conditions innan de når produktion, drift mellan specifikation och implementation innan någon undrar varför kod och dokumentation inte stämmer överens, och ologiska tillståndsövergångar innan en slutanvändare hittar dem åt oss.

Pipelinen är ingen hemlighet. Den körs på varje icke-trivial ändring i varje system vi äger. Nedan står vad varje fas gör, varför den finns, och vad det betyder i praktiken.

Vi bygger inte fler funktioner än kunden behöver. Det som byggs har bevisbar logik bakom sig.

Pipelinen i sex faser.

Varje fas producerar artefakter som kan läsas av människor och granskas av maskiner. Inga fas-hopp, inga genvägar. Faserna körs i ordning på varje icke-trivial ändring — oavsett om det är ett nytt fält i en formulärsvy eller en ny domänmodell.

Fas 01

Specifikation.

Vi skriver vad systemet ska göra innan vi skriver hur. En spec-fil per feature, granskad innan en rad kod skrivs. Plus en klarifieringsrunda som fångar luckor som annars hade dykt upp i produktion.

/specify · /clarify
Fas 02

Formell spec (Allium).

Specen formaliseras i Allium — ett ifrågasättningsspråk för specifikationer. Inkonsekvenser och tvetydigheter ytar upp som öppna frågor innan implementation. Senare jämförs spec mot kod för drift-detektion.

/allium:elicit
Fas 03

Plan + uppgifter.

Specen bryts ned till en plan och en uppgiftslista med beroendegraf. Sedan körs en analysfas som auto-applicerar alla rekommenderade åtgärder. Implementation börjar mot en fullt instrumenterad ritning, inte en hash av idéer.

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

Implementation.

Kod skrivs mot planen — inte i en abstrakt mening, utan task för task. Backend-first som princip, inte slogan: all auktorisering, audit, soft-delete och idempotens enforced server-side. Frontend är ett tunt vylager.

.NET · React · EF Core · SSE
Fas 05

Browser-tester.

1:1 funktionell täckning — bygger du tolv funktioner skriver du tolv tester. Plus åtta destruktiva tester per yta: XSS, SQL-injection, auth-bypass, race conditions, otillåten input, gränsvärden. Alla i Playwright. Inga "happy path".

Playwright · Funktionell + destruktiv
Fas 06

Formell verifiering (TLA+).

Tillståndsmaskiner modelleras i TLA+ och invarianter bevisas matematiskt. TLC-modellcheckern hittar race conditions, deadlocks och tillstånd som ingen tänkt på. Det som kommer ur den fasen är inte ett test som "passerade" — det är ett bevis.

TLA+ · TLC · Invarianter

Vad de flesta gör. Vad vi gör.

En ärlig jämförelse mot det vi möter när vi tar över ett system byggt av någon annan. Inte ett angrepp — bara en kalibrering av vad "produktionsklar" faktiskt betyder.

Test

Manuell rundtur före release.

Vanlig byrå. Någon klickar igenom systemet, ser att inget exploderar, och trycker deploy. Edge cases upptäcks av kunden.

Manuellt · Lyckotänk
Test

1:1 funktionell + 8 destruktiva.

Vi. Varje implementerad funktion har minst ett Playwright-test. Plus åtta destruktiva tester per yta som försöker bryta systemet på de sex vanligaste sätten det går att brytas på.

Playwright · Granskningsbart
Spec

Specen lever i ett Confluence-dokument.

Vanlig byrå. Specen skrivs en gång, sedan glider den isär från koden. Sex månader senare svarar ingen på frågan "varför fungerar det så här?".

Drift · Glömska
Spec

Allium-drift mellan spec och kod.

Vi. Spec och kod jämförs automatiskt. Drift surfas som öppna frågor, inte gissningar. Specen är källkod — versionerad, granskad, alltid i synk.

Allium · Driftdetektion
Tillstånd

Race conditions hittas i produktion.

Vanlig byrå. En tillståndsmaskin tecknas på whiteboard, sedan kodas den i farten. Race conditions hittas av oturliga användare på en torsdagseftermiddag.

Whiteboard · Hopp
Tillstånd

TLA+ bevisar invarianter.

Vi. Tillståndsmaskiner modelleras formellt, invarianter bevisas. TLC hittar trilladen av tillstånd som logiken inte hanterar — innan den blir en produktionsincident.

TLA+ · Bevisbar

Stacken — vad vi väljer och varför.

Få teknikval, gjorda en gång, fördjupade i tio år. Vi byter inte stack varje sprint. Vi byter när det finns en faktisk anledning — och då motiverar vi det skriftligt.

Backend

.NET · ASP.NET Core.

Mogen, snabb, gratis runtime med starkt typsystem. EF Core med SaveChanges-interceptors som fångar audit-trail centralt — ingen kod kan smita undan. Vi har skrivit .NET sedan version 1.1.

.NET · EF Core · ASP.NET
Frontend

React · Blazor där det passar.

React som default för nya frontends — server components, suspense, native streaming. Blazor WASM för PWA där C#-end-to-end är värt det. Aldrig SPA-religion: vi väljer per system.

React · Blazor WASM · TypeScript
Databas

SQLite. Även i produktion.

SQLite på NFS rymmer flera projekt utan tenant_id-pyssel. Backups är filer du kan zippa. Inga driftkostnader för en separat databasserver. Vi byter till PostgreSQL den dag belastningen kräver det — sällan tidigare.

SQLite · WAL · NFS
AI

Egen-hostad LLM som fail-open.

Lokal modell i Docker Swarm-klustret. Är AI:n nere fortsätter systemet att fungera utan blockerare — auto-kategorisering blir manuell, ingenting kraschar. GDPR-vänligt eftersom data aldrig lämnar klustret.

Lokal LLM · Semantic Kernel · RAG
Drift

Docker Swarm på Azure.

Vi äger hela kedjan: arkitektur, databas, frontend, drift. Egen Swarm-kluster på live4.se. Inga managed-tjänster med oklar prissättning. Du vet exakt vad som körs och var.

Docker Swarm · Azure · live4.se
Verktyg

Claude Code · Spec-register.

AI-augmenterad utveckling med deterministiska hooks. Spec-register som källa för vad som byggs härnäst. Pipeline-hooks som blockerar feature-arbete utan spec. AI:n följer en metod vi har skrivit ned, granskat och versionerat.

Claude Code · Hooks · Subagents

Hela kompetensbredden.

Vi väljer få teknologier per system — men listan på det vi behärskar är längre än så. 25+ år av leveranser ger en bred bas att luta sig mot när problemet inte passar standardlösningen.

Backend

.NET-ekosystemet.

.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

Webb och 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

Relationellt, dokument, sök.

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

AI & formell verifiering

Agenter, RAG, bevisbar logik.

Semantic Kernel · Microsoft Agent Framework · Azure OpenAI · Ollama · lokala LLM:er · Claude Code · Cursor · GitHub Copilot · RAG · embeddings · hybridsök (pgvector + pg_trgm) · TLA+ · Allium · spec-driven utveckling · custom skills

Cloud (Azure)

Tjänster vi använder.

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

Containers & infra

Drift, virt, nätverk.

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

CI/CD & test

Pipelines och kvalitetsgrindar.

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

Säkerhet & identitet

Auth, GDPR, tillgänglighet.

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

Integrationer & data

Betalning, kommunikation, data governance.

Stripe · Swish · Twilio · Mailjet · Google APIs · Fortnox · SCORM · OpenTelemetry · Prometheus · Grafana · data governance · datakatalog · metadatahantering · begreppsmodellering · datakvalitet

Den långa förklaringen.

För den som vill ha det tekniska djupet — här är vad varje fas faktiskt producerar, varför den finns, och hur den hänger ihop med nästa. Övergripande sett: pipelinen är en kedja av artefakter där varje fas tar in ett dokument från föregående fas och producerar ett nytt dokument som nästa fas kan läsa. Inga muntliga överlämningar. Inga "jag tror att vi pratade om det här på onsdagsmötet".

Allium — drift som datapunkt.

Allium är ett ifrågasättningsspråk: du skriver en specifikation, sedan körs en elicitering som hittar luckor, tvetydigheter och inkonsekvenser. Den producerar öppna frågor som måste besvaras innan vi går vidare. Senare körs en distillering som jämför den färdiga koden mot specen — drift visas som tre kategorier: specificerat-men-ej-implementerat, implementerat-men-ej-specificerat, och beteendedrift. Varje punkt får ett individuellt beslut: fixa nu, defer (spåra i spec) eller dismiss med skäl. Inga gruppbeslut om att "vi tar det senare" — varje finding har ett ägare och ett datum.

TLA+ — bevis, inte tester.

Ett test som passerar visar att en exekvering fungerade. Det säger ingenting om de exekveringar du inte testade. TLA+ modellerar systemet som ett tillståndsrum och kör en uttömmande genomgång — TLC-modellcheckern testar varje möjlig sekvens av händelser och hittar de tillstånd där invarianter bryts. För ärendehantering: kan ett ärende vara stängt och pågående samtidigt? För SSE: vad händer om klienten reconnectar mitt under en uppdatering? För idempotens: vad händer om samma idempotency-key ses i två requests samtidigt? TLC svarar matematiskt, inte sannolikhetsbaserat.

Destruktiva tester — sex kategorier.

Funktionella tester verifierar att lyckomönstret fungerar. Destruktiva tester verifierar att systemet inte rasar när någon försöker bryta det. Vi kör minst åtta destruktiva scenarier per yta, fördelade över sex kategorier.

Input-validering bombarderar fält med för långa strängar, ogiltiga tecken, null och tomma värden. Auktorisering försöker läsa och skriva resurser som användaren inte äger. Injection-kategorin matar in XSS i textfält och SQL-injection i sökparametrar. Race conditions tvingar två klienter att ändra samma resurs i samma sekund. Gränsvärden testar maxlängder, maxantal och paginering vid sista sidan. Tillståndskorruption skickar ändringar i fel ordning eller mot redan borttagna resurser.

Inget av detta är teoretiskt. Varje kategori har fångat verkliga buggar i produktionssystem vi byggt — innan de släpptes.

AI-augmenterad utveckling — utan AI-religion.

Claude Code används som verktyg, inte som ersättning. Pipelinen ovan är inte AI-genererad — den är dokumenterad, versionerad och enforced via deterministiska hooks. Hookarna blockerar feature-arbete utan spec, kräver klarifiering före plan, kör Allium-elicitering före implementation, och vägrar släppa ifrån sig en feature utan både Playwright- och TLA+-validering. AI:n följer metoden — den uppfinner den inte. Resultatet: AI-hastighet med människa-nivå granskning på arkitekturbeslut.

Den här metoden tar längre tid i den första veckan. Den sparar månader när systemet är ett år gammalt.

Vi är inte rätt val för allting.

Vi återkommer med en bedömning av passningen — och om det inte är oss ni behöver, säger vi det direkt.

Skriv en rad till oss om vad ni försöker bygga.

Skriv till oss