TSD Generator
Write the functional requirement once. Get a complete, well-structured Technical Solution Design scaffold in Markdown — your words kept verbatim, with specific guidance in every other section.
Designs written by hand drift: different structure, different depth, and sometimes the section that would have caught a production problem is simply missing. This tool fixes the structure instead. Your requirement goes in word for word; every unfilled section carries a note saying exactly what belongs there. Paste the file into your repository and write it in your editor — an assistant such as GitHub Copilot can draft from those notes, and they read just as well if you never use one.
The thinking behind this tool is written up as a study: Using AI as a consistency engine for architecture work. Prefer the raw files? The templates are on GitHub — fork them and make them your team’s standard.
Everything stays in your browser. Inputs are saved locally so a refresh loses nothing; no data is sent anywhere.
A short name for the change, as it would appear in a backlog.
The only input that matters. Write the requirement in as much detail as you have — what the feature does, for whom, and any rules you already know. It goes into the document word for word; the guidance comments handle the rest.
Options
All optional. The defaults produce a complete scaffold.
Only if the project uses a layered platform — for example: Core, Brand, Market, Site. Leave blank to omit the impacted-layers section.
Repeats the integration table this many times.
Generated scaffold
25 sections · 0 seeded from your input · 25 carrying guidance
Next: save this file in your repository, open it in your editor, and let your AI assistant expand each section from its guidance. The prompt version is for people who prefer a chat assistant.
Want this as a team standard? The templates are on GitHub
An assistant will fill these sections with confident text that is sometimes wrong. Review every section it writes: the structure is automated, the judgement is not.
# Technical Solution Design — Untitled feature | Field | Value | | --- | --- | | Author | | | Related ticket | | | Version | | ## Approvals > **What to write here.** List who must approve this design. Keep roles generic — for example "Lead architect" or "Platform owner". | Role | Name | Status | | --- | --- | --- | | Lead architect | | Pending | ## Version log | Version | Date | Author | What changed | | --- | --- | --- | --- | | 1 | 2026-08-13 | | Initial draft | ## Functional requirement > **What to write here.** Paste the requirement for this feature here, in the words it was given to you. Everything below is expanded from this, so the more detail it carries the better the rest of the document will be. ## Purpose > **What to write here.** Using the functional requirement above, describe the purpose of this feature: what it does, for whom, and why now. Keep it in words a product owner would agree with. ## Scope > **What to write here.** Using the functional requirement above, state which parts of the system change for this feature — and just as important, which do not. Name what is explicitly out of scope. ## High-level design > **What to write here.** Describe the shape of the solution for this feature in plain words: the main parts, how they interact, and where the boundaries are. No code. ## Multi-site and multi-brand impact > **What to write here.** State whether this feature affects one site or many. Is the change shared or overridden per site? Will a future fix reach every site automatically, or must it be applied N times? ## Options considered and rejected > **What to write here.** List at least one alternative design for this feature and the reason it was not chosen. A design with no rejected options usually means the thinking has not been done. ## Storefront changes > **What to write here.** List the customer-facing touch points this feature changes: which pages or flows (product page, listing, cart, checkout, account) and what changes on each. ## Backend changes > **What to write here.** Describe the server-side work for this feature: scheduled jobs, service calls, business logic. Name anything that runs while a customer is waiting — that is the critical path. ## File changes > **What to write here.** List every file this feature touches, one row each. Status is NEW, UPDATE or RE-USE. Naming RE-USE matters: it shows existing code was checked before writing new code. | Status | File | What changes | | --- | --- | --- | | NEW | path/to/file.js | What is added, without code blocks | ## Dependencies > **What to write here.** List the features, teams, libraries or releases this feature depends on — and anything that depends on it. ## Interfaces and integrations > **What to write here.** For each integration of this feature, complete the table: all eight rows. The last three — timeout, failover behaviour and authentication — are the ones that prevent outages. Add an interaction diagram description showing browser, platform and external system as actors. ### Integration 1 | Field | Details | | --- | --- | | Description | | | Communication protocol | | | Data format | | | Sample request | | | Sample response | | | Timeout | | | Failover behaviour | | | Authentication method | | ## Data > **What to write here.** Describe the data this feature creates, reads or changes. Which system is the source of truth for it, and is anything shared across sites? ## Error handling and failover > **What to write here.** List the failure scenarios for this feature — service down, bad data, timeout — and the expected behaviour for each: what the customer sees, and what the system does. ## Caching > **What to write here.** Describe the caching strategy for this feature. State what is cached, for how long, and what must never be cached because it is personalised. ## Performance impact > **What to write here.** State the performance cost of this feature: extra calls per page, job run time, quota use. Size it for peak traffic, not a quiet day. ## Security > **What to write here.** State the security considerations for this feature: secrets and where they live, encryption, what must never appear in logs, and who can call any new endpoints. ## Privacy and data protection > **What to write here.** State what personal data this feature touches, the lawful basis, any consent it depends on, how long data is kept, and how a data-subject request (access or deletion) would be served. ## Accessibility > **What to write here.** State what this feature does that affects accessibility: keyboard use, focus, contrast, announcements. Which third-party components are involved, does a shared component carry the fix to every site, and who owns it? Accessibility is decided here, in the architecture — long before anyone runs a scanner — and in the EU it is a legal obligation. ## Observability > **What to write here.** State what this feature logs, what is monitored, and what alerts exist. How would someone detect that this feature has failed in production before a customer reports it? ## Rollout strategy > **What to write here.** State how this feature reaches production: feature flag or not, phased or all at once — and for a multi-site estate, the order in which sites and markets receive it, and why that order. ## Rollback plan > **What to write here.** State what happens if this feature fails after release. Can it be switched off without a deployment? Is rollback still safe once real data has been written? ## How to test > **What to write here.** Write tutorial-like steps to test this feature, positive and negative: required setup, how to test the service calls, and the failure cases — bad data, empty tokens, no response, permission denied. ## Success criteria > **What to write here.** State how you will know this feature worked, beyond “it shipped”: a number, a behaviour, or a complaint that stops happening. ## Risks and assumptions > **What to write here.** Different from open issues: list what this feature assumes to be true, and what would hurt if it is not. Name the assumption nobody has checked. ## Open issues > **What to write here.** List the questions about this feature still waiting for an answer: who needs to answer, and about which requirement. --- **Every section an assistant expands must be reviewed by the author. It will produce confident text that is wrong. The structure is automated; the judgement is not.** _Generated with the document scaffold tools at commerceatscale.com. Nothing was sent to a server; all content stayed in the browser._