Approach
Most architecture work fails for reasons that have nothing to do with architecture. These are the principles the practice holds to, and the reasons behind them.
Understand the constraints before designing
Every system is shaped by things that are not in the diagram: a contract that cannot be renegotiated, a team that is already at capacity, a regulator with an opinion. A design that ignores those is not a design, it is a wish. The first work of any engagement is finding out what is actually fixed.
Build what the operations team can maintain
The people who run a system are rarely the people who chose it. A design is only as good as the worst night someone has to operate it. If the runbook needs its author present to be useful, the system is not finished.
Balance performance against maintainability
Optimising either one into the ground produces something that fails later and harder. The interesting question is never which matters more, but where this particular system should sit between them — and that answer changes by workload, by team, and by year.
Say what is uncertain
Assessments are more useful when they distinguish what was measured from what was inferred. Where evidence is thin, we say so rather than rounding a guess up into a finding.
The model is the commodity
In AI-assisted work the model is the part you can buy. The scarce work is shaping it: scope, boundaries, and outcome, kept in the user’s hands rather than assumed on their behalf. Every product in the studio is built on that premise.
Technology changes rapidly, human challenges slowly
Four generations of computing have passed through this practice, and the recurring problems have barely moved: unclear ownership, integration nobody wants to own, and systems that outlive the assumptions they were built on. Designing for the slow-moving problem tends to survive the fast-moving one.
If that sounds like how you want to work
The next question is usually shape and cost — a short review, or someone embedded for a while.