Meshory

I build Meshory, a desktop app that turns folders of 3D printing files into a library you can browse. My own collection is the benchmark: a NAS share with 141,696 files in 8,448 folders.

On 2 August the first scan of that library took 6 hours 49 minutes. On 4 August, same machine, same share, it took 7 minutes 18 seconds. I published both runs as raw JSON. The slow one broke down like this:

- Walking the folders: under a minute

- Saving the file list: a few seconds

- Reading archives: 3.5 minutes

- Rendering thumbnails: 355 minutes

- Extracting cover images: 27 minutes

- Hashing files for duplicate detection: 22 minutes

About 4.5 of those 409 minutes were scanning. Everything else had crept into the scan over time, one reasonable addition at a time. A thumbnail for every model feels like part of scanning a library. So does hashing.

The change was mostly structural. A scan now walks the folders, saves what it found and indexes the archives, and that's it. Thumbnails, covers and hashing happen afterwards in the background, and previews render whatever is on screen first. Peak memory during the scan went from 5,873 MB to 391 MB along the way.

That work still has to happen. On a library this size the previews keep rendering long after those 7 minutes, mostly because a lot of the models sit inside large zips on a NAS, and reading them over the network is the slow part. What the 7 minutes buys is being able to browse and search straight away. I'm spelling that out because a headline like 56x invites people to assume it covers everything.

The first time I ran the new version in the real app, the scan took nearly three times as long as in the benchmark. The background renderer had started competing with the scan for the same workers. Making it step aside while a scan runs fixed that, and a clean run in the packaged app now lands within a minute of the benchmark.

One number went the wrong way, too. Reading archives went from 3.5 to 6.3 minutes, and it's now most of what's left of the scan.

A later archive change made the whole scan about 11% faster, but reading archive directories, the part I wanted to speed up, got slower in aggregate. My own report concluded that the runs "do not support a directory read speedup claim", so I don't make one, and the page quotes that sentence word for word.

The raw runs and the machine spec are at meshory.com/engineering. It's one machine and one library, so treat it as evidence rather than a benchmark suite.

For anyone who has done a similar split: how did you decide what had to finish before the user could do anything? I only saw how much had crept in because I timed every phase separately.

I build Meshory, a desktop app that organises 3D printing model files. Solo, and yes, I use AI heavily while writing it.

A few weeks ago someone on Reddit described it as "vibe coded". Not as a technical claim - as a way of saying it isn't real software.

My first instinct was to reply in that thread with a list of everything the app does. I'm glad I didn't. Arguing about your own product in a Reddit thread is a fight you cannot win: you're the one with something to defend, you look defensive doing it, and the best available outcome is that a few people decide you're touchy.

So I built a page instead, at meshory.com/engineering. It has three things on it:

1. What runs before a release ships. 4,842 unit tests and 205 end-to-end tests that drive the real Electron app, not mocks.

2. Before-and-after benchmarks with the raw JSON published, so anyone can check them rather than take my word for it. Same NAS library, same machine, both runs: 141,696 files across 8,448 folders.

- Full scan of the library: 6h 49m -> 7m 18s (56x)

- Rescan when nothing changed: 8m 33s -> 56ms (9,098x)

- Opening the folder tree: 206ms -> 66ms

3. A plain list of what is NOT done yet. If a page only contains flattering facts, a reader correctly reads it as marketing. Mine says the Windows build isn't code-signed yet, and gives no date for when it will be, because I don't know.

Two things I got wrong on the way:

I published a speedup figure I'd carried around in my head - 9,335x - and when I went back to the raw JSON to write this post, the actual number was 9,098x. Not a meaningful difference, and that's the point: I'd have been "caught" being sloppy on a page whose entire purpose is showing I'm not sloppy. If you publish numbers, generate them from the source every time.

And the honest limitation: these are runs on my machine against my library. That's why the machine spec is in the published JSON. It's evidence, not a benchmark suite, and saying so up front costs nothing.

I have no idea whether the person who said it ever saw the page. That wasn't really the point. It exists now for everyone who wonders the same thing and doesn't say it out loud - which, if someone said it once in public, is probably a lot of people.

If you're solo and building with AI: what do you actually show people to demonstrate the thing is real? I'm curious whether published test counts read as credible or as trying too hard.