Technologies
The technologies North Tech Labs uses to build custom software, mobile applications, and applied AI systems — what each one is good at, and where we'd choose something else instead.
Architecture follows the project, not the other way around
We don't start a project by picking a technology stack and fitting the product to it. We start with the business problem, the expected scale, and what already exists, then choose technology that fits those specifics. The pages below explain where each technology genuinely fits, and where it doesn't — not a generic feature list.
AI architecture pattern
- AI Agents (Architecture Pattern)The architecture pattern behind LLM-driven action-taking — a scoped tool-calling loop with permission tiers, bounded orchestration, and decision-trace evaluation — described here at the pattern level, not as a delivery offering.
- Retrieval-Augmented Generation (RAG)An architecture pattern that grounds language model output in an organisation's own documents — a retrieval pipeline and vector index engineered alongside the generation step, not a single off-the-shelf feature.
AI platform
- Anthropic (Claude)Large language model APIs from Anthropic that we integrate into business systems for document processing, long-context analysis, and agentic tool-use workflows — deployed with explicit controls, not as an unsupervised, fully autonomous layer.
- OpenAILarge language model APIs we integrate into business systems for document processing, structured extraction, and AI-assisted workflows — deployed with explicit controls, not as an unsupervised, fully autonomous layer.
Cloud infrastructure
- AWSCloud infrastructure we use to host, run, and scale backend systems, data platforms, and integration layers — selected on a project-by-project basis for what it offers, not used as an unconditional default.
- Microsoft AzureCloud infrastructure we use to host and integrate systems when a client's existing Microsoft ecosystem makes it the better technical fit — used deliberately, alongside AWS as our default cloud platform, not as an equally-weighted default of its own.
Data & infrastructure
- DockerA containerization technology we use to package applications and their dependencies into portable, reproducible units — the foundation for consistent deployments, not a full deployment or scaling strategy by itself.
- KubernetesA container orchestration platform we use to run, scale, and coordinate many containers across a cluster of machines — applied where a system's scale and complexity genuinely need it, not adopted as a default way to run containerised workloads.
- PostgreSQLA relational database we use as the primary data store for transactional systems, reporting layers, and increasingly as metadata and vector storage for AI-assisted retrieval — chosen for its consistency guarantees and relational model, not applied as an unconditional default for every kind of data.
- RedisAn in-memory data store we add to a system's architecture for caching, session storage, and lightweight queueing or pub/sub — chosen where its speed solves a specific problem, not treated as a standing default.
Backend framework
- LaravelA PHP framework we use to maintain, extend, and modernize existing Laravel applications and to support clients standardized on PHP — chosen for fit with an existing codebase or ecosystem, not applied as the studio's default for a new backend.
- NestJSAn opinionated, modular framework built on top of Node.js — chosen when a project's size, team, or lifespan benefits from enforced structure and dependency injection, rather than applied by default to every Node.js backend.
Frontend
- Next.jsA React framework we use to build production web applications — adding server-side rendering, static generation, routing, and API routes on top of React's component model, chosen when a project's performance or SEO requirements justify its conventions, not applied as an automatic default for anything built with React.
- ReactA component-based JavaScript library we use to build web user interfaces — a strong default for interactive frontends, applied with a deliberate framework and architecture choice on top of it rather than treated as a complete application solution on its own.
Not tied to a single stack
The technologies documented here are the ones we use most often, because they fit the majority of projects we take on — not a fixed stack applied regardless of requirements. Where a project's constraints call for a different technology, we say so during discovery rather than defaulting to what we know best.
Have a specific technology question?
Tell us what you're building and what constraints you're working within. We'll give you an honest read on the right technology fit, not just the one we'd prefer to use.