Navigating Global Uncertainty with Confidence
Product Strategy
AI Product Design
Live-model Prototyping
Saas
At a Glance
AI Native
the model is the product, not a feature
3 core features
scoped from an open field
Launched
February, 2026
Overview
GAIL (Geopolitics AI Lab) turns world events into business consequences. A tariff shift, a port closure, a change of government somewhere you have suppliers. The platform reads those events and tells an organisation what they mean for it specifically.
The founding thesis was validated. The product was not. There were dozens of plausible things to build and no agreement on which one came first.
I ran the sprints that answered that and re-positioned the platform as a resilience tool rather than a prediction engine.
“Annual global economic output losses from geopolitical fragmentation could reach $5.7 trillion.”
- World Economic Forum
The problem with an AI product that predicts
The initial vision for the platform was as forecasting tool — it tells you what will happen and how likely it is. That's what the category invites, and it's what most people assume you're building.
What became clear with early concept testing is that people were sceptical. The model would never be right every time, and target users felt that.
The goal was to help operationally focussed users — (CFOs and COOs or L2s reporting in to those functions) who are naturally risk adverse. If we shipped a product that positioned itself as a prediction engine, then every miss would be a broken promise, and trust would erode with each one until nobody opened it. The interaction design problem wasn't "how do we make the model seem confident." It was the opposite: how do we build something genuinely useful that doesn't depend on being right?
Early AI prototype exploration
GAIL builds resilience. It does not predict.
The real strength of GAIL was surfacing second, and third-order consequences a user hadn't thought of, faster than they could have found them. For example, a supplier two steps removed, an exposure in a business unit nobody was watching. That value doesn't require accuracy in the forecasting sense. It requires breadth, speed, and enough reasoning for a person to judge it for themselves.
That reframe drove every design decision that followed.
Exploring data presentation for scenario planning
Designing for judgement, not answers
Scored exposure, with the reasoning attached. Every scenario carries a global impact score, then weighted scores across Strategy, Operations, Finance and People. Each one comes with its reasoning and the relevant exposure data.
The weighting matters more than the score. A single number invites a user to accept or reject it. A breakdown across business units invites them to interrogate it — why is Operations exposed and Finance not? — which is exactly the behaviour the product needs. The interface is designed to start an argument with the user, not end one.
The tool stops before the decision. GAIL doesn't action mitigations. It was a deliberate boundary: the product's job is to get a well-reasoned case in front of a senior decision-maker faster, not to make the call itself.
What it does instead is help the user build the case. Mitigation reports can be created, tracked, shared, commented on, and carry a full changelog. The human stays in the loop because the human is accountable for the outcome — and the audit trail exists because a report that goes to the board needs to show its working.
Three features, scoped tight.
- Onboarding — establishing what an organisation's actual exposure looks like, since everything downstream depends on it
- Home dashboard — live events, current exposure scores, and incident feeds, anchored by a rotatable globe showing a live world view
- Scenario and mitigation report creation — the workflow from "something happened" to "here's what we should do about it"
Onboarding data capture flow
Why I prototyped against live models
I built the prototypes in Magic Patterns and Lovable, then used ProtoPie to wire them to live model APIs. Validation sessions ran against real output.
Two reasons, and both were about credibility.
A Wizard of Oz prototype cannot build trust in a model. The entire question we needed to answer was whether users would believe what GAIL told them. You can't test belief against output a designer wrote. The moment someone senses the answer was authored rather than generated, the session is measuring their politeness, not their trust.
The data was too broad and too deep to fake convincingly. Geopolitical risk analysis spans regions, sectors, supply chains and time horizons. Any plausible mock would have been thin in a way a domain expert spots immediately — and the people we were testing with were domain experts. Live models gave us range no amount of prototype content could have matched.
Design system
The outcome
GAIL launched in February 2026 and began onboarding users immediately, alongside a fundraise for expansion.
The founding team came out of the sprint with a fully defined product design and a design system ready for developer handoff. But the more consequential output was the roadmap — it cut the scope and cost of a custom AI build substantially, which matters disproportionately when the founders are non-technical and every engineering decision is an act of faith.
The feasibility testing changed the build itself. Working against live models surfaced enough about what was actually achievable that the team refactored their technical architecture before writing production code. That's the argument for prototyping with real models rather than mocked ones, made better than I could make it in the abstract.
The product went to market as a resilience tool, not a prediction engine — and that positioning came out of the design work, not the pitch deck.
What I would do differently
I'd want to be in the room earlier. A lot of what we resolved in the design phase was really unfinished business from the strategy phase — assumptions that had been left open, and were then inherited as constraints once the design work started. By the time you're prototyping, those decisions have hardened, and you end up designing around them rather than testing them. Being involved during the assumption phase would have meant surfacing them while they were still cheap to change.
The second thing is about how I built. Prototyping against live models was the right call, but the iteration workflow at the time was clunky — it was often faster to rebuild a prototype from scratch than to modify one. On a product the size of GAIL, that's a slow way to work, and it quietly limits how many variants you're willing to explore. The tooling has moved considerably in the year since — AI-assisted design and prototyping now makes iterative change genuinely cheap — and I'd structure the build to take advantage of that: a modular prototype I could evolve across sessions rather than a series of one-offs.
That's the nature of designing with AI at the moment. The material changes faster than the practice around it does, and part of the job is staying honest about that.