Senior engineeringjudgement,written down.

We look at how the system is put together and what that shape costs you: service and module boundaries, the data model, integrations, environments, hosting, and the failure modes those choices create. We read the code behind the important paths rather than trusting a diagram, and we talk to the engineers who maintain it. You get a written picture of the architecture as it exists today, the decisions that have become expensive to reverse, and what we would change first — with the reasoning, so you can disagree with it on the merits.

No. The assessment is written so that your own engineers, or any other studio, can act on it without us — findings, evidence, priority, and reasoning are all on the page. Some clients take the document and do the work in-house, and that is a perfectly good outcome. If you do want us to implement, that is scoped and quoted as a separate engagement rather than assumed at the end of this one.

Usually, yes. Architecture, data modelling, performance, security posture, and delivery process travel across stacks, and reading unfamiliar code is a normal part of inheriting systems. Day to day we work in JavaScript and TypeScript, React and Next.js, Node, PHP and Laravel, Vue, React Native, and relational databases, so those get the deepest read. If your stack sits far outside that, we say so before you commit and scope the review around what we can genuinely assess rather than bluffing our way through it.

It depends on how much system there is and how deep you want us to go — reviewing one service is not the same job as planning a modernisation across a whole platform. We agree the scope and the end date in writing before the engagement begins, and quote per engagement, which is why this service is not on the pricing page with a published range. What we will not do is let a review run open-ended; a fixed finish is part of the scope, not something negotiated later.

Read access to the repository, whatever documentation exists, and a walk through a non-production environment are usually enough to begin. A performance audit also needs monitoring, logs, and ideally a realistic dataset, because measuring against empty tables tells you nothing useful. Where access has to stay limited, we work with what you can give us and state plainly in the assessment which conclusions were constrained by it.

Different subject. The AI Operations Audit is a fixed-scope, one-week paid diagnostic of how your business runs day to day: it maps manual workflows, scores where AI agents create real leverage, and comes back with a prioritised, priced implementation roadmap. Technical consulting looks at the software itself — architecture, code, performance, platform, and how your team ships. If the question is "where should AI go in our operations", book the audit. If it is "is this system worth keeping, and what would it take to fix", this is the engagement. Clients who need both usually run the technical review first, because it tells you what the software can support.