Our technology choices in 2026: TypeScript, Next.js, and Azure
A walkthrough of the technology stack we use at UNOS SOFTWARE AS — and why we've settled on these choices for Norwegian businesses.
In 2026, we build all software with TypeScript, Next.js 14, and Azure — a technology stack that delivers type safety, fast load times, and data stored in Norwegian data centers. Here is why we have chosen exactly this stack.
Technology choices are business decisions. The wrong choice doesn't just mean lost time — it means more expensive maintenance, a weaker talent pool, and systems that can't scale. The right choice gives the team velocity, the client stability, and solutions that can live in production for many years.
In this article, we share the stack we've standardized on at UNOS SOFTWARE AS — and the reasoning behind each choice.
Core principle: pragmatism over hype
It's easy to be tempted by the latest framework or the coolest architecture. But we've learned that the most important criterion for technology choices is long-term maintainability. The code we write today will be read and modified by someone in three years — possibly by an entirely different team.
That's why we choose technology based on three questions:
- Is there a large, active community? — Can we get help when needed, and can we find developers who know the tool?
- Is it mature enough for production? — Has it been tested at scale, with good documentation and stable APIs?
- Does it fit the rest of the stack? — Does it create synergy with existing choices, or does it introduce a new maintenance burden?
Why TypeScript?
We write all code in TypeScript — frontend, backend, infrastructure scripts, and CLI tools. We've done this consistently since 2024, and we haven't looked back.
Why TypeScript?
Type safety catches errors before they reach production. According to the State of JS survey 2024, 89% of TypeScript users report experiencing fewer runtime errors after transitioning from JavaScript. Our experience confirms this — we spend significantly less time debugging type-related errors.
Shared language between frontend and backend. When React components and API endpoints share the same type definitions, an entire class of bugs disappears. A change in the data model is caught by the compiler on both sides immediately.
The ecosystem is mature. TypeScript had over 57 million weekly downloads on npm in January 2026. Tools like ESLint, Prettier, and tsx (runtime) work seamlessly. Hiring is easier because most JavaScript developers already know TypeScript.
What we've considered as alternatives
- Go for backend services with high performance requirements — we use it for specific microservices but not as a primary language
- Rust for systems programming — too specialized for business applications
- Python for data processing — we use it for AI/ML tasks but not for web
Why Next.js?
We use Next.js for all website projects — from corporate sites (like this one) to dashboards and customer portals.
Static generation for performance and SEO
Next.js generates HTML at build time. This means the finished page is served directly from CDN, without the server needing to render anything. The result is load times under 1 second and a Lighthouse score consistently above 90.
For a website like this, all pages are statically generated using generateStaticParams(). Content is stored as MDX files with frontmatter, and Next.js builds finished HTML for each route.
Server Components eliminate unnecessary JavaScript
React Server Components — introduced with App Router in Next.js 13 — let us build data-driven pages without sending any JavaScript to the browser for those components. Menus, content pages, and data displays render on the server, while only interactive elements like the contact form and theme toggle send JavaScript to the client.
According to Vercel benchmarks, this reduces JavaScript bundle size by 40–70% compared to traditional React applications.
Built-in infrastructure
Next.js gives us out of the box:
- Image optimization — automatic resizing, lazy loading, and WebP/AVIF conversion
- Metadata API — type-safe generation of
<title>, Open Graph, Twitter Cards, and JSON-LD - Middleware — for authentication, redirects, and security headers
- Incremental Static Regeneration (ISR) — update individual pages without rebuilding the entire site
Why Azure?
Microsoft Azure is our preferred cloud platform. For Norwegian businesses, three properties make Azure a natural choice:
Data center in Norway
Azure Norway East (Oslo region) has been operational since 2020, giving Norwegian businesses the ability to keep all data within the country's borders. This simplifies compliance with the Norwegian Personal Data Act and GDPR Articles 44–49 on transfers to third countries.
For businesses handling health records, financial data, or public personal data, this isn't just an advantage — it's often a requirement.
Microsoft Entra ID for authentication
Most Norwegian businesses already use Microsoft 365. With Entra ID (formerly Azure AD), we can implement single sign-on without users needing yet another password. This is what we use for admin access to this website — integrated via NextAuth v5.
PaaS over IaaS
We prefer Platform-as-a-Service over managing our own servers:
| Service | Use case |
|---|---|
| App Service | Hosting Next.js applications |
| Azure Functions | Serverless APIs and background jobs |
| Logic Apps | Integration workflows (e.g., contact form → Teams) |
| Azure SQL / PostgreSQL | Relational databases |
| Blob Storage | File storage and static assets |
| Key Vault | Secure handling of secrets and certificates |
The advantage of PaaS is that Microsoft handles OS updates, scaling, and high availability — while we focus on business logic.
Payment integrations for the Norwegian market
For Norwegian end users, Vipps is the preferred payment method. In Splice, we've built a payment flow supporting:
- Vipps — Norway's most-used mobile payment solution with over 4.4 million users (Vipps annual report, 2025)
- Dintero — a Norwegian payment orchestrator unifying card, Vipps, and invoice in one API
- Mastercard Payment Services — for international card transactions
The integrations are built as modular services so new payment methods can be added without changing existing code.
Security as a pervasive principle
Security isn't a layer we add on top — it's integrated throughout the entire stack:
- Content Security Policy (CSP) — restricts which sources can execute scripts on our pages
- HTTP Strict Transport Security (HSTS) — enforces HTTPS with preload
- Input validation and sanitization — all user input is validated server-side, and markdown content is sanitized through a strict allowlist
- JWT-based authentication — session management without server state
- Environment variable isolation — secrets never live in code
What we deliberately choose not to use
Equally important as what we choose is what we choose not to use:
No WordPress or PHP — we want type safety and modern developer experience. WordPress is excellent for many use cases, but doesn't fit our quality level for custom solutions.
No Kubernetes for standard projects — for most of our projects, PaaS provides sufficient control with significantly lower operational complexity. Kubernetes makes sense only for very large distributed systems.
No proprietary frameworks — all code builds on open source. Our clients own their code and can take it to another partner if they wish.
The stack in practice: this website
The website you're reading now is built with exactly this stack:
- Next.js 14 with App Router and static generation
- TypeScript in strict mode
- MDX content with YAML frontmatter and gray-matter
- NextAuth v5 with Microsoft Entra ID for admin
- Custom CSS with design tokens (no Tailwind)
- Playwright for E2E testing
The entire website builds to static HTML in under 10 seconds and is served with a Lighthouse score above 95.
Summary
Technology choices aren't about using the newest and coolest tools. They're about choosing tools that give the team velocity, the client stability, and the codebase longevity. TypeScript, Next.js, and Azure give us this combination — and we believe it's especially well-suited for Norwegian businesses that need secure, scalable solutions with data stored in Norway.
Curious about how we can apply this stack to your project? Get in touch. We deliver custom software development with this stack, run everything on Azure with Norwegian data centers, and ensure security that meets GDPR requirements.
Sources and further reading
- State of JavaScript Survey (2024). "TypeScript satisfaction and usage statistics." stateofjs.com
- Vercel (2025). "Next.js App Router Performance Benchmarks." nextjs.org/blog
- Microsoft Azure (2025). "Azure geography: Norway." azure.microsoft.com/explore/global-infrastructure/geographies
- Vipps MobilePay (2025). Annual Report 2025.
- Dintero (2025). "Unified Commerce Platform." dintero.com
- OWASP (2025). "Top 10 Web Application Security Risks." owasp.org