Home → Technology
TECHNOLOGYThe stack, and why each thing is on it.
A technology list tells you nothing on its own — every agency has one, and they mostly look the same. What matters is the reasoning: when we’d choose each of these, when we wouldn’t, and what we’d tell you to avoid. That’s what’s below.
Four things decide the stack. None of them is what we enjoy using.
Your load profile
Users, transactions, data volume and growth at launch and at 10x. A system serving 200 internal users and one serving 200,000 public visitors are different problems, and over-engineering the first is as much a mistake as under-engineering the second.
Who maintains it after us
If you have an in-house team, we build in what they know. If you’ll hire later, we choose technologies with a deep hiring pool in your market. A stack only we can maintain is a liability regardless of its technical merit.
Five-year cost
Licence fees, hosting, the maintenance burden of the dependency tree, and how expensive the likely migrations are. Cheap to build and expensive to run is a bad trade that shows up on year two’s budget.
Maturity and support
We don’t put client systems on technology that might be abandoned. Interesting isn’t a criterion. Boring, well-documented and widely adopted usually wins.
Every recommendation is written into the architecture brief during discovery, with the reasoning. If you disagree with a choice, that’s a conversation before development starts — not a discovery afterwards.
Frontend
→ Web Development| TECHNOLOGY | WHEN WE USE IT |
|---|---|
| Next.js | Our default for most web work. Server-side rendering gives fast first paint and reliable indexability in one framework — the two things that matter most for public-facing sites. |
| React | The component layer underneath most of what we build. Large hiring pool, mature ecosystem, easy for your team to pick up. |
| Angular | When you have an existing Angular estate or an enterprise team fluent in it. Strong for large, structured internal applications with long lifespans. |
| TypeScript | On everything. The upfront cost is small; the reduction in runtime errors and the improvement in maintainability are not. |
| Tailwind CSS | Fast, consistent styling that doesn’t accumulate dead CSS. Paired with a documented component system so it stays disciplined. |
Backend
→ SaaS Engineering| TECHNOLOGY | WHEN WE USE IT |
|---|---|
| Node.js | Shared language with the frontend, strong for I/O-heavy APIs and real-time features. Our default for JavaScript-stack products. |
| Python / Django | Data-heavy applications, complex business logic, or anything adjacent to ML and analytics. Django’s admin and ORM save real time on internal tooling. |
| PHP / Laravel | Robust application backends at lower cost, and extending existing PHP estates. Widely underrated and very easy to hire for. |
| Go | High-throughput services where concurrency and predictable latency matter. Used selectively, not by default. |
| REST & GraphQL | REST for most APIs — simpler to cache, document and debug. GraphQL when clients need flexible queries across related data, typically multi-surface products. |
Mobile
→ App Development| TECHNOLOGY | WHEN WE USE IT |
|---|---|
| Flutter | Our default for business apps. One codebase, both platforms, and a rendering model that holds 60fps on mid-range devices reliably. |
| React Native | When your team already works in React or you’re sharing significant logic with an existing React application. |
| Swift / Kotlin | Deep platform integration — advanced camera, background processing, Bluetooth, hardware — or single-platform builds needing maximum control. |
Data
→ ERP Solutions| TECHNOLOGY | WHEN WE USE IT |
|---|---|
| PostgreSQL | Our default database. Relational integrity, strong JSON support, mature tooling, excellent under load. Most projects should use it, and most do. |
| MongoDB | Genuinely document-shaped data with varying structure. Chosen deliberately, not as a default — relational data in a document store causes problems later. |
| Redis | Caching, sessions, queues, rate limiting, materialised read projections. |
| ClickHouse | Analytical workloads over large event data where a transactional database would degrade under reporting queries. |
| Elasticsearch | Full-text and faceted search at scale, typically large catalogues. |
Cloud & DevOps
| TECHNOLOGY | WHEN WE USE IT |
|---|---|
| AWS | Default for most production infrastructure. Breadth of services and the deepest operational hiring pool. |
| Google Cloud | Data and ML-heavy workloads, or where you’re already in the Google ecosystem. |
| Docker | Everything. Consistent environments from local development to production. |
| Kubernetes | Only when scale genuinely warrants it. It carries real operational overhead and is frequently adopted far too early — we’ll say so if that’s the situation. |
| Terraform | Infrastructure as code, so environments are reproducible and reviewable rather than configured by hand. |
| GitHub Actions | CI/CD pipelines, automated testing, staged deployment with rollback. |
On hosting: we deploy to your cloud accounts by default. You own the infrastructure, the billing relationship and the ability to revoke our access at any time.
AI & Machine Learning
→ AI & Automation| TECHNOLOGY | WHEN WE USE IT |
|---|---|
| Python | The default for anything involving data or modelling. Pandas, scikit-learn, FastAPI. |
| PyTorch / TensorFlow | Custom model training where an off-the-shelf model doesn’t fit the domain. |
| LangChain & LLM APIs | Agents, retrieval over your own documents, classification, summarisation. Where most current business value actually sits. |
| Vector databases | Semantic search and retrieval across large document sets. |
| Self-hosted models | When data sensitivity requires that nothing leaves your infrastructure. Real trade-off — generally lower capability at higher infrastructure cost, and we’ll set that out plainly. |
Platforms we implement
We’re not a custom-only shop. When a platform fits the requirement, it’s the better answer, and the recommendation follows your situation rather than our margin.
| PLATFORM | WHEN WE RECOMMEND IT |
|---|---|
| WordPress | Content and marketing are the priority and requirements are standard. Built as a custom theme with minimal plugins — not a page-builder stack. |
| Shopify / Shopify Plus | Most ecommerce businesses. Fastest path to a good store, and your team can run it without developers. |
| BigCommerce | Strong native B2B and multi-channel needs without heavy app dependency. |
| Magento / Adobe Commerce | Complex catalogue rules and deep B2B pricing tiers, or extending an existing Magento estate. Higher build and maintenance cost — justified less often than assumed. |
| ERPNext | Our default ERP recommendation. Open source, no per-seat licence, broad module coverage, straightforward to extend. |
| GoHighLevel | Marketing funnels, landing pages and CRM automation where speed to market beats bespoke architecture. |
What we steer clients away from.
Page-builder plugin stacks
Not page builders as a category — the specific pattern of stacking a builder plus fifteen plugins to reach a requirement. The cost shows up as performance and maintenance rather than on the invoice.
Kubernetes before you need it
Adopted at the wrong stage, it adds substantial operational burden for no benefit. Most applications should run on managed services for years first.
Microservices as a starting architecture
A well-structured monolith is easier to build, deploy, debug and hire for. Split services out when a specific scaling or team-boundary reason exists — not on principle.
NoSQL for relational data
Choosing a document store for data with genuine relationships creates problems that surface eighteen months in, when they’re expensive.
Frameworks with a thin ecosystem
Interesting technology with a small community means a small hiring pool and uncertain longevity. Not a risk worth taking with someone else’s business.
Anything only we can maintain
If a choice would make you dependent on us specifically, it’s the wrong choice.
If you need something not on this list.
This list reflects where we have depth, not the boundary of what we’ll take on. If your project needs something adjacent, we’ll say so honestly and tell you whether we’re the right people — including when the answer is no.
What we won’t do is take a project requiring technology we don’t know and learn it on your budget without telling you. If there’s a gap, you’ll hear about it during discovery, and we’ll either bring in a specialist or recommend someone better placed.
Questions about the stack.
Can we choose the technology stack?+
Yes, and plenty of clients do — usually because they have an in-house team or an existing estate. We’ll build in your stack and flag any concerns in writing beforehand.
What if we already have a team using something else?+
We build in what they know. A system your team can maintain is worth more than one built on our preferred tools, and this is a large part of why we ask about your team during discovery.
How do you avoid locking us in?+
Standard, widely-adopted technologies, documented architecture, code in your repositories, infrastructure in your cloud accounts. Any competent team can take over. That’s a deliberate design constraint, not a courtesy.
Do you keep up with new technology?+
Selectively. We evaluate continuously and adopt slowly, because client systems are the wrong place to test whether something has staying power. New tools reach client projects once they’re proven, documented and hireable.
Which database should we use?+
PostgreSQL, most likely. It handles relational and document workloads well, scales further than most projects need, and has excellent tooling. Alternatives need a specific reason, which we’ll set out if one applies.
Want the reasoning for your specific project?
Discovery produces a written architecture brief with the stack recommendation and the reasoning behind every choice. It’s yours to keep — you could hand it to another agency and get a comparable quote. That’s deliberate.