pilot-execution-recommendation

Identify the highest-risk design decisions, select minimal representative components to validate them, and define measurable success criteria. The output is a design_poc_recommendations.md document covering objectives, scope, timeline, resources, and a decision framework.

Run a PoC when the team lacks experience with the target platform, performance is uncertain, integrations are novel, data migration carries loss risk, or breaking API changes affect many consumers. Skip it for well-understood, low-risk migrations like minor version updates.

Success criteria should be specific and measurable, such as P95 latency under 200ms, unit test coverage above 80%, passing integration tests, build time under 5 minutes, and no critical dependency vulnerabilities. Failure criteria define when to stop and revise the design.

A typical PoC runs one to four weeks and is strictly time-boxed to prevent scope creep. For example, a two-week pilot might spend week one migrating scoped components and week two on testing, performance validation, and documentation.

A PoC validates specific risks with a minimal scope, not the full migration, so results may not cover every edge case. PoC code is often disposable, and skipping a PoC is reasonable for low-risk migrations or when time constraints prevent a pilot phase.