01
Frame the problem
I use research, product context and writing to make the decision visible before polishing an interface around it.
Workbench
The tools are part of the design process.
I move between research, visual systems, product flows, working software and content. The useful question is not which tools are in the stack. It is what each one lets me see, test or ship before I make the next decision.
Tools I use
Different tools for different kinds of certainty.
Grouped by what each one is for. The marks are the real ones; the sentence under each is the honest version of how it earns its place.
Also
FigmaInterface & visual craft
I use Figma to resolve the parts of a product that need visual precision: hierarchy, responsive composition, interaction detail, components and presentation.
ChatGPT + CodexReasoning & implementation
I use the loop to interrogate decisions, work through implementation constraints, inspect evidence and carry design intent closer to production instead of stopping at a handoff.
Claude + Claude CodeParallel design & build loop
I use it to pressure-test product structure, explore alternatives and work directly against implementation, especially when a design question is easier to judge in a running interface.
SanityStructured content
I model content so product structure, editorial control and presentation stay separate. This site is deliberately moving more of its public surfaces into Sanity instead of leaving them hardcoded.
Next.js + Vercel + GitHubProduction surface
I use code and preview deployments to test the actual responsive behaviour, content model, performance and edge cases rather than treating the final Figma frame as the end of the design.
The loop
A design workflow that gets closer to the thing itself.
02
Prototype the behaviour
Flows move between interface design and working prototypes so states, data and edge cases can push back on the concept early.
03
Make the system coherent
Once the behaviour holds, I tighten typography, composition, motion, components and content into something people can actually use.
Built tools and products
Some problems are easier to understand once I build the tool.
ApplyOSWorking software
An AI-assisted job-search operating system for assessing fit, finding roles, running applications and learning from outcomes.
It is also a test bed for my current design-build loop: journeys and system rules become working software early enough for real usage to expose what the static design missed.
See the build notes →FleetpassLive product
A simple way to track vehicle and driver documents before expiry becomes a roadside surprise.
The product is organised around one question: when I open it, can I immediately tell what needs my attention? Document upload, missing-document logic and urgency sorting all follow from that.
See Fleetpass →Studio builds — OUI Life, Stratfortis, KalviaClient builds
Commercial design-to-build work for clients: OUI Life’s private-label manufacturing enquiry journey, plus the Stratfortis and Kalvia acquisition systems.
The second commercial proof of the same loop ApplyOS runs on: strategy and design carried into working acquisition systems rather than handed over as files.
See the studio builds →Webflow Element CopierPublic repository
A Chrome extension for copying page elements from websites into Webflow Designer with their rendered styles preserved — a working design-engineering artefact rather than a product.
It turns a repetitive design-build handoff into something inspectable and reusable. Publishing it is the honest version of “I work close to the implementation”: the code is there to read, including the limits.
See the repository →African visual infrastructurePublic resources
African Icon Library and Retna are two responses to the same old problem: generic visual material standing in for African people and products.
Icons and photography become shared visual infrastructure, not one-off brand assets.
Explore the public work →What stays constant
The stack changes. The loop matters more: get close to the problem, make the uncertainty visible, build enough to test the decision, then refine what survives.