Most people work with the tools they’re given. I can’t.
I notice the friction. A tool makes me work harder than the task should require. Once I notice it, I can’t unsee it.
A few years ago, I worked with a team that handled compliance checks. A single query required searching across multiple systems, one at a time. People jumped between databases, copied results, and compared them manually. The process was slow and error-prone. Everyone accepted it as just how the job worked.
I built a search tool that consolidated those systems into a single interface. The search went from a multi-step process to a single query. People who used it daily saved hours every week. That tool taught me something I carry into everything I build now: the right tool makes work possible in a way that didn’t exist before.
The pattern
That was the first time, but not the last. It’s a pattern I’ve followed my whole career.
Someone spends hours doing something manually. I ask why. The answer is usually “because that’s how the system works.” So I build something that changes how the system works.
Workflow automation across multiple teams reduced manual effort by 70%. Custom forms, approval processes, and dashboards replaced spreadsheets. I built data validations into processes where entries used to vary without checks. Where data could be looked up automatically, I removed the manual entry. Data quality improved and people spent less time on repetitive tasks.
The pattern is the same every time: find the friction, understand why it exists, build something that removes it.
Why build instead of using existing tools?
Most tools are designed for a general audience. They solve the problem for 80% of people, 80% of the time. The last 20% is usually the hardest part, and it’s the part that matters most.
When I build a tool, I solve it for the people I work with, in the context where they actually work. That specificity makes the difference between a tool that sits there and a tool that gets used.
What I look for
Not every friction point is worth solving. I’ve learned to be selective.
Frequency matters. If something happens once a quarter, I don’t build a tool. If it happens every day, I fix it. The payoff compounds.
Manual effort is a signal. When I see people doing the same thing over and over, copying data, formatting reports, sending the same email, that’s a signal that a tool could help. The more repetitive, the more valuable the automation.
Information flow breaks. When a team can’t answer a simple question because the answer lives in three different places, that’s a tool problem. The fix is a system that connects the pieces.
From work to personal projects
This pattern didn’t stop at work. I started noticing the same friction in my own life.
I’d capture a thought. A task I needed to do, a contact I needed to follow up with, an idea I wanted to explore. Then I’d spend more time organizing it than acting on it. Pick a folder. Choose a tag. Decide if it’s a note or a task. By the time I finished organizing, the energy was gone.
Every tool I tried stored information but didn’t act on it. I’d dump a thought into one, then have to remember to go back and figure out what to do with it.
The work I do for my teams and the work I do on my own projects follow the same instinct, but they serve completely different purposes. At work, I build tools for specific teams with specific problems. Outside of work, I build products for people like me — people who want a better way to manage their thoughts.
That’s why I’m building Zenmori. It’s a personal project, not a work tool. The same pattern applies: find the friction, understand why it exists, build something that removes it.
With Zenmori, you dump your thoughts. The assistant figures out what’s a task, what’s a contact, what’s knowledge, and follows up. No folders. No tags. No setup.
What I’ve learned
Building tools has taught me a few things that I carry into every project.
Start with the problem, not the technology. I reach for AI when it actually solves something better than what exists. The technology serves the problem, not the other way around.
Prototype before committing. I build a working version fast, test it with real users, and iterate. If the prototype doesn’t work, I haven’t wasted much time. If it does, I have evidence.
The best tools are invisible. When a tool works well, you don’t notice it. You just get your work done. Tools that require training, documentation, or onboarding are usually solving the wrong problem.
Build for the people who actually use it. A tool that works in theory but doesn’t work in practice falls short. I test with real users, in real situations, before I consider anything finished.
These lessons come from building tools that serve thousands of users, training 200+ people on AI, and now building a product I hope will help people manage their thoughts without the overhead.
The pattern hasn’t changed. I still notice the friction. I still ask why. And I still build something that makes it better.