Your Files Live in Eight Places. Your Search Shouldn't Have To.

I have a confession that every knowledge worker will recognize: I genuinely do not know where my files are.

Not in a dramatic way. In the boring, modern way. A contract is in Google Drive. Its signed version is in Dropbox because that's where the client shared it. My notes about it are in Notion. The Slack thread where we argued about clause 4 has the only copy of one revision. The invoice is in SharePoint because accounting lives there. And half of it is also sitting in a folder on my laptop called final_v2_REAL.

So when someone asks "can you send me that thing from last month?", I don't search. I excavate. I open four apps, type the same query into four different search bars, and hope one of them remembers better than I do.

I built OmniFile because I got tired of being the search engine. Here's what I learned turning that frustration into a shipping desktop app.

The idea was obvious. The constraint was the interesting part.

The pitch writes itself: one search bar that looks everywhere — local disk, Google Drive, Dropbox, Box, SharePoint, Slack, Notion, GitHub, iCloud — and returns results instantly. Hit a keyboard shortcut, type, done. Spotlight, but for your entire scattered life. (That unified-search idea gets its own deep dive in how to search all your cloud storage from one place.)

The obvious way to build that is a cloud service. You connect your accounts, a server crawls everything, builds a big searchable index, and you query it from anywhere. Fast to build. Easy to scale. Every investor deck loves it.

I decided almost immediately that I would not do that — and that decision ended up defining the entire product.

Because think about what a cloud search service actually is: a company that holds a searchable, deduplicated, permanently indexed copy of every sensitive document you own. Your contracts. Your finances. Your half-finished ideas. Your company's internal Slack. To make search fast, that company has to keep all of it, readable, on their servers. Forever.

I didn't want to be that company. And more importantly, I wouldn't want to be a customer of that company.

So OmniFile became a desktop app where the index — and everything in it — never leaves your machine. No account to create. No server to trust. No telemetry. The search query you type is never transmitted anywhere, because there's nowhere for it to go. That one constraint made everything harder. It also made everything worth it.

"Local-first" sounds nice until you have to build it

The easy version of privacy is a paragraph on your landing page. The hard version is architecture. Keeping everything on-device meant the app itself had to do the work a server would normally do: crawl your files, extract their contents, build a real full-text index, watch for changes, and stay fast enough that you'd actually reach for it instead of alt-tabbing to Google Drive.

A few decisions fell out of that:

It couldn't be an Electron app. OmniFile launches from a global shortcut and sits in the background all day. Shipping an entire Chromium browser to do that felt absurd. I built it on Tauri + Rust instead, which uses the operating system's native webview. The result idles at around 30 MB of RAM and installs in about 8 MB — roughly a tenth of the equivalent Electron build. For something that's supposed to feel like a lightweight system utility, that gap is the difference between "always on" and "why is my fan spinning."

The search had to be genuinely good, not just filename matching. OmniFile indexes the contents of your files — the text inside your documents and spreadsheets, not just their names. That's what makes it feel like search instead of find. Because the files already live on your disk, the index stores what it needs to find things but re-reads the originals to show them, which keeps the whole thing small.

Some integrations required being clever instead of powerful. iCloud Drive, for example, has no real public search API. I spent a while looking for the sophisticated solution before realizing there wasn't one — and didn't need to be. macOS already syncs iCloud files into a folder on disk. So OmniFile just finds that folder and indexes it like any other local directory. No OAuth, no API, no permission scopes. It just works, because the files were already there. Some of the best engineering decisions are the ones where you stop trying to be smart.

I'll spare you the war stories about wiring up seven different OAuth providers, each with its own idea of how a desktop app is allowed to log in (one of them insisted on HTTPS to localhost, which is exactly as fun as it sounds). The point is that "keep it on the device" wasn't a marketing angle bolted on at the end. It was the spec that shaped every layer underneath.

The features I'm most proud of are the ones I didn't build

When you build in a category that's currently drowning in AI, the pressure to bolt on a chatbot is intense. "Ask your files anything!" Semantic search! An assistant that reads your documents and answers questions! I built none of it. On purpose.

Every one of those features points in the same direction: sending your file contents somewhere else to be processed. The moment OmniFile ships your documents to an LLM API to answer a question, the entire promise — nothing leaves your machine — is gone. I'd have rebuilt exactly the company I refused to become, just with a nicer demo.

So OmniFile does something almost unfashionable: it searches. Quickly, locally, across everything, and then it gets out of your way. No "AI" badge. No summarization. No cloud round-trip. It's a tool, not a copilot. The hardest part of product work isn't adding things. It's having a reason to say no that you actually believe. Privacy gave me that reason for free, on every single feature request.

The business model taught me more than the code did

Here's a mistake I made early, in my own head: I assumed the free tier had to be crippled to make people pay. My first instinct was a file-count limit — search up to N files free, pay to unlock more. It took me an embarrassingly long time to see why that was backwards.

The thing that costs me nothing is local search. It runs on your machine, on your CPU, against your disk. Charging by the file punishes exactly the users I want — the ones with a lot of files and a real problem. It makes the free product feel like a trial that's actively working against you.

So I threw the limit out. Local search is now completely free and unlimited. Search your entire disk, forever, no account, no ceiling. That's the whole privacy-first pitch, given away — because it's the part that's honest to give away.

What you pay for is the part that's genuinely more work to build and maintain: the cloud integrations. Connecting and keeping in sync with seven external APIs — handling their token refreshes, their rate limits, their breaking changes — is ongoing effort, and it's the feature that turns OmniFile from "a nicer Spotlight" into "the one search bar for my whole working life." That's a one-time $129 license. No subscription, because a tool that runs entirely on your own machine has no recurring server cost to justify one.

The lesson that generalizes: don't gate the thing that's cheap for you and valuable to them. Gate the thing that's expensive for you and valuable to them. Free should feel like a gift, not a countdown.

The part nobody tells you: building it was the easy half

I'll be honest about the humbling part. I shipped a genuinely good app. It's fast, it's private, it respects you, it solves a real and universal problem. And for a while, almost nobody knew it existed.

That was the real education. Writing Rust that walks your filesystem and builds an index is a tractable problem — it has a right answer, and you can grind until you find it. Getting a stranger to discover your tool, trust it enough to download a desktop binary, and understand in ten seconds why it's different from the search bar already built into their OS — that problem does not have a compile step. You can't cargo build your way to distribution.

I'm still in the middle of learning it. Writing honestly about the decisions, showing the thing in motion, meeting people where they already are instead of waiting for them to find me — this article is part of that. For a solo developer, the muscle you have to build second is completely different from the one that got you to a working product. Nobody warns you that the hard part starts after it works.

What I'd do differently

Decide your privacy line on day one, and let it make your decisions for you. I got lucky that "everything stays local" was baked in early, because it turned a thousand small feature debates into one simple test: does this send user data somewhere? If yes, it doesn't ship. A clear principle is a decision-making machine.

Stop trying to be clever when the boring solution is sitting right there. The iCloud "just index the folder" moment should have come a lot faster than it did. Reach for the dumb, robust option first.

Start telling the story the same week you start writing the code. Distribution isn't a launch-day event you bolt on at the end. It's a muscle, and muscles take months. I'd begin building in public far earlier next time.