Technology Decision Guides: Which Tool We Use and When
The most expensive mistakes in software projects are not made while writing code. They are made while choosing tools. The wrong database presents its bill three years later; the wrong framework charges you every time someone new joins the team.
This page brings together the frameworks we use when making those decisions. Each one links to a full guide.
Our approach comes down to three questions: What does the client's internal team know? How long will the system live? Who maintains it after handover? Most decisions fall out of those three.
Backend and data layer
Backend framework. We use NestJS on most projects and .NET on enterprise work. Where Express is sufficient, and what an unopinionated framework costs at scale.
Choosing a Backend Stack: NestJS, Express or .NET
Database. We have recommended MongoDB on our projects for a decade. But there is a condition: you have to know NoSQL. We also cover the four cases where Postgres is genuinely the better call.
Managed backend services. Supabase and Firebase compared: SQL or NoSQL, open source or lock-in.
Architecture. When microservices win, when a monolith is the right call, and why most teams should start with a modular monolith.
Mobile
Flutter or React Native. We choose Flutter on new projects: its own rendering engine, native access through method channels, a shallower dependency tree. Including the four cases where React Native is the right call.
Artificial intelligence
Agent orchestration. LangGraph, CrewAI and AutoGen compared across eight dimensions, with architecture patterns and production observability tradeoffs.
LangGraph vs CrewAI vs AutoGen
Platform. Vertex AI, AWS Bedrock and Azure AI Foundry: model breadth, pricing, agentic orchestration.
Enterprise AI Platform Comparison
Agents or chatbots. The architectural difference, and when each one delivers real operational return.
Multi-agent architecture. Six patterns for enterprise systems: router, planner, tool-use, critic, hierarchical and swarm.
Build or buy
The investment decision. Build, buy or modify: an eight-factor matrix with a three-year total cost comparison.
Custom software or SaaS. A nine-question framework covering process repetition, data ownership and integration complexity.
The principle underneath
Every one of these choices comes back to a single test: it should keep working when another team takes over. The codebase we deliver belongs to the client, and we do not want to leave behind a system only we can understand.
If you want to work through these decisions on your own project, bring your current stack and the point that slows you down most.