I build ZANCTA - 17 PDF and image tools that run entirely in the browser. No uploads, no server-side processing. I chose that constraint on purpose, and I want to write down what it actually costs, because the pitch version of "privacy-first" hides all of it.
1. Model size is a product decision, not an engineering one
The background-removal model is an ONNX network running in WebAssembly. The equivalent server-side pipeline could ship a model an order of magnitude larger, and it would be visibly better at hair edges.
I do not get to make that trade on quality alone. A user on a metered connection will close the tab before a 40 MB download finishes. So the download budget gets decided first - how long will someone realistically wait - and the quality ceiling falls out of it. Same on OCR: the model that handles a scanned document well still has to be small enough that a user will actually wait for the download.
If you are shipping anything with a model to the client, your first constraint is not accuracy. It is patience.
2. Closing the tab is a Tuesday, not an edge case
On a cloud PDF tool, if the user closes the tab mid-merge, the server keeps working and the file shows up in an email a few minutes later. The failure is invisible.
On a browser-local tool, closing the tab kills the process. There is no fallback tier. So work that is invisible for a server-side competitor becomes mandatory here: a resumable local queue, real progress reporting, and being honest about what happens when a job is interrupted. Nobody sees any of it when the tool is working fine. You pay in development time and get no visible feature.
3. Memory is the ceiling on input size
Everything happens inside one tab's heap. A large PDF or a high-resolution image is not a slow operation, it is frequently an impossible one. On a normal-size photo, in-browser background removal takes roughly ten seconds on desktop Chrome, which is tolerable. What I am most nervous about is iOS Safari tab-memory limits on large inputs. I have not benchmarked specifically on low-end Android yet, and I would rather measure than guess at it.
4. What the numbers actually look like
Publishing these because the useful version of a build log is the one with figures in it, and mine are small.
Last 30 days:
- 83 sessions, 533 page views
- 17 active users in GA4, 1 registered account
- Search Console: 45 impressions, 3 clicks, average position 13.3
- Revenue: 0 INR. Active subscriptions: 0
- Checkouts started: 1. Completed: 0
Per tool, from server and client events:
| Tool | Views | Started | Completed |
|---|---|---|---|
| background-remover | 5 | 2 | 2 |
| image-compress | 3 | 2 | 2 |
| ocr | 3 | 1 | 1 |
| pdf-text-extractor | 2 | 1 | 1 |
| pdf-merge | 2 | 0 | 0 |
| images-to-pdf | 2 | 0 | 0 |
| checksum | 1 | 0 | 0 |
Two things that table says, and only one of them is bad news.
The product is not the bottleneck. Every tool that got started got completed. One hundred percent across the board. Whatever is wrong is upstream of the tool.
The bottleneck is that nobody arrives. 45 Search Console impressions in a month, for a site in a category that is searched constantly. And look at what those impressions are for - the top queries are sha check, sha256 verify, and zancot, which is people misspelling my own brand. I am not ranking for a single head term in the category I built for.
That second one reframed the project. I put the effort into the tools and effectively none into the two things that would have made them findable.
5. What I got wrong about distribution
I relaunched on Product Hunt in October with better positioning than the first attempt: one flagship capability (in-browser OCR) instead of a list of seventeen tools, a clear hook, the maker comment written in advance.
It got one upvote. Mine.
Nothing about the product changed between the two launches. The only variable was an audience that was not there. I had treated the launch as an event and assumed distribution follows from shipping something good. It does not. Distribution is a separate product, and I had built neither a launch audience nor a search presence. I had built a nicer landing page.
The demand that converts for a file tool is search-shaped, not browse-shaped. Someone holding a tax document and a converter that just demanded an upload has the problem right now, and they are typing it into a search engine. Nobody browsing a launch directory has that problem this morning.
Where it goes from here
The completion rates say the engineering bet was right. The impression counts say everything around it was wrong. Effort is moving off tool count and onto the small number of pages that answer a specific blocked question completely, measured by completed files rather than visits.
If you have shipped a technically sound product into approximately zero demand, I would genuinely like to know what you changed first.
Top comments (0)