Teknologistabelen til cutty.dev — bevisste valg

De fleste "min tech stack"-artikler er en stolt liste over nyvinninger. Denne handler om noe annet — om filosofien som ligger bak valgene til cutty.dev: kjedelig og stabilt i stedet for trendy, europeisk i stedet for amerikansk, privat av natur, og enkel nok til at én person kan vedlikeholde den.

Rammeverk: Astro (server-side rendering)

cutty.dev er en Astro-applikasjon som rendres på serversiden. Hver forespørsel går gjennom serveren, genererer siden dynamisk og svarer med ferdig HTML.

Hvorfor: jeg ønsket server-side rendering uten tung maskinvare, god støtte for mange språk innebygd i selve rammeverket, og hastighet uten overhead. Astro gir alt dette, og koden forblir lesbar — noe som, i et prosjekt drevet alene, er verdt mer enn noe som helst trendy tillegg.

Database: SQLite

Én database, én fil. I tillegg et TypeScript-vennlig spørrelag, som gjør at endringer i datastrukturen umiddelbart viser feil i koden i stedet for i produksjon.

Hvorfor: cutty.dev er først og fremst "read-heavy" — hvert klikk på en lenke er en lesing pluss en økning i telleren. SQLite gjør dette utmerket, opp til veldig høy daglig trafikk. Backup er rett og slett å kopiere én fil — uten replikeringsseremonier, uten kompliserte skript. Enkelhet her er ikke en besparelse på kvalitet; det er en bevisst beslutning om at færre bevegelige deler betyr færre ting som kan gå galt.

Hosting: server i EU

Dedikert server i EU, eget TLS-sertifikat, reverse proxy med automatisk HTTPS, applikasjon i containere.

Hvorfor: dette er fundamentet for hvordan cutty.dev behandler data. Full kontroll over deres lokasjon (avgjørende for kunder i EU og for GDPR), ingen avhengighet av én enkelt leverandør, ingen automatisk replikering til USA slik store skyplattformer tilbyr, og en forutsigbar kostnad i stedet for en regning som avhenger av trafikk. Praktiske vestlige plattformer ville gitt en raskere start — men på bekostning av hvor brukernes data fysisk havner.

Oversettelser: lokal AI-modell

cutty.dev snakker 25 språk, og oversettelsene gjøres av en lokal, åpen AI-modell som kjører på vår egen infrastruktur.

Hvorfor: ingen tekst fra grensesnittet kommer ut — vi sender den ikke til noen ekstern AI-leverandør. Dette resulterer i null kostnad per enkeltoversettelse og full kontroll over kvaliteten: vi kan oppdatere dem når vi vil. Maskinoversettelse krever alltid menneskelig kontroll — og hvert språk har gjennomgått en slik gjennomgang — men å gjøre det selv betyr at personvern ikke er et valg i prislisten, men en egenskap ved arkitekturen.

CSS: utility-first (Tailwind)

Ett enkelt stilsystem, uten CSS-in-JS, uten separate stilark. Alt direkte i malene.

Hvorfor: iterasjonshastighet. Jeg kaster ikke bort tid på å finne opp klassenavn, og ubenyttede stiler havner uansett ikke på den endelige siden. Et konsistent design tvunget frem av selve systemet. For én person teller hvert minutt som jeg ikke bruker på bivirkninger.

Implementering: containere

Applikasjon i containere (Docker), distribuert på en repeterbar og portabel måte.

Hvorfor: samme miljø lokalt og på produksjon, ingen "det fungerte hos meg", og muligheten til å flytte hele greia til en annen server på en halvtime, hvis behovet skulle oppstå. Portabilitet er en form for uavhengighet.

Hva dette lærte meg

• Kjedelig stack vinner. Astro, SQLite, Tailwind, containere — alt er modent, godt dokumentert og stabilt. Ingenting går i stykker på det minst forventede tidspunktet.
• Hosting i EU er klart for produksjon. Myten om at "du må bruke den store amerikanske skyen for å være seriøs" er nettopp det — en myte.
• Lokal AI er realistisk. Du trenger ikke å gi fra deg dataene dine til et eksternt API for å få gode oversettelser.
• Én person kan lansere noe som ser ut som et produkt fra et team. Tid er en ressurs som er dyrere enn penger, så hvert valg her har nettopp spart tid.

Se live. Spørsmål om teknisk tilnærming — hello@cutty.dev, jeg svarer samme dag.