sa-daily-toolkit

A solutions architect switches context all day. Morning is one team's security review, afternoon is a sizing exercise for another, and by the end of the day someone needs a three-service comparison to close an RFC. Every one of those requests produces an artifact — and without a standard, every artifact is born different: an ADR becomes a chat thread, a threat model becomes four slides, a decision matrix becomes a spreadsheet nobody opens again.

The cost doesn't show up on the day the artifact is written — it shows up six months later, when someone needs to understand why that decision was made and finds nothing beyond a meeting summary. After years operating platforms where old decisions come back as incidents, I've learned that traceability is the only durable output of architecture work. The diagram ages; the record of why it has that shape does not.

This repository is my answer: a small, opinionated kit with one template per artifact type, so the cognitive cost of producing something good is low enough that I produce it every time, not only when there's time to spare.

There is no backend and no AWS account involved. The toolkit is a Next.js 16 (App Router) application with React 19, TypeScript 5 and Tailwind CSS 4, living entirely in frontend/. Each skill is a page: you fill in the fields, the page assembles the artifact, and you carry the result into the real project's repository — the toolkit generates but does not store. That choice is deliberate: an ADR belongs next to the code it explains, not inside a tool that may disappear.

docs/ holds the project's own architecture, ADRs and diagrams — the kit applies to itself what it recommends. .github/workflows/ has four pipelines: CI (typecheck and build), Frontend, Vercel (deploy) and Security (dependency and secret scanning). Production runs on Vercel with DNS on Cloudflare; OPERATIONS.md documents GitFlow, Vercel secrets and the security pipeline, and SETUP.md shows how to wire Vercel and Cloudflare from scratch.

Maintenance cost is what drove this design: a static app on a managed platform has no server to patch, no database to back up and no key to rotate. What needs care is only what always does — dependencies and the content of the templates themselves.

ADR: only for decisions whose cost to reverse exceeds the cost of writing. Picking a date library doesn't deserve an ADR; choosing between one and several AWS Organizations does. The MADR template forces you to list the options that lost — that's what a future reader is looking for, not the winner.

Well-Architected: the checklist goes in before go-live, with an owner per item. An item without an owner is an item ticked and not done.

Threat modeling with an LLM: the prompt produces a long list of threats in minutes, and that's where the risk lives — the list looks complete and isn't. I treat the output as a draft: cut what doesn't apply to the real perimeter, add what the model can't see (the onboarding process, the vendor's access, the static key nobody rotates), and only then does the document exist. The model enumerates; the accountability stays with me.

Decision matrix: the step that matters is assigning weights before scoring the options. A weight set after the score becomes retroactive justification for the option you already wanted — and the matrix, which existed to expose bias, starts hiding it.

Sizing: the calculator returns a starting number, not a verdict. It knows nothing about the traffic pattern, the seasonal peak or the reservation finance already bought. Use the number to open the conversation with the people who operate the system, not to close it.