Anyone can say their software is solid. Here is the evidence.
Meshory is built by one person, it costs money, and the source is closed. That is a lot to ask you to take on faith, so I would rather not ask. This page is the receipts: what runs before a release ships, what I measured, what I refused to claim, and what is still missing.
Written by Petros, who builds Meshory. More about the person behind it.
Nothing ships until it has been through all of this
Every release, including the small ones, passes the same gate. No manual exceptions, because a gate you can skip is not a gate.
The types have to check
TypeScript compiles the whole desktop app with no errors before anything else runs. A build that does not typecheck never reaches the test stage.
4,842 unit tests
421 test files covering the scan engine, the database layer, archive indexing, duplicate detection, licensing, and the UI. A further 51 are skipped rather than deleted, and the count above does not include them.
205 end to end tests
Playwright launches the actual packaged app against a real library on disk and drives it like a person: scan a folder, search it, open the 3D viewer, tag things, find duplicates, move files to the trash. 47 spec files.
Signed and notarized on macOS
Every macOS build is code signed and sent to Apple for notarization before it goes near a download link. If notarization fails, the release stops.
The installer itself gets smoke tested
CI installs the built app on a clean machine and boots it. A release that compiles but will not launch is caught here rather than by you.
Two stage publishing
Builds land in private storage first. Nothing reaches the download page or an existing user's auto updater until a separate promotion step runs.
I benchmark against my own library, not a demo folder
Every performance change is measured against the same NAS library on the same machine, before and after: 141,696 indexed files across 8,448 folders, 3.3 TB at the time these runs were captured on 2 August 2026. The raw results are committed with a timestamp, the app version and the hardware they ran on, so a later change that quietly makes something slower shows up.
That number counts files, not models, which is why it is larger than the 118,270 models quoted elsewhere on this site. 6,997 of those files are ZIP archives, and the 100,874 entries inside them are indexed as first-class items rather than left as opaque blobs. The rest of the difference is the images, PDFs and readmes that live alongside the models. Benchmarks count everything the scanner actually has to do work on.
Those last two figures come from a later run over the same library, on 8 August 2026, because the runs behind the table predate the counter that records them. Same corpus: both report the same 141,696 assets in the same 8,448 folders. That run is published too.
by
Measured on an Apple M4 Pro, 12 cores, 52 GB, against the same read only NAS share in both runs. Your numbers will differ with your hardware and your network. These are the ones I can show you. The speed-up column is divided from the raw measurements rather than the rounded figures beside it, so it can land a fraction of a percent off what you get dividing what is on screen. The raw JSON for every row is published here, timestamps, app versions and machine included.
What I would not let myself claim
The point of measuring is that sometimes the measurement says no. Here is a verbatim conclusion from one of my own benchmark reports, about a speedup I wanted to be able to advertise:
“Directory read aggregate increased substantially even while archive wall time fell, so these runs do not support a directory read speedup claim.”
In that same run, first scan got about 11% faster and archive handling got about 18% faster, both real. But preview latency in the sample got worse, and one target I had set for myself was not demonstrated by the data, so it is not demonstrated on this page either. Numbers that only ever move in the flattering direction are not measurements, they are marketing.
What is not done yet
The list I would want to read if I were deciding whether to trust someone else’s software.
Windows builds are not code signed yet.
Windows will show a SmartScreen warning on first install, and some antivirus tools quarantine the installer outright as a false positive. Only code signing removes either one. Until it lands, every build's SHA-256 and a VirusTotal report sit on the downloads page so you can check the file yourself. macOS is signed and notarized today.
The source is closed.
You cannot read the code, so the rest of this page is how I try to make that a reasonable deal rather than a leap of faith.
Very large single files can still defeat it.
A single STL over roughly a gigabyte can exhaust memory during duplicate hashing. It is a known limit with a measured threshold, not a surprise.
It is one person.
If I am asleep, your Discord message waits until morning. Nothing is on a 24 hour rota, and I will not pretend otherwise.
You cannot read the code, so here is what I owe you instead
It runs entirely on your machine.
Meshory never uploads your models. No account, no sync, no server between you and your own files. Pull the network cable and it works exactly the same.
You own what you paid for.
One time purchase, not a subscription. The version you bought keeps working, and it keeps working offline.
The changelog is specific.
Every release says what actually changed and why, including the fixes that were embarrassing. 21 of them since July 8, 2026
The person who takes the bug report is the person who fixes it
Bug reports and feature requests go to a Discord where they land on me directly, and a good number of them ship. Tag filtering exists because someone asked for it in Discord. Snapmaker slicer detection exists because a user sent me sample files. Half the release notes are somebody else’s idea.
See it on your own library
Download it, point it at your worst folder, and judge it on what it does to your own mess.