Independent product / Information retrieval / 2026

Find the file.Not just the screenshot.

A visual database that turns years of purchased Dropbox collections into individual assets I can actually find, inspect and use.

Read-only Design Asset Database viewer showing watercolor search results and a selected floral asset with its source path, dimensions and tags — Portable viewerSearch, inspect, and return to the original Dropbox collection without exposing edit controls.

Role: Sole product designer and builder
Scale: 47,448 logical assets
Boundary: One home writer / read-only work viewer
Build approach: Product design and AI-assisted implementation

The origin

A screenshot showed what I bought. It could not show everything inside it.

I kept marketplace screenshots as reminders of purchased collections. They represented whole downloads, not the thousands of illustrations, textures, vectors, templates and source formats buried inside them. During a project, I still could not answer the practical question: do I already own the specific asset I need?

From download to retrieval

Three jobs make an inconsistent archive searchable.

Ingest

Traverse inconsistent Dropbox collections and generate browser-ready previews without moving or duplicating the source files.

Folders, archives, raster, vector and design formats

Resolve

Group PNG, SVG, EPS, AI and other variants into one logical asset, then retain the formats and folder context as metadata.

One asset record instead of repeated search results

Retrieve

Search names, paths, file types and tags, inspect a result visually, then return to the original collection in Dropbox.

The index ends where the working file begins

Retrieval evidence

Search finds the individual asset. Selection restores its context.

Read-only viewer searching all folders for watercolor and showing matching visual assets — Cross-folder searchA visual query replaces opening collection after collection.

Selected floral asset in the read-only viewer with folder path, Dropbox action, dimensions, file type and tags visible — Source contextThe result keeps its path, format, dimensions, tags and direct Dropbox handoff.

The adoption problem

It worked. I still did not use it.

The first version behaved like a development environment: services, terminal commands, ports and crawler knowledge. Search worked, but opening the product cost too much attention. Syncing a live SQLite database through Dropbox would only exchange startup friction for data risk.

The portable release

One place to change it. Anywhere I work to search it.

The redesign separated authoring from consumption. A home machine publishes an integrity-checked snapshot; the work app verifies it, caches it locally and opens it immutable and read-only.

Home writer

Crawl + curate

The only computer allowed to index, tag, merge and edit the canonical catalog.

Dropbox release

Publish + distribute

A compact, versioned SQLite snapshot plus synchronized preview files.

Work viewer

Verify + search

A macOS app validates the hash, caches locally and opens the catalog read-only.

Home editor with merge, tag management and delete controls visible

Work viewer with a read-only status and no merge, tag editing or delete controls

What the viewer proves

Read-only is a product boundary, not a label.

No crawler, delete, merge or tag-edit controls
Immutable local database connection
Mutation endpoints return HTTP 403
Source files still open from Dropbox

The observed outcome

A personal archive became a product I can carry.

The release packages a 38 MB Apple-silicon macOS viewer and keeps complexity where changes happen. The evidence below is from local verification, not a claim of long-term adoption.

47,448: logical asset records
1,801: results for watercolor
2.0 sec: local snapshot publish
HTTP 403: viewer mutation attempt