About Tallis North
We help organisations make sound technical decisions and carry the worthwhile ones into production. That starts with understanding the system, the operating context, and the cost of getting the decision wrong.
How we approach problems
A technical problem rarely exists in isolation. We look at the architecture, delivery process, organisational boundaries, and operational burden together before recommending a course of action.
We make the current system legible first. That means tracing how data and decisions move, identifying where risk concentrates, and separating structural problems from symptoms. We then reduce the work to the smallest useful intervention that can be tested in the real environment.
The recommendation may be a focused change, a staged replacement, or no build at all. We explain the trade-offs plainly and leave a clear path from decision to delivery.
Capabilities
Our practice combines modern AI delivery with the architecture and engineering discipline needed to run software reliably.
We design AI-assisted workflows around evidence, feedback, and human review. The focus is not a demonstration that produces a plausible answer, but a production system that can be evaluated, observed, and trusted within defined limits.
We simplify integration boundaries, define stable service contracts, and plan changes across cloud, on-premise, and inherited systems. Architectural choices are judged by how they behave under change and failure, not by how tidy they appear on a diagram.
We improve the mechanics that make delivery dependable: testing, observability, code review, exception handling, and standards that teams can apply consistently. Good practice should reduce risk without becoming process for its own sake.
Working together
We inspect the system, test assumptions, and use what the software does in practice to guide decisions. Important recommendations come with the reasoning behind them.
Constraints are discussed early. We are clear about uncertainty, operating cost, delivery risk, and what a decision makes easier or harder later.
We document decisions, work alongside the people who will own the system, and favour approaches that remain understandable after the engagement ends.
Judgement
Technical capability matters. So does recognising when software is not the answer, when an existing tool is sufficient, or when the proposed change creates more operating burden than value.
We will decline work that depends on obscuring risk, bypassing sound engineering controls, or presenting an experiment as a production system. We also say no when the useful answer is smaller than the proposed engagement. A clear recommendation is more valuable than unnecessary delivery.
Tell us what you are trying to build or fix. If we are not the right people for it, we will say so.