Philosophy
The Desire Path
The shortest, clearest route from having a problem to having it handled — with as little resistance or confusion along the way as possible.
Walk across almost any park or campus and you'll spot one: a worn dirt trail cutting across the grass, ignoring the paved sidewalk a few feet away. Urban planners call it a desire path — the route people actually took, not the one they were told to take. Good planners don't fence it off; they pave it, because the people walking it already found the shortcut. One well-known example: an architect left a building's courtyards as open dirt for a year, watched exactly where people walked on their own, then paved only those routes — the building told him where the paths should go.
The shortest, most easily navigated route. The worn dirt trail that cuts across the grass, because the sidewalk always takes the long way. That's the whole idea in one sentence, and it's where every tool I build starts.
It's also a real, active term in user experience (UX) design — the discipline built entirely around how people actually behave, not how a screen is supposed to look. Design and user experience get treated as the same thing sometimes, and they aren't; a screen can look sharp and still fail the moment someone can't find what they came to do. For a digital tool, design should follow user experience, not the other way around. Digital products leave their own version of worn grass — click data, session recordings, where people hesitate or bail out — and good product teams read that as information, not user error, rebuilding the interface around the route people actually take instead of the one a spec document assumed they'd follow.
Point A to point B, nothing in between that doesn't need to be there
Here's the part worth being blunt about: almost nobody opens a budgeting tool because they want to use a budgeting tool. They open it because they have an actual job to get done — "tell me if I'm okay to spend this," "get this week's plan somewhere I can see it," "stop wondering and just know." The tool is a means to that job, never the point of the exercise.
This is sometimes called "Jobs to Be Done" thinking in product design: people don't buy a product, they hire it to do a specific job, and the moment it takes longer or asks more of them than the job requires, it's failed — regardless of how many features it has. A desire path is what that looks like in practice: the fastest, least confusing route from "I have this thing I need to handle" to "handled," with nothing extra in the way.
That's also why overwhelm matters as much as it does. A tool that makes someone stop and think about the tool itself — which button, which tab, what a term means — has already added friction to a job they just wanted done. Reducing that isn't a minor UX nicety. It's most of the actual work.
What that actually looks like in practice
It's why there's no bank linking or subscription to manage — the shortcut is fewer moving parts, not more dashboards to check. It's why the guidance lives inside the tool itself instead of a separate tutorial you have to go find, so the path from confused to done doesn't have a detour through a help article. It's why nothing here assumes you already speak "finance," "productivity," or whatever the expert language of the category happens to be — that vocabulary is exactly the kind of unnecessary detour a desire path route skips.
None of that is a lack of ambition. It's the same instinct as the architect who waited to see where people actually walked before deciding where the paths should go — build for the route people take when nothing's stopping them, not the one that looked more official on paper.