Case study · Tooling
ShortPath
A local-first, global-hotkey fuzzy-search launcher that puts a support team's saved replies, SOPs, and docs one keystroke away, without leaving the conversation.
The one-liner
Retrieval is a tax, so I removed it
Support reps already know the snippet exists. ShortPath deletes the seconds between "I know the answer" and "here it is": a global hotkey, fuzzy search, paste, done.
The problem
Death by a thousand lookups
Frontline support runs on repeatable answers: saved replies, SOPs, troubleshooting docs, links. The knowledge exists, but retrieving it means leaving the ticket, hunting through a wiki or a folder of canned responses, copying, and coming back. It's only a few seconds each time. Multiplied across every ticket, every rep, every day, it's one of the quietest, largest time sinks in a support org.
Existing tools solved the wrong shape of the problem: knowledge bases optimize for writing and organizing content, not for retrieving it at the speed of a live conversation. The reps didn't need a better library. They needed a faster door into the one they already had.
Who it's for
The rep mid-ticket, not the manager mid-audit
I scoped to a single primary user: a support agent with a customer waiting. Every decision was measured against one question: does this make the next answer faster? Admins, analytics, and content governance were explicitly someone else's job. Keeping the user singular is what kept the product sharp.
The PRD, condensed
What I decided to build (and refused to)
Before writing app code, I validated the pain and the shape through rep interviews and wrote it up as a real PRD. The most useful part wasn't the goals. It was the non-goals. Scope discipline is the whole reason a solo project shipped.
Goals
- Summon from anywhere via a global hotkey, over any app
- Fuzzy search that ranks as you type
- Rich-text snippets, copy or paste in one action
- Import an existing library from CSV in minutes
- Work fully offline; own your own data
Non-goals
- Not a knowledge base or a CMS
- No accounts, no cloud dependency to function
- No analytics dashboards or admin console
- No AI generation; it retrieves what you wrote
Success looks like
- Reps keep it open all day, unprompted
- Time-to-snippet feels instant, not "a lookup"
- A team can seed its whole library before lunch
- The product thinking is legible, not just the code
How it works
The architecture
ShortPath is a local-first Electron shell with a React overlay bound to a global hotkey. A fuzzy index (Fuse.js) sits in front of a flat content store imported from CSV, with nested subfolders preserved as hierarchy. The same index feeds a couple of extra surfaces so reps can reach their library from wherever they already work.
The stack
What I used, and why
Hard calls
The tradeoffs I owned
Local-first over a hosted service
Reps' data stays on their machine and the tool works offline, a real trust and reliability win for support teams. The cost: I take on the harder job of building a sync path later instead of getting it free from a backend. Worth it. Privacy and "always works" beat convenience for this user.
A portable CSV over a database
Making the content model a flat, portable CSV means teams own and version their library without a database or a migration. It caps how relational the data can get, but for "snippets in folders," that ceiling is high enough, and the portability is a feature reps and admins both feel.
Retrieval over generation
No AI writing here. ShortPath surfaces exactly what the team already approved and wrote, instantly and predictably. That's the right call for canned support responses, where "correct and on-brand" beats "plausible."
One job over ten features
The whole roadmap was ruthlessly scoped to "get me the right snippet, now." Everything adjacent (authoring, analytics, governance) was cut on purpose. That constraint is why it shipped as one clean, legible product instead of a half-built platform.
Screens
A look at it
Outcome
What shipped, and what's next
ShortPath shipped open-source, with the PRD and a written case study alongside the code, because the point was to demonstrate product judgment (scoping, validation, tradeoffs) as much as the engineering. It's a tool reps actually keep open: resources are one keystroke away instead of a tab-hunt.
The clearest next step is the one the architecture was designed for: team sync, using the portable CSV as the contract so a whole team shares one library without giving up the local-first guarantees. Because the content model was kept clean from day one, that's an addition, not a rewrite.
Want the deeper version?
The full PRD and code are open-source. Or reach out and I'll walk you through the decisions.