Chosen for the work, not the other way round.
We start from what the software needs to do, then choose the languages, frameworks and infrastructure that fit. This page lists the options we choose from and what each is for.
These are representative options, not a claim that we have shipped a project in each. Every choice is made, and its version checked, during the project.
Languages
The languages a product can be written in, each suited to different work.
| Name | What it is | Used for |
|---|---|---|
| JavaScript | Programming language | Behaviour in the browser, and server code in compatible runtimes. |
| TypeScript | Programming language, a superset of JavaScript | Adds static types; types do not replace checking the input a program receives. |
| Python | Programming language | AI orchestration, data processing, automation and backend APIs. |
| Rust | Programming language | Performance-sensitive services, native cores, command-line tools and selected WebAssembly modules. |
| Go | Programming language | Network services, infrastructure tooling and concurrent backend work. |
| C# | Programming language | Enterprise APIs and desktop services on the .NET platform. |
| Java | Programming language | Business applications and services, commonly with Spring. |
| Kotlin | Programming language | Android applications and JVM backend services. |
| Swift | Programming language | Native applications and integrations on Apple platforms. |
| Dart | Programming language | Applications built with Flutter. |
| C / C++ | Programming languages | Native libraries, hardware-facing software and specialized performance work. |
| PHP | Programming language | Custom server applications, for example with Laravel or Symfony; not the same thing as WordPress. |
| Elixir | Programming language | Concurrent and real-time services, often with Phoenix. |
| Ruby | Programming language | Business web applications, commonly with Rails. |
| SQL | Database query language | Query and change relational data. |
| HTML | Markup language | The structure and meaning of web documents. |
| CSS | Style-sheet language | Layout, typography, responsiveness and visual presentation. |
| Shell / PowerShell | Scripting languages | Deployment, local tooling and operating-system automation. |
| WGSL / GLSL | Shader languages | Specialized GPU and graphics workloads. |
Web interfaces
A custom website can combine these: Astro can include React components, and a React application can use Tailwind without Next.js.
| Name | What it is | Used for |
|---|---|---|
| React | UI library | Interactive interfaces built from components; routing, data and backend are chosen alongside it. |
| Next.js | React web framework | Integrated web products with server and client rendering and application routes. |
| Astro | Web framework | Content-led sites with interactivity only where it is needed; server rendering is available too. |
| Vue + Nuxt | UI framework and web framework | Reactive interfaces and integrated Vue applications. |
| Svelte + SvelteKit | UI compiler and application framework | Reactive interfaces and routed full-stack web products. |
| Angular | Web application framework | Structured application development, often for large internal interfaces. |
| React Router | Routing and React framework tooling | Client-side routing, or the architecture of a framework-based React application. |
| Vite | Development and build tooling | Builds frontend applications; it does not supply a production backend by itself. |
| Tailwind CSS | CSS framework | Utility classes for composing custom styling; optional alongside any framework. |
| CSS Modules / Sass | Styling tools | Scoped CSS or stylesheet preprocessing. |
| Radix / React Aria / shadcn/ui | UI primitives and component resources | Accessible building blocks, customized to the product. |
| Three.js / React Three Fiber | 3D library and React renderer | Interactive 3D in the browser; GPU and device limits still apply. |
| WebGL / WebGPU | Browser graphics APIs | GPU rendering and supported compute, after checking the target browsers and devices. |
| Headless CMS | Content-service architecture | An editing interface kept separate from a custom frontend. |
Backends and data
The interface framework does not decide the whole system. Transactions, permissions, background work and recovery are designed explicitly.
| Name | What it is | Used for |
|---|---|---|
| Node.js / Bun / Deno | JavaScript runtimes | Run JavaScript and TypeScript server code, after checking library compatibility. |
| Fastify / Express / Hono | Server frameworks | TypeScript and JavaScript APIs with different conventions and deployment targets. |
| NestJS | Node.js application framework | Structured services and modular business APIs. |
| FastAPI / Django | Python frameworks | APIs, or integrated backend applications with admin workflows. |
| Axum / Actix Web | Rust web frameworks | Rust services, when native performance or integration needs justify them. |
| Go net/http / Chi / Gin | Go HTTP tooling | Network services and APIs. |
| ASP.NET Core / Spring Boot | C# and Java frameworks | Enterprise services and business-system integrations. |
| Laravel / Symfony / Rails / Phoenix | PHP, Ruby and Elixir frameworks | Other custom backend ecosystems, chosen when the requirements favour them. |
| PostgreSQL / MySQL | Relational databases | Structured transactional data, relationships and constraints. |
| SQLite | Embedded relational database | Local apps or suitable bounded workloads; concurrent writing needs review. |
| MongoDB | Document database | Document-shaped data, where its model suits the queries and consistency needs. |
| Redis / Valkey | In-memory data stores | Caching, short-lived state and suitable messaging; not storage that lasts by default. |
| OpenSearch / Meilisearch / Typesense | Search systems | Indexed text search, when database search is not enough. |
| pgvector / Qdrant | Vector extension and vector database | Search by meaning; the quality depends on the data and on evaluation. |
| Object storage | Storage service | Uploads, documents, media and backup copies. |
| Prisma / Drizzle / SQLAlchemy | Data-access tools | Schemas and data access; migrations and query correctness still need checking. |
| REST / GraphQL / gRPC | API styles and protocols | Connect clients and services through a suitable contract. |
| WebSockets / SSE / webhooks | Communication mechanisms | Live connections, events from the server or notifications between systems. |
| Queues and durable workflows | Background execution tooling | Background jobs and retries that survive restarts. |
Mobile, desktop and AI
Platform access, installation, offline needs and data boundaries are settled before a toolkit is chosen.
| Name | What it is | Used for |
|---|---|---|
| React Native + Expo | Mobile framework and tooling | iOS and Android apps built with React, with native modules where needed. |
| Flutter + Dart | UI framework and language | One codebase across supported mobile, web and desktop targets. |
| Swift + SwiftUI / UIKit | Language and Apple UI frameworks | Apple-native experiences and deep platform integration. |
| Kotlin + Jetpack Compose | Language and Android UI toolkit | Android-native interfaces and platform integration. |
| Kotlin Multiplatform | Code-sharing technology | Share selected logic across platforms; the interface is a separate choice. |
| Tauri + Rust + web UI | Application toolkit | A native core with the system's own webview; platform capabilities are checked first. |
| Electron + JS/TS | Desktop framework | Desktop apps on Chromium and Node.js, trading runtime size and memory for reach. |
| Qt + C++ / Python | Application framework | Cross-platform desktop interfaces and native technical integration. |
| .NET + WinUI / WPF / Avalonia | Runtime and UI frameworks | Windows-native or selected cross-platform desktop products. |
| Godot / Unity / Unreal | Game and simulation engines | Interactive games or simulations; licensing, tooling and platform fit vary. |
| WebAssembly | Portable compilation format | Run suitable compiled modules in compatible hosts; not a speed guarantee on its own. |
| ONNX Runtime / llama.cpp | Inference runtimes | Run supported models locally, within the model's and the hardware's limits. |
| PyTorch / scikit-learn | Machine-learning libraries | Training or adapting models, or conventional machine-learning workflows. |
| Model APIs / agent SDKs | Hosted interfaces and libraries | Model inference and tools, with authentication and cost controls. |
| MCP | Tool integration protocol | Give compatible AI clients controlled access to tools and resources. |
| OpenCV / FFmpeg / OCR tools | Processing libraries and tools | Computer vision, media conversion and text extraction. |
Operations and verification
Hosting supports the product; it does not replace backups, release checks, access controls or someone responsible for maintenance.
| Name | What it is | Used for |
|---|---|---|
| Cloud infrastructure | Compute and storage from infrastructure providers | Servers, storage and managed services, with the region and recovery strategy chosen for the project. |
| Linux | Operating system family | The usual server environment; administration and patching remain our responsibility. |
| Containers | Packaging and local orchestration | Package services and define bounded multi-service deployments. |
| Container orchestration | Cluster platform | Used where the operational needs justify it; not a default. |
| Web servers and reverse proxies | Traffic handling | Routing, TLS and serving or proxying traffic. |
| DNS and content delivery | Edge and delivery services | Cache and route traffic with suitable access and security settings. |
| Infrastructure as code | Infrastructure automation | Provision and configure repeatable infrastructure. |
| Continuous integration and delivery | Delivery automation | Build, check and deploy agreed versions. |
| Metrics, traces and dashboards | Observability | Follow how systems behave and investigate problems. |
| Error tracking and structured logs | Diagnostics | Track failures, with care over what data is recorded. |
| Automated tests | Test tools | Check business rules and how the code behaves. |
| Browser and device testing | Journey checks | Walk through real journeys, permissions, saved data and compatibility. |
| OAuth, OIDC and passkeys | Identity standards | Sign-in done properly; what each person may do is still decided on the server. |
| Accessibility checks (WCAG) | Design and testing practice | Keyboard access, meaning, contrast and conformance testing. |
Terms kept straight
React is a UI library. Next.js and Astro are web frameworks. Tailwind CSS is a CSS framework. Node.js is a runtime. PostgreSQL is a database. Rust and TypeScript are programming languages. WebAssembly is a compilation format, not a programming language.
Quality comes from the work
Rust's memory safety does not make business logic secure. TypeScript types do not check untrusted requests. A database does not come with tested backups. A framework does not guarantee accessibility, search visibility or speed. That engineering and checking is part of the scope.
Choosing a web stack
Astro, Next.js and React, chosen by the work.
Our starting points for common needs. They are engineering recommendations, not rankings.
| What the site needs | Where we start | Why |
|---|---|---|
| Mostly public content: company, tourism, articles, documentation | Astro + TypeScript | HTML first, with interactive parts only where needed; server rendering is available too. |
| Accounts, transactions and personalized pages | Next.js + React + TypeScript | Its server and client conventions suit many integrated products. |
| An internal dashboard with a separate API | React + Vite or React Router | Keeps the browser interface and the server apart, with sign-in and deployment defined explicitly. |
| A public site plus a complex customer portal | An Astro site with a separate app, or one Next.js app | Decided by shared state, deployment complexity and who maintains it. |
| A storefront on an external commerce backend | Astro or Next.js | Astro can suit content-heavy storefronts; Next.js can suit tightly integrated interactions. |
| Highly interactive sections inside a content site | Astro with React, Vue or Svelte components | Only the sections that need it become interactive, instead of every page being an app. |
| A team or existing code that favours another ecosystem | Nuxt, SvelteKit, Angular or another suitable stack | Existing architecture and maintainability can outweigh a default preference. |
Common mix-ups
Next.js is not automatically faster or better for search. Astro is not limited to static pages. React can be used inside either, so React against Astro is not a like-for-like comparison. Tailwind works at the styling layer. Rust usually serves a backend, a native core or a compiled module rather than replacing the browser interface.
What decides it
Content or application behaviour; editorial workflow; sign-in and permissions; how fresh the data must be; transactions; offline needs; platform APIs; existing integrations; hosting constraints; measured performance; accessibility; maintenance; licensing and total running cost.
Example architectures
Starting points, family by family.
Plausible first designs for common situations. No project combines every technology on this page.
| Situation | A plausible architecture | Why |
|---|---|---|
| W Website for a service business | Astro + TypeScript + CSS or Tailwind + a forms API; optionally a headless CMS | Content-led public pages with limited interaction. |
| W Integrated online store | Next.js + React + a commerce API + a payment provider | Accounts, cart and checkout on a supported commerce backend. |
| A Booking portal | Next.js + TypeScript + PostgreSQL + a queue + an identity provider | Availability, reservations, permissions and notifications sent in the background. |
| A Mobile companion app | React Native with Expo, or Flutter, on a shared signed-in API | A mobile experience with its platform and offline needs stated up front. |
| B Internal operations dashboard | React + Vite + FastAPI or .NET + PostgreSQL | A separate interface and business API, with access by role and audit records. |
| I Document assistant | A Python or TypeScript API + ingestion jobs + document storage + retrieval + a model | Answers that can be traced to their source, with access control and quality evaluation. |
| M Incident review system | A React dashboard + an API + a database + a queue + a platform connector | Evidence that can be reviewed, and moderation actions under control. |
| D Local file-processing tool | Tauri + a React and TypeScript interface + Rust + SQLite | Processing that stays on the machine, in an installed product. |
| D Apple-specific native product | Swift and SwiftUI + suitable local storage and APIs | When native Apple integration is central to the experience. |
| O Managed deployment | Linux servers + a reverse proxy + CI + backups + monitoring | Infrastructure that is operated, with release and recovery procedures. |
| S Visibility and measurement | A properly rendered site + analytics + reporting in Python or TypeScript | Discovery and conversion measured from evidence. |
Migrations and integrations
A modern rebuild keeps the agreed content, important URLs, business data and working integrations, with a written migration plan and the results read back after the move. Existing systems do not need rewriting just because another stack is preferred.
Official documentation
The descriptions of the main frameworks were checked against their official documentation on 30 September 2026.
Start
Tell us what you are building.
A short description is enough. You get a straight read on scope, cost, and our honest take on the best approach, before anyone commits.
Write to [email protected] · New projects and general questions
- Built from zero, no templates
- Hosted and maintained by the same team
- Scope and cost agreed before we start
- Updates, monitoring and support after launch
- Findable in search and AI answers
