A while back I left my job to build a small, local-first utility for document compression. The bet was simple: researchers and labs sit on tens of gigabytes of Office files stuffed with screenshots, charts, and scanned pages, and most are uncomfortable uploading that material to a cloud service they don't control. I wanted to sell a tool that ran entirely on the user's machine. What I didn't expect was how much the product would change once real users started throwing their theses and grant proposals at it.
This is the part of indie building that rarely shows up in launch screenshots: the unglamorous iteration that follows the launch, when the people who actually use your thing tell you what you got wrong.
The niche found me
I started with a vague thesis that "documents are too big" and an equally vague audience of "people with too many PDFs." The clearer picture came from talking to graduate students and lab managers. Academic material tends to start life as an Office document — a thesis draft, a grant proposal, a lab notebook. The text is often modest. The embedded illustrations, instrument screenshots, and copied-in charts are what actually inflate the file, and nesting makes it worse: a chart in one deck copied from a spreadsheet, a diagram in a report cropped from a PDF. Object inside object, and the file quietly swells.
A global survey commissioned by M-Files and run by Vanson Bourne put numbers on the pain: 96% of employees said they struggled to find the latest version of a document, and 83% had at some point recreated a file simply because they could not locate the one that already existed. In a research lab that means cohorts of students re-indexing the same corpus and groups maintaining their own "close enough" reference libraries. The waste is not dramatic; it compounds.
The iteration that actually mattered
My first version compressed the body text and left embedded objects mostly alone. That was a mistake, and users told me so — politely at first, then bluntly. The files coming back from their labs were still huge because the bloat lived in the pictures, not the prose.
So the compression engine got reworked. The whole Office pipeline now handles embedded images and charts recursively instead of only the body text — a product change worth flagging on its own. For academic papers and proposals, it means the embedded visuals that were doing the inflating finally get trimmed. The document shrinks, the email with the 300 MB proposal finally goes through, and sync across devices stops stalling.
In our published benchmarks, a 443-page OFD document finishes end to end in 124 seconds, and compressed images cut the token cost of feeding them to a model by roughly 85.9%, measured on a GPT-4o basis. A figure pasted in as a high-resolution screenshot can burn thousands of tokens every time it reaches a model, even when the real information in it is small. Shrinking those images before they reach a model does double duty — lighter to store and far cheaper to reason over. You can see the tool and its approach over at https://www.uglypear.com/en/products/.
Pricing: buy-once vs subscription
For a local-first tool the default tug-of-war is buy-once versus subscription.
Subscription is easier to model for cash flow and gives you a reason to keep shipping. But a tool that runs entirely on someone's machine fights its own narrative when it also bills them every month for the privilege. The pitch "your data never leaves your computer" sits awkwardly next to "please keep paying us to open your own files."
Buy-once aligns better with the local-first promise. You pay, you own, it runs. The downside is the classic indie problem: you trade predictable recurring revenue for a support burden that tends not to end and a growth curve that depends largely on word of mouth. For a niche like research labs, where a single department might standardize on one purchase, buy-once also creates a strange incentive — you want them to keep buying seats, not buy once and forget you.
The lesson I'd hand another founder is this: pick the model that matches the shape of the value you deliver, not the one that looks best on a spreadsheet. If your tool saves a recurring, ongoing cost like model tokens, a subscription can be honest. If it solves a one-time problem, buy-once respects the buyer.
Local-first as differentiation, not a slogan
"Local-first" gets thrown around, but for this audience it is the floor, not a feature. Research institutions treat data sovereignty as nearly non-negotiable, and a lab handling collaborator details, unpublished datasets, and draft findings cannot casually pipe all of it to a third-party cloud. The differentiator is that the data never has to leave the internal network.
That also changes how you talk about the product. You are not selling cleverness; you are selling the absence of a risk — to people burned by the ordinary, not the spectacular. IBM's 2025 cost-of-a-breach study found that 26% of breaches trace back to human error, a more common path than external intrusion. In a research setting that might be a sensitive dataset attached to an email sent to the wrong address. Making the normal case safe by default — detecting and masking sensitive content before it is ever ingested — removes a whole class of accidents.
Distribution lessons for a niche tool
The hardest part was not building. It was reaching the people whose documents are a mess without sounding like I was shouting into a void. A niche research tool does not have a broad funnel to pour ad spend into, so many founders stall here.
A few things that actually moved the needle:
- Show before-and-after file size on a real document, not a synthetic benchmark.
- Hang out where the audience already complains about the problem — academic forums, lab communities, faculty mailing lists — and answer questions without dropping links.
- Lead with the pain: version chaos, attachment limits, cold storage.
Komprise's customer research is a useful gut-check here: 60% to 70% of data on enterprise NAS has not been accessed in over 90 days yet still sits on the most expensive primary storage. Research institutions are the extreme case — a project closes, raw data is touched by no one, but it cannot be deleted because a reviewer may ask for it back. The people who feel this are not hard to find if you listen. The overview at https://www.uglypear.com/en/products/ lays out the compression side in plainer terms.
Closing
If there is a takeaway from building this, it is that the interesting work happened after launch, not before. The embedded-object recursion was not in my original plan. Neither was the realization that local-first is less a feature and more a promise you keep in every decision — from the compression pipeline to the pricing page. The tools that earn a place in a researcher's workflow make the ordinary safe and the messy manageable, then step aside.
Try it now
To see how local-first document compression lands in your own lab or department, review the public product introduction at https://www.uglypear.com/en/products/, explore the broader platform at https://www.uglypear.com/en/, or read more founder and rollout thinking on the https://www.uglypear.com/en/blog/. When material is portable and stays inside your network, research stops being slowed by its own documents.
FAQ
Q: Why did you choose buy-once pricing instead of a subscription for a local-first tool?
A: A tool that runs entirely on a user's machine argues for ownership rather than a recurring bill to open their own files. Buy-once matches a one-time problem — compress a document, send it, move on. We still keep a seat-based option for labs that want ongoing support, but the base model respects the local-first promise instead of fighting it.
Q: For a research org, is local-first genuinely better than a SaaS knowledge base, or just a preference?
A: It depends on the data. If a lab handles unpublished datasets, draft findings, or collaborator details, keeping that material on premise removes an entire class of egress risk that a public cloud cannot fully close. SaaS can be faster to stand up, but for research institutions where data sovereignty is nearly non-negotiable, local-first tends to be the safer floor rather than a stylistic choice.
Q: How do you reach the right researchers without a large marketing budget?
A: By showing real before-and-after file sizes on actual documents and showing up where researchers already discuss the problem — academic forums, lab communities, faculty lists — to answer questions without pushing links. The wedge is pain-led: version chaos, attachment limits, and cold storage that nobody touches but nobody can delete.
Q: Doesn't offering private or on-prem deployment scare off buyers who want something turnkey?
A: It can filter the audience, which is partly the point. Buyers who need data to stay inside their network are precisely the ones who will not consider a cloud-only option, so private deployment is a qualifier rather than a deterrent. For teams that want less hands-on work, the setup can be scoped to connect to existing databases rather than rebuild from zero.
Q: How does a small team actually support on-prem installs across different campuses?
A: By keeping the deployment shape assessable per environment and connecting to each institution's existing systems instead of forcing a rip-and-replace. Support leans on snapshot rollback and deletion protection so a bad import can step back to the last good state, which keeps the ongoing burden manageable for a lean team.