We don't believe complexity is impressive — we believe it's a cost that has to be justified by a constraint that exists today, not one we're guessing might arrive. Therefore, we remove or defer a system before we introduce a new one, and an architecture only grows a layer when a named, present requirement forces it to.

An assumption about a user, a market, or a technical limit is a liability until it's been tested. Therefore, we test the assumption before we fund the build on top of it — and where testing isn't possible yet, we flag it visibly in the plan rather than let it pass as fact.

A demo that only works in a controlled room hasn't told us anything about production. Therefore, we don't report a prototype as progress on a client's board — and before an engagement starts, we write down the number that will tell us, later, whether it actually worked.

Code that only the person who wrote it can extend isn't finished, no matter how well it works today. Therefore, we build and hand off in a way that lets a client's own team change what we built without calling us back to do it.

A decision without a written reason gets re-argued in six months by someone who wasn't in the room. Therefore, we write the rationale down while we're making the call, not afterward when a client asks for it — and we name the person accountable for it at the same time.

These principles aren't a list to agree with — they're what actually gets consulted when two of them point in different directions, which happens on almost every engagement. A principle that never has to resolve a real tension isn't a principle; it's a preference.

When a client needs something fast and the fast version would leave their team unable to extend it later, maintainability wins — but the trade-off gets named out loud, not absorbed silently into the schedule. We'll ship the narrower, well-built version of the request before we'll ship the broad version that only we can maintain.

When a workflow could be automated but the underlying process hasn't been verified yet, verification wins first — automation follows once the process is actually correct, not before. And where a decision carries real consequence for someone outside the system, it stays a human decision regardless of how automatable the mechanics are.

When a deadline and the discipline of writing down the rationale for a decision are in tension, we still write it down — a decision made under time pressure is exactly the one most likely to be re-argued later without a record of why it was made. Rapid delivery is not an exception to documentation; it's the reason documentation matters most.