For a while now, I've been watching the AI wave from close range. Using the tools every day, reading the takes, nodding along. But I wanted to know what it actually felt like to build something with AI myself. Not read about it. Not listen to someone else's case study. Build.
There was a second question quietly tugging at me too. As a designer, I've spent my career making software for other people, and I'd always wondered what it would feel like on the other side. To use an app designed entirely around me. Every default, every column, every bit of copy shaped to how I actually think and work.
So I built one. A personal leadership tool called Trends, made by an audience of one for an audience of one. This is the story of how it came together, the AI tools that shaped the workflow along the way, and what the whole experience taught me as both a designer and a leader.
It started with a frustration
The spark was a simple annoyance. Every time I built something with Claude Code, it opened in the browser. I wanted something that lived on my desktop, felt like a real app, and stored everything locally. That was it. That was the whole brief.
From that small frustration, I started a conversation with Claude (not Claude Code, just Claude) to figure out what I actually wanted to build. What came out of that conversation was much bigger than I expected.
Think before you build
One of the best decisions I made early on was not to start building immediately. Instead, I spent time in conversation, shaping the idea before a single line of code was written.
I was also testing out a voice tool called Wispr Flow at the time, and it quietly changed the shape of that conversation. Instead of typing my thoughts into Claude, I spoke them. Talking ideas out loud is different from typing them. Looser. More exploratory. More honest. I'd ramble, Wispr would transcribe, Claude would catch the through-line. It was the first time I really felt what people mean when they talk about an AI workflow. Not a single tool, but a handful of them working together, each one shaping how I thought.
I started with "I want a note-taking app." But as I kept talking, it became something more: a tool that would help me be a better leader. I manage two design teams, and my biggest fear is that things fall out of my purview. Projects that drag on. People who go quiet. Blockers that keep reappearing. I wanted something that could hold all of that for me, read it back intelligently, and surface the things I should be paying attention to.
That's how the name Trends came about. And that's how a simple note-taking app became a personal leadership intelligence tool.
Functionality first. Seriously.
If there's one thing I'd tell anyone starting a project like this, it's this: don't worry about how it looks. Not yet.
I had strong opinions about the design from the beginning. Warm cream tones, serif typography, something that felt more like a notepad than a dashboard. Those opinions ended up mattering later. But in the early days, I kept them in my back pocket and focused on whether the thing actually worked.
The first version of the trends engine was a heuristic system: keyword matching, pattern recognition, rules I'd written manually. It was arbitrary and brittle. It would flag "Planning Beta" as an unknown person's name. It couldn't understand context. It was, frankly, not very useful.
But it worked. And because it worked, even poorly, I could see what I actually wanted. I could feel where it fell short. That gap between what I had and what I needed became the clearest brief I'd ever written.
A rough, functional thing teaches you more than a polished mockup ever could.
When heuristics hit the ceiling
The moment the system flagged a project name as an unrecognised team member was the moment I knew the heuristic approach had to go.
I went back to Claude and said: I want it to feel as though I've sent the notes to an LLM that actually understands what it's reading. And the answer was simple. Just do that. Replace the rules with a real Claude API call. Send all the notes. Get back structured observations and suggestions.
That switch changed everything. Suddenly the tool had genuine intelligence. It could read a month of stand-up notes and tell me someone seemed stretched, or that a project had been running longer than usual, or that I hadn't heard from a particular team member in a few weeks.
This was the moment Trends became something I actually wanted to use.
Build, then cut
Once the core was working, I started building out. A Planning module for weekly goals and reflections. A Notes section for general context. A Wiki for retaining knowledge. An Ideas engine that reads my reflections and suggests articles I could write.
And then something interesting happened. I started cutting things.
The Trends page originally had two sections, Observations and Suggestions. After using it for a few weeks, I noticed I never read the observations. I always went straight to suggestions. So I removed the observations entirely. One prompt. Done.
This is one of the most underrated parts of building for yourself: you can be ruthless in a way you never could with a product for others. There's no stakeholder to convince. No user research to commission. You just know.
The features that stayed are the ones I actually use. The ones that didn't earned their removal honestly, through real use.
Design at the right time
Here's the thing about that design direction I put in my back pocket. When the time came to think about how the app looked and felt, I had a simple brief — make it feel like Claude.
I said this partly because I love the Claude interface. The warmth of it, the restraint, the way it feels like a tool that respects your attention. But I also said it because I had a hunch Claude would know how to interpret that instruction better than almost any other reference I could give.
I was right.
Describing the aesthetic (cream palette, serif typography, tactile rather than hypermodern) in the language of something Claude already knew produced results that genuinely surprised me. The app doesn't look like a side project. It looks considered. It looks like something I'd want to open.
The lesson isn't that aesthetics don't matter. They do. The lesson is that with the right reference point at the right moment in the process, you can get a long way without being a visual designer yourself.
The feedback loop is everything
What made this process work — really work — was the tightness of the feedback loop. I'd run the app, notice something off, describe it, and see the change in minutes. Not hours. Not a sprint. Minutes.
That speed changes how you think. You stop overthinking decisions because you know you can reverse them. You become more willing to try things. You develop a clearer sense of your own preferences because you're confronted with real outcomes, not hypothetical ones.
It also changes what you're willing to build. Features I would never have commissioned from a team (a history log of every prompt I'd ever made, a Projects module with a required context field) I built for myself in an afternoon, just because I wanted them.
An app for an audience of one
Here's the strangest part of this whole experience. I know what it feels like, now, to use an app designed entirely around me. Every default, every column, every bit of copy shaped by someone who knows exactly how I think and work. Because that someone is me.
Most software is a compromise. Built for someone like you, but not you. The spacing is close, the features mostly apply, but there's always friction. A button that isn't quite where you'd put it. A flow that doesn't match how your brain moves. A default you'd change if the settings would let you.
Trends has none of that friction. It does what I want, in the order I want, in the voice I want. And the experience has quietly sharpened my eye back at the day job. I'm more aware of the compromises other products ask their users to make. I'm more curious about the person on the other end of the design.
There's a quiet meta-joke in all of this, too. I'm a design leader, and I built a tool to help me be a better design leader. The product I made for myself turned out to be the product I most needed to make. That wasn't the plan when I started. It's probably the insight I'm sitting with most now.
What I'd tell someone starting out
If you're a designer, a leader, or anyone who spends a lot of time in tools built by others, I'd encourage you to try building something for yourself. Not a startup. Not a product. Just a tool. Something small, something specific, something yours.
A few things that made the difference for me:
- Talk before you build. Use the conversation to figure out what you actually want. The brief you arrive at will be better than the one you started with.
- Ship ugly. The first version doesn't need to be good-looking. It needs to work well enough for you to understand what's missing.
- Cut without guilt. If you're not using something, remove it. The things you keep will be more valuable for the honesty of that decision.
- Use good references. When it comes to design, point to things that already exist and that the model knows well. Vague aesthetic language is harder to interpret than a concrete, shared reference.
- Trust the loop. The feedback cycle between what you build and how you use it is faster and more honest than any research method I know. Use it.
Trends isn't finished. It probably never will be. There are modules I still want to add, behaviours I want to refine, and ideas pinned in the Ideas section that I haven't acted on yet.
But it's mine. And it works. And I open it every day.
That's more than I can say for most tools I've used.