Argue a design with three people who want different things
We could build this, and I cannot tell whether we should.
Build against buy is rarely a technical argument
The technical comparison is usually the easy half and it is the half that gets written down. The decision turns on the parts that are not in the document: what it costs to keep running, who is on call for it, and whether the team you actually have can ship it alongside everything else they owe.
A design review inside one team tends to converge, because everybody in the room shares a set of priorities and a recent history. A review by one assistant converges faster, for the same reason with fewer people.
What is missing is somebody in the conversation who would lose something by agreeing with you.
What the room does with a design
You describe the system or the choice as you would to a peer, plus the constraint you designed against and the failure you would be most embarrassed by. The advisers read it and arrive with different priorities.
One asks what happens under load and at failure. One asks what it costs to run and how long the cash lasts if the answer is more than you think. One asks whether the team can ship it at all, which is the question that usually decides it and the one nobody in the original review was incentivised to raise.
The three argue with each other rather than taking turns to comment. Where two of them price the same constraint differently, you have found the part of the design that is actually load bearing.
There is no architecture description on this site and there will not be one. What the room does with your design is the product. How the room itself is built is not something a marketing page is qualified to explain, and a diagram of our own infrastructure would tell you nothing about whether the argument is any good.
The build against buy brief
An engineering lead choosing between building a component and paying for one, or defending a design that nobody senior has read yet.
- The system or the choice under review, described as it would be to a peer.
- The constraint you designed against, and where it came from.
- What you are choosing not to build, and why that is safe.
- The failure mode you would be most embarrassed by.
- What this costs to run, and who pays for it.
- The part of this you would change if the team were twice the size.
The advisers do not share your priorities. One will ask what happens under load, one will ask what it costs to keep running, one will ask whether the team can ship it at all. Expect the design conversation to become a staffing conversation, which is usually where it should have started.
Not yet produced
The strip for this use case, cut from a session about this kind of problem. No session of any kind has been recorded, so there is nothing to cut, and a reconstruction of a use case we have never seen anyone attempt would be an invention rather than an illustration.
Before you start
The advisers do not read code, do not have access to your repository and know only what is in the brief. They will invent a number if the brief gives them room to, which has happened in our own testing and is written up rather than hidden.