Stack
Stacken vi kender — og driver — på rygmarven.
Det her er teknologierne vi vender tilbage til. Ikke fordi de er nyeste, men fordi vi har bygget og driftet dem længe nok til at vide hvor de knirker, hvad de koster i drift, og hvornår man skal vælge noget andet.
Modent slår nyt — hver gang noget skal stå oppe.
Vi vælger ikke teknologi efter trends. Vi vælger efter dokumentation, community, driftsmodenhed og hvor let det er at hyre folk til om to år. Når vi tester en ny teknologi i et internt projekt, går der typisk 12-18 måneder før den får lov at ramme en kundeleverance — så vi ved hvor den fejler, ikke kun hvor den shines.
Det betyder ikke at vi er konservative. Vi bruger gerne edge-runtimes, server components og Postgres' nyere features. Men kerne-stacken er valgt med en ting for øje: det skal stadig være vedligeholdbart i 2030. Modent og kedeligt er en feature, ikke en begrænsning.
Next.js
Frontend & fullstack framework
Vores standard for både websites og kundevendte SaaS-frontends. App Router, server components, edge-runtime — vi bruger hele paletten, men kun hvor det giver mening for jeres team at vedligeholde bagefter.
Det bruger vi den til
- Marketing-sites med Core Web Vitals i grøn felt
- SaaS-dashboards med server components og streaming
- Multi-tenant kundeportaler
TypeScript
End-to-end type-sikkerhed
Skrives på frontend, backend, deploy-scripts og IaC. Strict mode fra dag 1. Vi tror på at compile-time fejl er billigere end runtime-fejl — særligt i en SaaS hvor kunder ikke har tid til at vente på en hot-fix.
Det bruger vi den til
- Delte typer mellem klient og API
- Generated types fra database-schemas
- End-to-end typesikre RPC'er (tRPC, Hono RPC)
Node.js
Backend-runtime og API'er
Vores foretrukne runtime når Next.js-API ikke rækker. Lightweight HTTP-services, baggrundsjobs, scheduled tasks. Holder sig tæt på standardbiblioteket — vi undgår tunge frameworks der låser jer ind.
Det bruger vi den til
- REST og JSON-RPC backends
- Webhook-modtagere og baggrundsjobs
- Scheduled tasks via cron eller workflows
Python
Data, scripting og ML-pipelines
Når opgaven hedder data-engineering, ML-inference eller integration mod biblioteker som ikke findes i Node-økosystemet. Typisk FastAPI for services, polars/duckdb for data-pipelines.
Det bruger vi den til
- Data-pipelines og ETL
- LLM-services med evaluation og caching
- Integration mod Python-only biblioteker
Vercel
Edge-hosting og preview-deployments
Vores standard hosting for Next.js. Preview-environment på hver pull request — det er her vores arbejdsform reelt bor. Vi bruger Vercel når kunden vil have nul drifts-overhead på frontend; AWS eller Cloudflare når der er specifikke krav.
Det bruger vi den til
- Preview-deploys på hver PR
- Edge functions og middleware
- ISR og on-demand revalidation
Cloudflare
Edge-netværk, WAF og Workers
DNS, CDN, WAF, DDoS-beskyttelse, Workers og R2. Vores foretrukne kant af internettet. Vi bruger Cloudflare som standard foran alt der ligger i en cloud, og som primær compute når en service kan leve på Workers.
Det bruger vi den til
- DNS, CDN og WAF foran alt produktion
- Workers til lightweight services og edge-logik
- R2 storage og cache-strategier
AWS
Cloud-arbejdsbelastninger og storage
Når noget kræver mere end edge-runtime: lange jobs, store data-volumener, regulatoriske krav. Vi bruger primært ECS, RDS, S3, Lambda, EventBridge — bygget med IaC fra start, så I kan tage over.
Det bruger vi den til
- Compute-tunge backends (ECS, Lambda)
- Managed databaser (RDS, Aurora)
- Event-drevne arkitekturer (EventBridge, SQS)
Firebase
Auth, realtime og mobil-backend
Når et MVP skal i luften hurtigt og hovedopgaven er auth + et hurtigt datalag — typisk for mobile-first eller realtime-tunge produkter. Vi bygger det så I kan migrere væk hvis I vokser ud af det.
Det bruger vi den til
- Auth med social providers og custom claims
- Realtime-data til mobile apps
- Hurtig MVP-backend uden DevOps-overhead
Supabase
Postgres, auth og real-time
Postgres med batterier inkluderet. Vores foretrukne start for SaaS hvor I gerne vil eje databasen, men ikke vil bygge auth, RLS-policies og storage selv fra dag 1. Migrerbar til selvstændig Postgres når I vokser.
Det bruger vi den til
- SaaS-MVP'er med multi-tenant RLS
- Auth, storage og realtime ud af boksen
- Edge functions tæt på databasen
PostgreSQL
Relationel database vi tør drifte
Vores standard-database. Næsten alt vi bygger lander i Postgres — managed (RDS, Neon, Supabase) eller self-hosted afhængigt af kravene. JSONB hvor det giver mening, RLS for multi-tenant, materialized views for tunge queries.
Det bruger vi den til
- Multi-tenant data med Row Level Security
- JSONB for fleksible schemas hvor det giver mening
- Logical replication og read-replicas
Tailwind CSS
Designsystem og UI
Vores foretrukne måde at bygge designsystemer hurtigt og holdbart. Kombineret med CSS variables for tematisering og en lille ui-primitives-mappe — så I ikke arver et tungt komponent-bibliotek I ikke ejer.
Det bruger vi den til
- Designsystemer baseret på CSS variables
- Holdbare komponent-primitiver
- Hurtigt design uden CSS-in-JS overhead
Fire kriterier — hver gang.
Vi har ikke ét framework. Vi har en proces for hvordan vi vælger ét.
- 01
Driftsmodenhed over feature-set
Vi spørger først: kan vi drifte det her i 5 år uden at hate-fork'e biblioteket? Hvis svaret er nej, vælger vi noget andet — uanset hvor smart det ser ud i en demo.
- 02
Hyrbarhed om to år
Hvis det kun er os der kan vedligeholde stacken, har vi gjort det forkert. Vi vælger teknologi I kan hyre folk til, eller som jeres eget team kan lære uden et bootcamp.
- 03
Klar exit-vej
Vi binder os ikke til vendors uden en plan B. Postgres frem for proprietære databaser. Standard-protokoller frem for vendor-SDKs. Hvis I skal væk, skal I kunne det.
- 04
Total cost of ownership
Hosting-pris er én ting. Drifts-tid, on-call-byrde, opdateringsfrekvens, migrationsbesvær — det er hvad det reelt koster at drive noget. Vi medregner hele billedet.
Snak om jeres stack
Skal vi kigge på en stack der allerede står?
Vi tager også eksisterende platforme — du behøver ikke skifte stack for at arbejde med os. Vi kigger gerne med på en arkitektur og siger ærligt hvad vi ville ændre.