Each study traces a crossing: the challenge, the passage, the result. For the full list of work, see all our work.
In all four cases a system already existed, held together by someone's willpower: spreadsheets retyped by hand after every meeting, terminals opened one by one alongside scattered scripts, a group chat where 'what are we doing tonight?' drowned. So the work never starts from a fresh idea, but from an honest reading of what still holds and what has already given way.
What gives a product its shape is not the list of what it does, but the one thing it forbids itself. Never show learners a word they have not met yet. Never install a single process on the servers being watched. Never rank a venue by advertising budget. Never make anyone type the same figure twice. These refusals cost features, and they are what we defend in meetings.
A demo is judged on what it shows, a product on what it does by itself. A spaced-repetition engine deciding what to review and when. A scheduled watchdog waking someone when a server stops answering. A shared calculation updating disposable income on both sides at once. That invisible part is what separates a delivered product from an abandoned prototype.
A product never replaces anything overnight: existing data has to be migrated, the people who will use it trained, and the switch made without interrupting the work in progress. It is the least spectacular part of a project, the one no mockup shows, and the first to sink a rollout when it is handled last.