For the past year I have been building a small document knowledge-base and compression tool for teams that cannot send their files to the cloud. As a solo founder, the hardest parts were deciding how to charge for it and how to earn a stranger's trust when the entire pitch is "your data never leaves your building."
The document problem is real and well-measured. IBM's Cost of a Data Breach Report 2025 puts the global average cost of a breach at 4.44 million USD, with an average of 241 days to contain one. Those numbers are not abstract to a public-sector or regulated buyer; they are the reason a procurement form asks where data lives before it asks what the software does. A separate survey by M-Files and Vanson Bourne found that 96% of employees struggle to find the latest version of a document, and 83% have recreated a file from scratch because they could not locate the original. We are drowning in our own output: more than 3 trillion PDFs are in circulation, and one major collaboration platform alone receives over 2 billion file uploads every day.
As a small maker, those numbers are both the opportunity and the trap. The opportunity is obvious — every organization has a document mess. The trap is that the obvious solution, another cloud service, is exactly what these buyers cannot adopt.
Pricing that matches the trust story
The instinct for a small tool is subscription: recurring revenue, predictable runway, room to keep shipping. But for a product that lives on a customer's own server, subscription sends a strange signal. If the core value is "you own your infrastructure and your data," asking for a monthly fee forever can feel like the one exception to that promise. I found myself uncomfortable explaining why a privacy tool needed a recurring leash.
Buy-once pricing, by contrast, aligns with the local-first story. The customer pays, they run it, and it keeps working even if they never talk to me again. The downside is obvious: no compounding revenue and a growing install base that costs more in support than it earns. What I landed on is a hybrid that I have seen other indies use successfully — a one-time license for the core engine, with optional paid tiers for things that genuinely cost money to maintain, like hosted validation or priority incident response. The core promise stays buy-once, and the recurring part is honestly framed as a service, not a toll.
The lesson for other builders: match your pricing shape to your trust story. A privacy product with a surveillance-shaped billing model feels off no matter how solid the feature list is. I would rather have a smaller, honest customer base than a larger one that resents the meter running. You can see how this plays out across the product lineup.
Local-first as differentiation
Most document tools assume the cloud — fine until a buyer cannot use it: air-gapped networks, classified material, citizen data with strict residency rules. Framing the product as data sovereignty rather than a feature set changed how conversations went. Instead of "we have solid search," the pitch became "your original data stays where it is, and we never copy it out." That single reframing moved me from the crowded search-tools aisle into a much smaller, much hungrier room.
A few capabilities turned out to matter far more in real conversations than I expected when I started:
- Access control at the content level. Rather than locking whole folders, access tiers from fully public to strictly restricted can be pushed down to the level of an individual content segment, and enforced at the moment a question is asked. That granularity is what lets a single document serve both a press office and a legal team without duplicating it.
- No migration. The tool connects directly to databases that already exist. The original data stays put; nothing has to be copied into a new system. For a risk-averse buyer, "no migration" is sometimes the entire decision, because migration is where projects die.
- Safe indexing. Incremental indexing with snapshot rollback means a bad update can be unwound, and an accidental mass deletion is caught before it propagates. These safeguards earn trust over months, not demos.
- Proven pipeline. The full ingestion-to-answer pipeline was recently validated end to end, which matters more than any single benchmark when compliance is at stake.
- Compression that pays for itself. In one benchmark, a 443-page OFD document was processed in 124 seconds, and image compression cut LLM token cost by roughly 85.9% when tested against GPT-4o, while preserving seals and tables. For a team worried about inference bills, that number does real work — it turns a scary monthly cost into something manageable.
The patterns above apply to any local-first document stack, and you should evaluate them on the capabilities, not the badge. I have written more about the reasoning behind these design choices on our engineering notes.
Distribution lessons for a trust-sensitive product
Distribution for a trust-sensitive product is different from shipping a consumer app, and I underestimated how different. A few things I learned the hard way:
- Lead with the constraint, not the feature. "Runs on your hardware" is the headline; search quality is the footnote. Buyers in this space filter on the constraint first.
- Write for the evaluator, not the user. In public-sector and regulated buys, the person reading your page is often not the person using it. They need audit language, not a tour of the interface.
- Proof beats adjectives. "Fast" is forgettable; "124 seconds for 443 pages, seals preserved" is verifiable. Concrete numbers are your cheapest form of trust.
- Community beats ads. For an indie maker, an honest thread about the build teaches more than a campaign ever could, and it surfaces the exact objections you need to design around.
- Expect a long tail. This is not a launch-day spike business. The deals are fewer, the cycles are longer, and a single signed contract can outweigh a hundred free signups.
A generic evaluation lens
If you are building a document knowledge system, here is the lens I wish I had started with. This is not a product comparison — it is the checklist I use to judge any option, including my own:
| Dimension | What to look for | Why it matters |
|---|---|---|
| Data residency | Data stays in your environment, no external copy | Breach and compliance risk |
| Permission granularity | Control down to content segment, enforced at query | One doc, many audiences |
| Migration-free | Connects to existing stores directly | Lower risk, faster adoption |
| Rollback | Snapshots plus mass-deletion guard | Recover from bad updates |
| Audit | Clear record of access and changes | Procurement and regulation |
I keep this table pinned above my desk. Whenever I am tempted to add a feature that does not serve one of these five rows, I stop. For a local-first product, scope discipline is a trust signal too. The fuller version of this framework lives on the main site.
The moat is the alignment
The path for a local-first document tool is slower and more relationship-driven than a typical SaaS launch, but the moat is real. When your entire promise is that the customer's data never leaves their building, every part of the product — pricing, permissions, even how you write about it — has to point the same direction. Get that alignment right, and the rest is just shipping. The document mess is not going away; 3 trillion PDFs and 2 billion daily uploads suggest it is getting worse. Someone has to help organizations tame it without handing the keys to the cloud, and that someone can be a small team with the right constraints.
Try it now
- Explore the product lineup: https://www.uglypear.com/en/products/
- Read the engineering blog: https://www.uglypear.com/en/blog/
- Visit the homepage: https://www.uglypear.com/en/
FAQ
Is this a buy-once license or a subscription?
The core engine is sold as a one-time license: you pay once, you run it, and it keeps working without a recurring fee. Optional paid tiers exist only for services that genuinely cost money to maintain, such as hosted validation or priority incident response. The recurring part is framed honestly as a service, not a toll on your own data.
Can it run fully offline, including in an air-gapped environment?
Yes. The product is designed to operate entirely within your own infrastructure, with no dependency on an external network once deployed. That includes air-gapped networks where no outbound connection is permitted at all. Your original data stays where it is, and nothing is copied out to a third party.
How is this different from a public-cloud SaaS document tool?
A public-cloud SaaS stores and processes your documents on infrastructure someone else operates, which means your data crosses a trust boundary you do not control. A local-first deployment keeps the data inside your environment and connects directly to the stores you already have, with access control enforced at the moment a question is asked. The difference is not one feature — it is where the data physically resides and who can reach it.
Where does the data physically reside?
On infrastructure you control — your servers, your databases, your network. The tool connects directly to the databases that already exist, so the original data stays put and is never migrated into a separate system. There is no external copy created as part of normal operation.