The Five Questions I Ask Before Building Any System

Most systems fail not because the technology was wrong, but because the problem wasn't understood clearly enough before building began. The architecture decisions that matter most are made in the first few hours of a project — often before a single line of code or a single automation step is written.

Over time, I've developed five questions I ask at the start of every project. They're not a framework. They're pressure tests. Each one is designed to expose an assumption that, if left unchecked, will cause problems later.

1. What is the actual constraint?

Not the symptom. Not the tool that's frustrating people. The actual constraint — the point in the process where work accumulates, slows down, or disappears. In almost every project I've worked on, the stated problem and the actual constraint are different things. Someone says "we need a better database" and the real problem is that data is being entered inconsistently at the source. Someone says "we need automation" and the real problem is that nobody has agreed on what the output should look like.

Finding the actual constraint usually requires ignoring the first answer and asking again.

2. What does success look like at 3am?

Every system will run without supervision. The question is what it does when something goes wrong and nobody is watching. Does it fail gracefully? Does it alert someone? Does it keep running in a degraded mode until a human can intervene? Does it corrupt data silently?

Designing for the 3am scenario forces you to think about error states, retry logic, monitoring, and alerting as first-class concerns — not afterthoughts. A system that works perfectly in the demo and fails silently in production hasn't solved the problem.

3. Where does human judgment create the most value?

Automation should be applied aggressively to the predictable and rule-based. But every system has points where human judgment adds irreplaceable value — where the edge case is too nuanced, the stakes too high, or the context too ambiguous for a machine to handle reliably.

Identifying those points before building determines the architecture. The system should route those decisions to humans efficiently — with the right context, at the right moment, through the right channel. Everything else is a candidate for automation.

4. What does this system look like in two years?

Not because I need to build for two years from now — I don't. But because thinking about where a system needs to go reveals architectural decisions that are cheap to make correctly at the start and expensive to change later. Database schema. API design. The way records are linked. The way errors are logged. These things compound.

A system designed only for today's scale will be replaced. A system designed with tomorrow's constraints in mind will be extended.

5. What happens when the inputs change?

Every system assumes something about its inputs. The barcode is always valid. The API always returns the expected schema. The file is always in the right format. Those assumptions will be violated. The question is whether the system handles that gracefully or breaks.

Asking this question before building forces you to design input validation, normalization, and fallback handling as part of the core architecture. It's the difference between a system that needs constant maintenance and one that handles real-world variability without intervention.

The answers are the architecture

By the time I've worked through these five questions with a clear head, the shape of the system is usually obvious. The technology choices follow from the answers — not the other way around. That's the order that works.