En teknikstack är inte ett religiöst val — det är ett leveransbeslut. Stacken du väljer avgör hur snabbt du levererar, hur många buggar som når produktion och hur billigt nästa ingenjör kan ta över koden. Vi bygger de flesta produkter på en heltäckande TypeScript-stack, och det är ett medvetet val för kundresultat, inte utvecklarmode. Här är vad vi använder och varför varje del förtjänar sin plats.
Ett språk, hela vägen
Grunden är TypeScript överallt — databaslager, API och frontend. Ett enda språk över hela stacken innebär en uppsättning kompetenser, delad kod och delade typer mellan klient och server, och inget kostsamt kontextbyte mellan, säg, en backend i ett språk och en frontend i ett annat.
Den större vinsten är typsäkerhet som flödar från databasen till gränssnittet. När formen på din data definieras en gång och tvingas hela vägen till knappen som visar den, kan en hel kategori buggar — typen “API:et returnerade ett fält frontenden inte väntade sig” — helt enkelt inte uppstå. Det är färre produktionsincidenter och snabbare, säkrare refaktoreringar när produkten växer.
Delarna
- Runtime & verktyg: Bun. En snabb allt-i-ett-runtime och verktygskedja. Snabbare installationer, testkörningar och byggen ger en tätare återkopplingsloop — vilket sammantaget över ett helt projekt blir verklig leveranshastighet.
- Frontend: Nuxt (Vue) eller Next.js (React). Båda är mogna, serverrenderande ramverk med utmärkt prestanda och SEO direkt ur lådan. Vi väljer per projekt — Vue/Nuxt eller React/Next — baserat på teamet och produkten, inte dogm.
- API: tRPC. Heltäckande typade API:er utan kodgenerering och utan handskriven klient. Frontenden anropar backenden som en lokal funktion, fullt typad. Vi går djupare i Typsäkra API:er med tRPC och Drizzle.
- Databas: Drizzle ORM + PostgreSQL. Ett typat frågelager över den mest kapabla öppna databasen. Ditt schema är TypeScript, dina frågor kontrolleras vid kompilering, och Postgres hanterar långt mer skala än de flesta produkter någonsin behöver — inklusive vektorsökning med pgvector för AI-funktioner.
- Validering: Zod. En schemadefinition som validerar indata vid kanten och producerar typer som används överallt annars.
Varför detta levererar snabbare
Temat över varje val är att fånga misstag vid kompilering i stället för i produktion, och att dela en definition i stället för att underhålla flera. Konkret betyder det:
- En ändring i databasschemat dyker upp som ett typfel i exakt de frontend-komponenter som behöver uppdateras — innan något levereras.
- Nya ingenjörer kommer igång snabbare eftersom typerna dokumenterar systemet och samma språk körs överallt.
- Refaktorering är säkert, så kodbasen förblir hälsosam i stället för att förstenas — vilket håller framtida funktioner billiga, inte bara den första.
För en kund översätts det till de saker som faktiskt spelar roll: färre buggar, snabbare iterationer och en kodbas som är billig att underhålla och lämna över.
När vi skulle välja annorlunda
Ingen stack är universell. Tunga data-engineering- eller vetenskapliga beräkningsarbetslaster, ett befintligt team med djup expertis någon annanstans, eller ett hårt krav på ett specifikt ekosystem kan alla peka åt ett annat håll — och vi är stack-agnostiska nog att bygga vidare på det ni redan har. Men för att bygga nya webbprodukter och SaaS från grunden är heltäckande TypeScript, enligt vår erfarenhet, den snabbaste tillförlitliga vägen från idé till produktion.
Om du väljer en stack för ett nytt bygge — eller undrar om din nuvarande bromsar dig — pratar vi gärna igenom avvägningarna för din specifika produkt.
