← All use cases · Full directory
Engineering Decision Trees
Decision trees for engineering trade-offs: API versioning, build vs buy, PR review depth, tech debt, on-call escalation. Run any tree free or embed it.
16 published trees in this category. Every one runs as a guided wizard in the browser — no signup — and can be copied as the starting point for your own version.
Trees in this category
Caching Strategy Selection
Premature or misapplied caching adds complexity — stale data bugs, invalidation logic, and distributed consistency problems — without solving the actual bottleneck. This tree routes you to the caching pattern that matches your data access profile, so you apply the right tool to the right problem rather than defaulting to Redis for everything.
CI/CD Pipeline Tool Selection
Choosing a CI/CD platform is a long-term infrastructure commitment — pipelines accumulate config, custom scripts, and team muscle memory that make switching painful. This tree eliminates tools that don't fit your source control host, infrastructure model, or team scale, leaving only the options genuinely viable for your situation.
Container Orchestration Platform Selection
Container orchestration is foundational infrastructure — the platform you choose shapes how you deploy, scale, network, and operate every service you run. This tree eliminates options that don't match your operational maturity, cloud provider commitment, and workload complexity, so you land on the platform that fits your team today without over-engineering for a scale you haven't reached.
Deployment Strategy Selection
Deployment strategy is one of the highest-leverage engineering decisions for system reliability — the wrong choice turns every release into a stressful event, while the right choice makes deployments routine. This tree routes you to the pattern that matches your infrastructure capabilities, rollback requirements, and confidence level in each release.
Frontend Framework Selection
Frontend framework choice shapes hiring, component library selection, and team conventions for years. This tree cuts through the ecosystem noise and eliminates options that don't match your rendering model, performance constraints, or team context — leaving you with a concrete shortlist rather than a five-way comparison.
How should I prioritise and address this technical debt?
Not all technical debt deserves the same response—some debt is blocking and dangerous, some is a low-priority annoyance, and some is a deliberate trade-off worth keeping on the books. This tree helps engineers and tech leads make a consistent, defensible decision about whether to fix immediately, schedule the work, formally accept the debt, or escalate to a broader architectural conversation.
How should I version my API?
Choosing the wrong API versioning strategy creates long-term maintenance pain, breaks client integrations, and can stall product evolution. This elimination tree narrows down the right approach—URI path versioning, header versioning, query parameter versioning, or a no-versioning backwards-compatibility contract—by working through the characteristics of your API, its consumers, and your team's operational constraints.
Message Queue and Event Bus Selection
Messaging infrastructure is hard to replace once services are built around it — consumer groups, retention policies, and delivery guarantees become load-bearing assumptions embedded in application code. This tree eliminates brokers that don't match your durability, routing, throughput, and operational constraints, so you choose the right foundation before building on it.
Observability Stack Selection
Observability tooling accumulates dashboards, alert configurations, and on-call runbooks that are expensive to migrate. Choosing the wrong platform means either paying for capabilities you don't need or hitting walls when debugging complex production incidents. This tree eliminates options that don't match your cloud footprint, operational capacity, and primary debugging use case.
Should we build or buy this software capability?
Deciding whether to build a capability in-house, purchase a commercial product, adopt an open-source solution, or outsource can define a product's trajectory for years. This tree guides engineering and product leaders through the key trade-offs—competitive differentiation, budget, team capacity, time-to-market, and vendor lock-in—to arrive at a defensible, context-appropriate recommendation.
What level of review does this pull request require?
Applying the same review process to every pull request wastes senior engineering time on trivial changes and under-scrutinises high-risk ones. This tree helps engineers and tech leads determine the appropriate level of review—from self-merge for genuine production hotfixes to full architect sign-off for cross-cutting changes—based on urgency, size, risk, and service boundaries.
Which API design pattern is right for my project?
Determine the right API design style for your integration scenario.
Which API design pattern is right for my project?
Determine the right API design style for your integration scenario.
Which cloud provider should I use — AWS, Azure, or Google Cloud?
Answer a few questions to identify the most suitable cloud platform for your workload.
Which database engine should I use for my application?
Narrow down the right database engine for your project by answering a series of questions about access patterns, consistency requirements, and scale.
Who should I escalate this on-call incident to?
Every minute an on-call engineer spends deciding who to call is a minute not spent fixing the problem—but over-escalating creates alert fatigue and erodes trust in the paging system. This tree gives on-call engineers a fast, consistent framework for deciding whether to handle an issue solo, wake a secondary, page their engineering lead, or trigger a full incident response with executive and communications involvement.
All Engineering trees
- Caching Strategy Selection — Premature or misapplied caching adds complexity — stale data bugs, invalidation logic, and distributed consistency problems — without solving the actual bottleneck. This tree routes you to the caching pattern that matches your data access profile, so you apply the right tool to the right problem rather than defaulting to Redis for everything.
- CI/CD Pipeline Tool Selection — Choosing a CI/CD platform is a long-term infrastructure commitment — pipelines accumulate config, custom scripts, and team muscle memory that make switching painful. This tree eliminates tools that don't fit your source control host, infrastructure model, or team scale, leaving only the options genuinely viable for your situation.
- Container Orchestration Platform Selection — Container orchestration is foundational infrastructure — the platform you choose shapes how you deploy, scale, network, and operate every service you run. This tree eliminates options that don't match your operational maturity, cloud provider commitment, and workload complexity, so you land on the platform that fits your team today without over-engineering for a scale you haven't reached.
- Deployment Strategy Selection — Deployment strategy is one of the highest-leverage engineering decisions for system reliability — the wrong choice turns every release into a stressful event, while the right choice makes deployments routine. This tree routes you to the pattern that matches your infrastructure capabilities, rollback requirements, and confidence level in each release.
- Frontend Framework Selection — Frontend framework choice shapes hiring, component library selection, and team conventions for years. This tree cuts through the ecosystem noise and eliminates options that don't match your rendering model, performance constraints, or team context — leaving you with a concrete shortlist rather than a five-way comparison.
- How should I prioritise and address this technical debt? — Not all technical debt deserves the same response—some debt is blocking and dangerous, some is a low-priority annoyance, and some is a deliberate trade-off worth keeping on the books. This tree helps engineers and tech leads make a consistent, defensible decision about whether to fix immediately, schedule the work, formally accept the debt, or escalate to a broader architectural conversation.
- How should I version my API? — Choosing the wrong API versioning strategy creates long-term maintenance pain, breaks client integrations, and can stall product evolution. This elimination tree narrows down the right approach—URI path versioning, header versioning, query parameter versioning, or a no-versioning backwards-compatibility contract—by working through the characteristics of your API, its consumers, and your team's operational constraints.
- Message Queue and Event Bus Selection — Messaging infrastructure is hard to replace once services are built around it — consumer groups, retention policies, and delivery guarantees become load-bearing assumptions embedded in application code. This tree eliminates brokers that don't match your durability, routing, throughput, and operational constraints, so you choose the right foundation before building on it.
- Observability Stack Selection — Observability tooling accumulates dashboards, alert configurations, and on-call runbooks that are expensive to migrate. Choosing the wrong platform means either paying for capabilities you don't need or hitting walls when debugging complex production incidents. This tree eliminates options that don't match your cloud footprint, operational capacity, and primary debugging use case.
- Should we build or buy this software capability? — Deciding whether to build a capability in-house, purchase a commercial product, adopt an open-source solution, or outsource can define a product's trajectory for years. This tree guides engineering and product leaders through the key trade-offs—competitive differentiation, budget, team capacity, time-to-market, and vendor lock-in—to arrive at a defensible, context-appropriate recommendation.
- What level of review does this pull request require? — Applying the same review process to every pull request wastes senior engineering time on trivial changes and under-scrutinises high-risk ones. This tree helps engineers and tech leads determine the appropriate level of review—from self-merge for genuine production hotfixes to full architect sign-off for cross-cutting changes—based on urgency, size, risk, and service boundaries.
- Which API design pattern is right for my project? — Determine the right API design style for your integration scenario.
- Which API design pattern is right for my project? — Determine the right API design style for your integration scenario.
- Which cloud provider should I use — AWS, Azure, or Google Cloud? — Answer a few questions to identify the most suitable cloud platform for your workload.
- Which database engine should I use for my application? — Narrow down the right database engine for your project by answering a series of questions about access patterns, consistency requirements, and scale.
- Who should I escalate this on-call incident to? — Every minute an on-call engineer spends deciding who to call is a minute not spent fixing the problem—but over-escalating creates alert fatigue and erodes trust in the paging system. This tree gives on-call engineers a fast, consistent framework for deciding whether to handle an issue solo, wake a secondary, page their engineering lead, or trigger a full incident response with executive and communications involvement.
How to use these trees
- Run one to see how the questions are ordered and where each path ends.
- Copy the source. Every tree is plain text, so you can lift it and edit the wording for your own organisation. Syntax reference →
- Embed it in your wiki, help centre, or intranet with one snippet that stays current whenever you edit the tree. Embedding guide →