How to judge a technical proposal

Why this works without technical knowledge

You can't evaluate whether a proposed architecture is correct. You can evaluate whether the person proposing it has thought about the things that go wrong, and that turns out to be most of the signal.

Somebody who has shipped and supported a system answers these questions immediately and with specifics, because they've lived the failures. Somebody who hasn't gives a general answer that would fit any project. That difference is audible without knowing anything about software.

The six questions

1. What happens when it breaks, and who finds out first?

Good answer: names a monitoring approach, says what triggers an alert, says who receives it and how fast. Mentions the difference between the system stopping and the system carrying on while producing wrong results, which is the harder case.

Bad answer: "we'll monitor it" or "it's very reliable". Reliability is not a plan. Every system breaks and the question is about the first ten minutes afterwards.

2. Who else understands this system besides the person writing it?

Good answer: names a second person, or explains what documentation exists so somebody else could pick it up. Doesn't get defensive.

Bad answer: reassurance about the individual's skill. That's not what you asked. The risk isn't that they're bad, it's that they're unavailable.

3. What's the stack, and can I hire for it?

Good answer: names the technologies plainly, without hedging, and tells you whether the local market has people who know them. A supplier who is comfortable being replaced will answer this easily.

Bad answer: vagueness, or a stack you can't find anyone else using. Some obscure choices are correct. Almost none of them are correct for a first system in a company with no engineers.

4. What's in version one, and what's deliberately not?

Good answer: a short list of what's in, and a longer list of what's out with reasons. The second list is the one that tells you they've done this before.

Bad answer: everything is in version one. That is a proposal that has not met reality yet, and the date will move.

5. What does this cost me monthly after you've gone?

Good answer: names the hosting, the third-party services, the licences, roughly what each costs, and separates that from anything they'd charge you.

Bad answer: "just hosting, it's cheap". Ongoing cost is where badly-scoped projects become expensive, and a supplier who hasn't calculated it hasn't thought about your position after handover.

6. What would make you tell me not to do this?

Good answer: an actual example. A budget threshold, a tool that would do it off the shelf, a process that isn't stable enough to automate yet.

Bad answer: "nothing, we can build anything". That is the single strongest negative signal on this list. Everyone who has shipped has talked a client out of something, and the ones who haven't are telling you they care more about winning the work than about what happens after.

What to do with the answers

You're not scoring the technology. You're scoring specificity. Count how many of the six produced a concrete, checkable answer with a name or a number in it. Four or more is a supplier who has done this. Two or fewer is a supplier who is about to learn on your money.

The last one is the one that matters

If you only ask one, ask the sixth. A supplier willing to name the conditions under which they'd turn your project down is telling you they have a threshold, and a threshold is the only real protection you have against buying something you didn't need.