Technical design document draft

Draft a design doc with goals, options, a recommendation and risks, ready for team review.

LLazyPrompt(@lazyprompt)CodingPlanWorks with any model
Prompt template
Draft a technical design document for the following.

Problem or feature: {{problem}}
Background and current system: {{background}}
Constraints (deadline, team, budget, tech, compliance): {{constraints}}
Options I am already considering: {{options}}
Audience: {{audience}}

Structure the document with:
1. Summary: three sentences, readable alone.
2. Context and problem: why this matters now and what happens if we do nothing.
3. Goals and non-goals: measurable goals; non-goals that prevent scope arguments.
4. Proposed design: components, data flow, key interfaces or data models, and a simple text diagram if useful.
5. Alternatives considered: at least two, including my options, each with an honest comparison and the reason it was not chosen.
6. Key tradeoffs and open questions: what we are giving up, and the questions reviewers must answer.
7. Rollout plan: phases, feature flags, migration, backward compatibility and how to roll back.
8. Testing and observability: how we will know it works in production, with specific metrics and alerts.
9. Risks and mitigations.
10. Effort estimate in rough ranges with the assumptions behind them.

Be specific and direct. Where my input lacks a fact you need, write the assumption in a bold "Assumption:" line rather than inventing details. Do not pad sections that do not apply.
Example output
# Design: Order status webhooks **Summary.** We will send signed HTTP webhooks when an order changes status, using a transactional outbox so events are never lost and checkout latency is unaffected. A worker delivers events with retries. Estimated 4-5 weeks for two engineers. **Goals:** deliver 99.9% of events within 30 s; no checkout latency increase above 5 ms. **Non-goals:** a customer-facing event log UI; event types beyond order status. **Proposed design.** In the same transaction as the status update, insert a row into `outbox_events`. A worker polls (`FOR UPDATE SKIP LOCKED`), signs the payload with HMAC-SHA256 and POSTs to each subscribed endpoint. **Alternatives** | Option | Pros | Cons | |---|---|---| | Inline HTTP calls | Simplest | Slow endpoints block checkout; events lost on crash | | Outbox + worker (chosen) | Reliable, isolated | New worker to run | | Managed service | Fast to ship | Cost, data leaves our network | **Open questions:** retry schedule and when to disable a failing endpoint. **Rollout:** behind a flag per account; start with internal accounts. **Observability:** delivery latency, failure rate, outbox depth with alert at 1,000 rows. **Assumption:** peak is under 50 events per second.

Why it works

The mandatory alternatives and non-goals sections force real tradeoff thinking, and marked assumptions keep invented details visible. Paste real schemas or code in the background for a more accurate design.

Licensed CC0 (public domain) Version 1 · history