Architecture Decision Records are one of the better habits a team can pick up. When you choose a database, a messaging pattern, or a service boundary, an ADR captures the call and the reasoning in a durable place. If your team writes them, keep writing them. This is not an argument against ADRs. It is an argument that they cover a narrow slice of the decisions that actually cost you time.
What ADRs are good at
ADRs work because architecture decisions have the right shape for them. They are big, they are relatively rare, and they are clearly decisions. Choosing Postgres over a document store is obviously a moment that deserves a record. It is weighty enough that someone will take the ten minutes to write it up, and stable enough that the record stays useful for years. The format fits the thing.
The decisions ADRs miss
The trouble is that most decisions do not look like that. They are small, frequent, and only obvious as decisions in hindsight. A few that no ADR ever captures:
- Why a field is nullable. Someone made that call for a reason. It is not architecture, so it never got an ADR, and now it is a mystery that a code reviewer has to ask about.
- Why a retry is set to three, not five. A real decision, tuned against a real problem, invisible the moment the person who tuned it moves on.
- Why this endpoint stayed synchronous. Discussed once, decided in a thread, never formal enough for an ADR.
- Why we dropped the caching layer we built. A rejected approach, which is exactly the knowledge people most need and least often record.
- Why the migration ran in two steps. An operational call with real reasoning that leaves no trace in the schema.
None of these are architecture. All of them generate the same interruption months later: someone stops, cannot find the reason, and pings whoever might remember.
Why they fall through
Two things push these decisions out of the ADR net. First, they do not feel big enough. Nobody opens the ADR folder and writes a formal record for a nullable column, and they are right not to; the ceremony does not fit a two-minute call. Second, there are too many of them. You make dozens of small decisions a day. Even a lightweight ADR process cannot absorb that volume without becoming a full-time job.
So the small decisions stay where they were made: in threads, in pull request comments, in someone's memory. Which is fine until that someone is out, or gone, and the reasoning goes with them.
What the rest needs instead
The everyday decisions need the opposite of an ADR's formality. They need a capture method with almost no friction, one that fits the flow of work rather than interrupting it, and one that produces something a teammate can actually retrieve later without asking a person. The bar is not "write a record." The bar is "leave enough of a trail that the next question finds an answer instead of a person."
The parts still matter, they are just lighter: what you decided, why, and what you ruled out. But the act of capturing has to cost seconds, not minutes, or it will not happen at the volume these decisions occur.
The two-layer habit
The healthiest setup is two layers, not one. Keep ADRs for the big architectural calls that deserve a formal, permanent record. Add a low-friction daily habit for everything else, the hundred small reasons that shape the system just as much but never clear the ADR bar.
StandIn is built for that second layer. You write one short brief at the end of your day, in plain words, including the small calls you made and why. While you are off, it answers teammates from what you wrote, with a source and a date under each answer, and when the reason was never recorded it says so instead of guessing. It does not replace your ADRs, and it should not. It covers the decisions that were never going to get an ADR in the first place, which is most of them.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.