Someone on Reddit called my product "vibe coded". I published my benchmarks instead of arguing.
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.
My guess is your second reading is closer to right. The page probably doesn't turn a skeptic into a buyer. Nobody reads "205 E2E tests" and changes their mind; they read it and stop looking for a reason not to. It closes a loop for people already leaning in rather than opening one for people who aren't.
What it definitely changed is my side. I have one URL instead of an argument. When the question comes up in a thread, in an email, in my own head at 2am, it's already answered somewhere I don't have to defend it in real time. That turned out to be worth the build even if it converts nobody.
That rescan drop from 8m 33s to 56ms is absolute insanity—56ms for ~140k files is wild. Honestly, publishing the raw JSON, machine specs, and the 'what's NOT done yet' list reads 100% as raw engineering credibility, not 'trying too hard'. The transparency is what sells it. Handling Reddit noise with cold data is definitely the play. Epic write-up!
Thanks. Worth being precise about that 56ms, since it's the number most likely to make a careful reader suspicious: it's what it costs to confirm nothing changed, not to redo the work. In that same published run the first sweep is 7.8s, the 56ms is the idle one. The old build spent 8m 33s arriving at the same "nothing changed" every time. The "not done yet" list was the section I nearly cut, and it's the one doing the most work. Cheap to write, expensive to admit.
"Cheap to write, expensive to admit"—that’s a masterclass in founder transparency right there.
The fact that you actively measure state verification (confirming zero drift) versus full re-indexing is exactly what separates real engineering from "vibe coding." Reducing a 8m+ idle check to 56ms changes the user experience entirely from "heavy desktop app" to "instant background native feel."
Defeats the Reddit noise completely. Rooting for Meshory!