Diivo
A local-first library for your design references
31 followers
A local-first library for your design references
31 followers
Diivo is a local-first app for design references. Boards are real folders on your disk, a Chrome clipper saves any image or video in one click, and on-device AI finds shots by meaning. Free 30-day trial, no card. Then $29 once - yours forever.
Free Options
Launch Team / Built With
Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
the license covers 2 devices and the pitch mentions syncing via your own Drive/iCloud, which makes me curious about the AI search side specifically. if the same board folder is synced to a second machine, does the on-device index/embeddings rebuild fresh on that machine, or does it try to sync the index too. and if I tag or rename something on device A while device B is mid-index of the same synced folder, is there any chance of the two AI indexes drifting or stepping on each other, or is search fully independent per device regardless of what's synced
@galdayan Great question - this is exactly the part of the architecture I'm most happy with, so forgive the detail 😄
Each reference has a small per-asset JSON "sidecar" file living next to your library, and that's the source of truth for everything: tags, notes, favorites - and the AI embeddings too. So when the folder syncs to a second machine, the embeddings ride along with it: device B doesn't re-crunch your whole library, it only embeds files that are genuinely new. The heavy lifting happens once.
The searchable index itself (a local SQLite file) is deliberately treated as a disposable cache: each machine builds its own from the synced sidecars, and if sync ever mangles it mid-write, the app just detects that, nukes it and rebuilds. So search always runs fully locally on each device - there's no "shared index" to fight over.
On concurrent edits: since metadata is one small JSON per asset, the only real clash window is editing the same reference on both machines at the same moment - then your sync provider's normal conflict rules kick in (last write wins or a conflict copy), and both indexes converge to whatever the files say. Renaming/tagging on A while B is mid-index is fine: B's watcher picks up the changes and reconciles.
Honest caveat: syncing is your provider's job, by design - so right after a big sync, one machine can briefly search slightly stale data until the files land. It catches up on its own.
The local folders idea is genuinely smart, and the on-device AI search is what convinced me to try it. One thing that would seal the deal for me though is a way to tag boards with project context, like client name or deadline, so I can quickly filter across multiple ongoing projects without digging through nested folders.
@nuriyepbrr Thanks so much! I’m really glad the local folders and on-device AI search resonated with you.
I’ve actually been thinking about this for a future update. My current idea is to introduce sub-boards (essentially folders inside boards), so you could have a board for a client or project and organize everything inside it however you like.
I really like your idea of adding project metadata like client names or deadlines for filtering across multiple projects too. That’s a great use case, and I’ll definitely keep it in mind as I evolve the organization system. Thanks for the suggestion! 🙌
Love the local-first approach and the one-time price is a huge plus over subscriptions. One thing I'd love to see is a way to tag or annotate clipped images directly in the clipper before they hit the folder, so my collection stays organized from the moment I save something instead of cleaning it up later.
@celalasravxqhf Thank you! Local-first + one-time price was exactly the hill I picked from day one 😄
Great point on organizing at save time. Two things the clipper already does today: click the chevron next to the save button and you can pick the exact board before the clip lands (it remembers your last choice for one-click saves). And as of this week every clip automatically keeps the source page URL, so there's context for later triage.
Tags and notes right in the clipper popup - noted, adding it to the roadmap. The clipper already talks to the app locally, so it's very doable; the challenge is keeping that hover pill fast and unobtrusive.
Curious: would you want free-form tags at save time, or picking from your existing tags? That choice changes the design quite a bit.
The local folders approach is great for control, but it would be a huge help if the Chrome clipper could capture full-page screenshots instead of just visible images, since so many design references come from long scrolling sites.
@yeliz950491 Great idea - and the timing is almost funny: this week's update quietly built the exact plumbing this needs (the clipper can now send raw bytes to the app, not just URLs). Full-page capture is "scroll, stitch, ship" on top of that.
Adding it to the roadmap. One honest caveat from having fought this before: long-page capture wrestles with sticky headers and lazy-loaded sections, so v1 would likely be "capture what's rendered" rather than pixel-perfect on every site.
Curious what you'd capture most - full landing pages, or specific sections like pricing tables and hero blocks? A "capture this section" mode might actually ship faster.
the local-first approach with actual folders on disk is such a smart move, makes it feel less like yet another walled garden tool. Also love that the AI search runs on device, no waiting on some server.
@volkanruhtemiz Thanks! The "delete the app, keep your library" test was my north star - if a tool fails it, it's a walled garden no matter how pretty.
On-device AI was honestly the harder path (the model is ~360 MB and runs locally), but it means your references never leave your disk - and search works on a plane. Worth it.