The asset nobody tags is the asset you can’t repurpose
Every social media operator I know is sitting on a graveyard of untagged gold: screen recordings of a winning hook, a client’s raw B-roll folder, the 40-minute founder interview that got cut into three Reels and then forgotten. The dirty secret of the repurposing economy isn’t that creators lack tools — it’s that the tools assume your source material is already findable. It isn’t. When I scheduled 30 posts across five platforms last month, the single biggest time sink wasn’t writing captions or checking the Buffer queue. It was hunting through Finder for the one clip where the guest said the thing I half-remembered. Instant Search, a new macOS tool from maker Dmitry Dolgopolov, is interesting to me not because it’s a social product — it isn’t — but because it attacks the exact bottleneck that sits upstream of every content calendar: finding the file you’re describing by describing it. That’s a creator-economy story whether the maker intended one or not.
What Instant Search actually is, and the problem it’s really solving
Let me be precise about what this thing is, because the Product Hunt listing is easy to misread. Instant Search is a local, offline AI file search for the Mac. You type a natural-language description — the maker’s example is literally “drivers license,” or “just explain the context” of a note you’re trying to find — and it returns the exact file and page containing the content you described. The team claims a 95% hit rate and sub-second results. Those are maker claims, not independently verified numbers, and I’ll treat them as such throughout.
The mechanism is the part worth understanding, because it explains both the promise and the limits. The maker draws an explicit contrast with Spotlight, Apple’s built-in search, which is fundamentally keyword matching — it finds filenames and metadata, not meaning. Ask Spotlight for “the clip where the founder talks about pricing” and it shrugs. Instant Search is doing semantic retrieval over your local files instead.
The more interesting technical claim is how it does that retrieval. The maker argues that traditional RAG pipelines — the retrieval-augmented-generation pattern most AI search tools use — collapse an entire document into a single embedding vector. That forces a tradeoff: the vector is either too coarse to represent the document accurately, or too precise to carry enough surrounding context. Instant Search says it sidesteps this with a bidirectional late-interaction embedding model, which is the family of techniques (think ColBERT-style retrieval) that keep per-token representations and score query-document interaction more finely rather than squashing everything into one vector. The maker also says it uses “the latest embedding models from Perplexity.” I’d flag that as a marketing-flavored detail — the source doesn’t name the specific model, and “embedding models from Perplexity” is a loose way to describe what’s almost certainly an underlying open model. Treat it as directional, not a spec sheet.
Two operational facts matter more to a creator than the architecture:
- It runs fully offline. A commenter asked directly whether it needs an internet connection, and the maker confirmed it works fully offline. Another asked whether data leaves the Mac; the maker said the only thing transmitted is anonymized PostHog usage data, and that “your data never leaves your Mac.”
- Indexing is cheap on disk. The maker says an average content library needs less than 1GB of disk space to index.
For anyone whose “content library” is 400GB of unlabeled video, that last number is the one that makes this plausible to actually try.
Why this is a creator tool even though it isn’t marketed as one
Here’s my take, and I’ll own it as opinion: the creator-economy tooling market has over-invested in the output end of the pipeline — schedulers, caption generators, CapCut templates, Canva resizers — and under-invested in the input end. But repurposing is an input problem. The reason most creators don’t turn one long-form video into 15 shorts isn’t that they lack an editor; it’s that the raw material is a swamp. A tool that lets you type “the part where she gets emotional about leaving her job” and jump straight to that timestamp is, functionally, a repurposing accelerator. It’s just wearing a file-manager costume.
How it stacks up against the incumbents you’d actually compare it to
I want to be fair to the alternatives, because “better than Spotlight” is a low bar and the real competitive set is broader.
Versus Spotlight and Finder. This is the comparison the maker leads with, and it’s the right one for the local file use case. Spotlight is fast and free and baked into macOS; it’s also keyword-only. If your files are well-named and well-tagged, Spotlight is genuinely fine and you don’t need this. Instant Search wins specifically when your library is a mess of IMG_4471.mov and Untitled-3.docx — which, for creators, is most libraries.
Versus cloud AI search (Google Drive search, Notion AI, Dropbox Dash). These tools do semantic search too, and some do it well. But they require your assets to live in their cloud, and they require an internet connection. Instant Search’s offline, local-only posture is a real differentiator for anyone handling client footage under an NDA, unreleased product shots, or source files they simply don’t want synced to a third party. That’s not a niche concern — it’s the default state of agency work.
Versus desktop AI assistants and RAG chat tools. Plenty of “chat with your files” apps exist. The maker’s critique — that single-vector RAG loses fidelity — is a legitimate technical argument, and late-interaction retrieval is a defensible answer to it. Whether Instant’s specific implementation delivers the claimed 95% hit rate is unknowable from the listing; I’d want to test it against my own worst-case folder before believing the number.
Versus the scheduling stack. It doesn’t compete with Later, Metricool, or Hootsuite at all — and I think that’s a gap, not a feature. More on that below.
Why video-first creators should care more than text-first ones
A LinkedIn ghostwriter’s files are mostly text, and text is already searchable — Spotlight plus a decent naming convention gets you 80% there. But if you’re a TikTok or YouTube operator, your source material is video, and video is the least searchable format on your machine. Transcripts help, but only if something has already transcribed and indexed them. The promise of describing a moment and landing on the file (and page) is worth dramatically more to someone whose library is hours of footage than to someone whose library is 200 markdown notes. If you live in Premiere or DaVinci Resolve, this is the audience I’d point at it first.
What social teams can borrow from this, regardless of whether they adopt it
Even if you never install Instant Search, the launch is a useful prompt to audit your own retrieval layer. Three things I’d steal:
- Stop relying on filenames as your only index. The reason creators can’t find anything is that we name files for the camera, not the content. A semantic layer — whether it’s this tool, a cloud drive with AI search, or a disciplined tagging habit in your DAM — is now table stakes once your library crosses a few hundred assets.
- Treat privacy posture as a content-ops decision. The offline/on-device angle matters for client work in a way that’s easy to wave off until you’re handling embargoed footage. When you evaluate any AI tool that touches raw assets, “where does the data go” should be a line item in your comparison, not an afterthought.
- Interrogate the retrieval architecture, not the demo. The single-vector-vs-late-interaction distinction the maker raises is the kind of question every operator should be asking of AI tools now: how does it retrieve, and what does that cost me in accuracy? A slick demo hides a lot of retrieval sins.
Where the math breaks
The 95% hit rate claim deserves scrutiny, and I say that as someone who wants the tool to be good. Hit rate on what corpus? A clean folder of PDFs is a very different test than 500GB of near-duplicate video clips with ambient audio and no transcripts. The maker doesn’t specify the benchmark, and the listing doesn’t disclose pricing, platform support beyond macOS, or how it handles video specifically versus documents. Those aren’t gotchas — they’re just the questions a careful operator asks before trusting a number. My bet is the real-world hit rate is high on documents and more variable on messy media, which is exactly the media creators care about most.
Where my judgment says it falls short
I’ll be blunt about the limitations, because the listing is thin on them.
It’s macOS-only and local-only. For a solo creator on a Mac, fine. For a social team spread across Windows machines, Google Drive, and a shared Figma or Frame.io workspace, this solves a problem most teams have already outsourced to the cloud. The offline advantage is real, but so is the collaboration disadvantage — there’s no shared index, no team search, no “find the clip marketing approved last week” across people.
It doesn’t connect to your publishing workflow. This is the biggest gap for my audience. Finding the file is step one; the operator’s actual job is file → edit → caption → schedule → measure. Instant Search ends at step one. There’s no evident tie-in to your scheduler, your analytics, or your UTM tracking. It’s a search tool, not a content-ops platform, and I’d rather say that plainly than pretend it’s a repurposing suite.
The Perplexity framing is doing marketing work. “Uses the latest embedding models from Perplexity” sounds impressive and may be technically true, but it doesn’t tell you which model, how it’s tuned, or what happens when Perplexity updates it. For a tool whose entire value is retrieval quality, that’s a meaningful opacity.
Pricing and longevity are not disclosed. The listing doesn’t state a price. A solo-maker local app is a different reliability bet than a funded SaaS, and operators should weigh that. I’d test it on a copy of my library before trusting it with the only copy of anything.
Who this is not for
If your assets already live in a well-organized cloud DAM with AI search, or your team is Windows-based, or you mainly need scheduling and analytics, this isn’t your tool and shouldn’t be. It’s for the Mac-based creator or solo operator with a large, messy, private local library and a real findability problem. That’s a narrower audience than the Product Hunt framing implies — and that’s fine.
What I’d watch / test next
This week, before you install anything, do the retrieval audit: pick your five most painful “where is that clip” searches from the last month and time yourself finding each one the old way. That baseline is the only honest way to judge a tool like this. Then, if you’re on a Mac, install Instant Search, point it at a copy of one messy folder — not your whole drive — and re-run the same five searches. Watch specifically for how it handles video versus documents, since that’s where the maker’s claims are least specified. Ask the maker directly, in the launch thread, what corpus the 95% figure was measured on and whether video transcription is part of the index. And keep it in perspective: even a perfect file search is upstream of your real job. The win isn’t finding the clip — it’s what you do with the 40 minutes you get back, and whether your scheduler and analytics are ready to turn that found asset into a post you can actually measure.
