03Instant, privateclipboard historyfor macOS
A lightweight macOS clipboard utility case focused on fast recall, keyboard-first interaction, local-first storage, and privacy-aware product decisions.
Clippy is a macOS menu-bar clipboard utility case designed for high-frequency copy workflows. It focuses on instant recall, keyboard-first interaction, and local-first storage. The product treats clipboard history as local, sensitive data: stored in SQLite, without accounts or cloud sync.
4
Clipboard tools compared: Maccy, Raycast, CleanClip, Paste
3
Core product risks reviewed: hotkey reliability, privacy defaults, paste semantics
V1.2.1
Security-oriented review covering local API binding and token-based WebView access
01 — Problem Statement
Every clipboard tool feels like overkill or too slow
Clipboard history is one of the highest-frequency utility scenarios on macOS. Users need three things: speed (summon feels instant), trust (data is treated as local and sensitive), and low interruption (the tool never breaks the current workflow).
Existing tools fall into two camps. Heavy apps like Paste and CleanClip offer rich features but require learning new interfaces and cost $20+/year. Lightweight options like the system clipboard only store one item — forcing users to retype or re-copy constantly.
Users need the ability to find "that thing I copied earlier" without switching context or learning a new tool.
I owned this project end to end — product direction, interaction design, competitive analysis, implementation review, and iterative prototyping.
The comparison pushed Clippy toward a narrow positioning: fast like Maccy, but with stronger privacy defaults and image support.
02 — Hypothesis
Keyboard-first ≠ keyboard-only
The initial assumption was simple: fully keyboard-driven = fastest. But observing my own usage patterns revealed a nuance — users switch between two modes: scanning (browsing recent history) and targeting (finding a specific item).
For scanning, keyboard arrows work perfectly: ⌘⇧V → ↑↓ → Enter. Done in under a second. For targeting, you need a "pause and look" moment — fuzzy search with visual feedback.
The Hypothesis
If the path from summon to paste stays within three actions, and fuzzy search is always available, the tool can become the user's default recovery path when the current clipboard is not enough.
Two primary interaction paths: Path A for keyboard scanning, Path B for search targeting. The goal is to keep both paths short enough for repeated daily use.
03 — Design Decisions
Five core bets that shaped the product
Direct Paste
Selecting an item pastes it immediately into the active app. No extra ⌘V needed. Most tools copy to clipboard and wait — we skip that step entirely.
Local SQLite Storage
No account model and no cloud sync. The user's mental model should be simple: "my clipboard history is local data on this machine." Trust is built by architecture, not by a privacy policy page.
App-level Privacy Exclusion
Sensitive contexts such as password managers and banking apps are handled through exclusion rules. The product requirement is to block sensitive capture up front, instead of relying on users to delete entries later.
Smart Retention
Default retention is 7 days with a configurable item limit. This avoids the psychological weight of "storing everything forever" while keeping enough history for real workflows.
Image Capture
Screenshots and image clipboard entries are stored with thumbnail previews. One-click paste for visual content, not just text.
Privacy exclusion architecture — sensitive apps are blocked at capture time, not deleted after.
04 — Interaction Design
Speed comes from eliminating decisions, not adding shortcuts
The core interaction is a HUD-style floating panel — not a separate window. It appears near the cursor, responds instantly, and disappears the moment you make a choice.
Search-as-filter: typing immediately filters the history list. No "press Enter to search" step. Characters narrow results in real-time.
Single-key navigation: ↑↓ to move, Enter to paste, Esc to dismiss. The first item is pre-selected, so Enter alone pastes the most recent.
Every extra decision point is latency the user feels. If they have to think "should I search or scroll?" — the tool is already too slow.
The three UI states keep one mental model: recent history first, type to narrow, preview only when it helps the paste decision.
System architecture: Swift menu-bar shell → WKWebView (Liquid Glass UI) → Go backend with SQLite storage and 800ms clipboard polling.
05 — Competitive Analysis
What existing tools get right — and where they leave gaps
I analyzed five clipboard tools across six dimensions: summon speed, direct paste, privacy controls, image support, search quality, and pricing.
Maccy is the closest competitor — fast, free, keyboard-driven. But it lacks privacy exclusion rules and image clipboard support.
Raycast Clipboard is powerful but bundled inside the full Raycast launcher. If you don't want Raycast's entire ecosystem, you can't use just the clipboard feature.
CleanClip has the best feature set — privacy rules, smart lists, paste queues. But it costs ¥99/year, the UI is heavy, and summon speed suffers from the visual complexity.
Clippy's positioning: Maccy's speed and simplicity + CleanClip's privacy intelligence. Free, open, and keyboard-first with zero configuration needed.
Interface comparison focused on interaction cost, not visual taste: how many decisions users must make before pasting.
What I intentionally left out
No cloud sync in the first version
Cross-device sync sounds attractive, but it would weaken the local-first trust story and expand the security surface too early.
No complex folder system
Clipboard tools are recovery tools first. Heavy organization would make the product feel like a knowledge base instead of a quick utility.
No AI layer before reliability
The case is deliberately positioned as a C-end utility project. AI summarization or memory features only make sense after hotkeys, privacy, and paste behavior are trustworthy.
Usage pattern analysis — clipboard access frequency across content types during daily development workflow.
06 — Reflection
A utility tool is finished when there's nothing left to remove
Building a clipboard utility taught me that product judgment in tooling is about restraint. Every feature added is summon-speed debt. Every pixel of UI complexity is a reason for users to reach for ⌘V instead.
Local-first is not a technical choice — it's trust architecture. Users never need to understand SQLite, but they need to feel that "this tool doesn't steal my data."
This project demonstrates a different kind of product signal from my B2B and AI-content work: the ability to define a small C-end utility, narrow its scope, evaluate interaction cost, and connect product decisions to implementation constraints.
Lessons Learned
Speed is the feature
A utility that takes > 1s to appear has already failed. Summon latency is the single most important metric for a clipboard tool.
Privacy is felt, not explained
Architecture decisions speak louder than policy pages. If the tool never touches the network, users know it instinctively.
Keyboard-first requires zero-config
If the user has to set up a hotkey, they won't. The default ⌘⇧V must work out of the box on the first launch.
Metrics are framed as product health signals for future testing, not as claims of market traction.