technical-feasibility-study

## Purpose Prevent the most expensive engineering failure mode: committing significant resources to a direction that was never viable. A technical feasibility study is not a design document - it does not specify how to build something. It answers the prior question: **should we build it this way at all?** ## Input **Works best with:** A description of the proposed concept, approach, or technology being evaluated. **Also valuable:** Timeline constraints, team skills inventory, existing tech stack, budget limits, regulatory environment. **Example invocation:** `Assess the feasibility of building a real-time fraud detection engine using stream processing for our payment gateway, given our team of 3 PHP engineers and a 4-month delivery window.` ## Key Concepts ### Four Feasibility Dimensions **1. Technical Feasibility** Can this be built with available or acquirable technology? Does the proposed solution have proven precedent at similar scale? Are there known technical blockers? **2. Resource Feasibility** Do we have - or can we acquire - the engineering skills, infrastructure, and budget required? What is the realistic timeline given current team capacity? **3. Operational Feasibility** Once built, can we operate, monitor, and maintain this system? Does it integrate with existing monitoring, deployment, and support processes? **4. Risk Feasibility** What are the critical failure modes? What is the fallback if this approach does not work? What is the blast radius of a f...