Architecture Decisions I Would Defend in Due Diligence

Most architecture writing is about what to build. Very little of it is about what happens when somebody serious sits down to evaluate what you built. I have been on both sides of that conversation, and the questions are never the ones engineers prepare for.

Nobody Asks If The Code Is Clean

A technical reviewer doing diligence has limited time and a specific job: find the things that will cost money later. Clean code is nice, and it correlates with good outcomes, but it is not what gets probed. What gets probed is risk.

The questions that actually come up:

• What breaks if the person who wrote this leaves tomorrow?
• Where does the data live, who can reach it, and can you prove that?
• What is the deployment story, and has anyone other than the author done it?
• Which third party services are load bearing, and what is the plan if one changes terms?
• How do you know the system is working right now?

None of those are about elegance. All of them are about whether the system is a business asset or a personal project that happens to have users.

Boring Choices Survive Scrutiny

The decisions I am most comfortable defending are, almost without exception, the least interesting ones I made.

A relational database with a normalised schema and real foreign keys. Not because relational is universally correct, but because when somebody asks "can you show me how a customer relates to an invoice", the answer is a diagram rather than a story about eventual consistency. Constraints in the database rather than only in application code, because application code is one deploy away from being bypassed and a constraint is not.

Server rendered pages where SEO or first paint matters, client rendering where interactivity matters, and a clear reason for each. A reviewer does not mind either choice. They mind not being able to tell which one you made or why.

One deployment target per environment, with the same pipeline for all of them. Staging that genuinely mirrors production rather than staging that is production with a different database and four undocumented differences that surface during an incident.

The pattern here is not conservatism for its own sake. It is that novel architecture spends credibility. Every unusual choice is one you will have to explain and justify, and you have a finite amount of explaining before a reviewer concludes the system is idiosyncratic. Spend that budget on the two or three places where the problem genuinely required something unusual, and take the boring option everywhere else.

The Questions That Expose Real Problems

Two questions in particular tend to find the soft spots.

"Walk me through what happens when a request comes in." This sounds gentle. It is not. Answering it properly requires you to have a coherent mental model of the whole path: routing, auth, validation, business logic, persistence, response. If there are layers that exist for historical reasons, or two competing ways of doing the same thing, this question surfaces them within about ninety seconds. I have watched capable engineers discover their own architecture's incoherence while answering it out loud.

"What is the oldest piece of this you are afraid to touch?" Every system has one. The honest answer is more useful than the confident one, and an experienced reviewer knows that a team claiming there is nothing scary either does not know their codebase or is not telling the truth. What they are actually assessing is whether you have a plan for it and whether it is contained.

Ownership Is An Architecture Concern

This is the part engineers routinely underrate, and it is the first thing a buyer checks.

Who owns the cloud account. Whose name is on the domain. Where the DNS is managed. Who can rotate the credentials. Whether the repository is in an organisation or in someone's personal account. Whether there is a single administrator whose departure would lock everyone out.

I set every client engagement up so the client owns all of it from the first day. Their cloud account, their domain, their repository organisation, their secrets. I get access as a member, not as the owner. This costs slightly more setup time at the start of a project and removes an entire category of problem later.

The commercial argument for it is straightforward: a client who cannot leave is a client who resents you. The engineering argument is better. Infrastructure that lives in a contractor's account is infrastructure with an undocumented dependency on a person, and that is a design flaw whether or not anyone has written it down.

Observability Is The Difference Between Confidence And Hope

"How do you know the system is working" is a question with two possible answers. One is a dashboard. The other is a pause.

You do not need elaborate tooling. Structured logs with a request identifier that lets you follow one request through the whole system. Error tracking that notifies someone who will act on it. Uptime checks on the paths that matter rather than just the home page. A metric or two for the things the business actually cares about, like orders placed rather than CPU percentage.

What matters is that the answer is demonstrable. Being able to open a screen and show current state is worth more in a diligence conversation than any amount of describing how carefully the code was written. It converts a claim into evidence, and diligence is entirely a process of converting claims into evidence.

The Decisions I Regret

For balance, the ones that did not hold up.

Early on I over abstracted. I built configurable systems for requirements that never arrived, on the theory that flexibility now saves work later. It does not. It front loads complexity against a future that usually turns out differently than you guessed, and the abstraction becomes something the next engineer has to understand before they can change anything. Concrete code that does one thing is easier to generalise later than a general system is to simplify.

I have also been too clever with data models, chasing normalisation past the point of usefulness. A schema that is theoretically pure and requires six joins to answer the most common question in the product is not a good schema. It is a correct one, which is a different property.

Both mistakes came from optimising for how the architecture would look to another engineer rather than how it would behave for the people using and maintaining it. That is the thing due diligence eventually finds, because a reviewer is not evaluating your taste. They are estimating what the next two years cost.