How I built a ~30 MB PDF editor that's 10× smaller than the industry standard

I was tired of PDF editors that took forever to download, launched slowly, and forced everything through the cloud. So I built RevPDF, a native PDF editor that's ~30 MB compared to the 300 MB bloat of standard industry tools.

I just wanted to edit my resume on the bus, but I found very few options to choose from on mobile. Some were laggy and buggy, many needed subscriptions, and most were cloud-based. Obviously, I didn't want my resume on a random server. I developed RevPDF to be small, roughly 30 MB, while many alternatives are 100s of MBs.

Here's how I did it, and the technical trade-offs I made.

The problem: PDF editor bloat

Most popular PDF editors have massive file sizes:

• Standard industry reader: ~150 MB
• Other popular reader: ~180 MB
• RevPDF: ~30 MB

Why are they so large? Because they're trying to do everything: cloud sync, telemetry, form builders, advanced graphics, collaboration features, update systems, and bundled runtimes.

Philosophy: do less, better

I analyzed what people actually do with PDF editors daily:

• Read PDFs (obviously)
• Highlight and annotate
• Fill forms
• Merge/split documents
• Basic editing (text, images)

That's it. 95% of users don't need 3D model rendering, advanced digital signatures, or cloud collaboration.

So I built RevPDF to do these core tasks exceptionally well, and nothing else.

Technical decisions

1. Native code, no Electron

Decision: Flutter, C++ instead of Electron.

Why: Electron bundles an entire Chromium browser. That's ~100 MB right there. Native frameworks give you access to OS-level PDF rendering.

Trade-off: More platform-specific code to maintain, but 10× smaller binaries and much faster startup.

2. Minimal dependencies

Decision: Write custom components instead of pulling in heavy libraries.

Trade-off: More initial development time, but total control over performance and size.

3. No cloud infrastructure

Decision: All processing happens locally. No accounts, no sync, no telemetry.

Why: Beyond privacy benefits, this eliminated the need for networking libraries, authentication systems, and sync engines. Turns out, removing features makes software smaller and more private.

Bonus: This resonated hard with European users. A German tech blog covered it and I got 5k+ downloads.

4. Smart asset management

Decision: No bundled fonts, icons as vectors not PNGs, compress everything.

Details: Use Google Fonts instead of bundling custom ones (-20 MB).

Performance results

What I gave up

To be clear, RevPDF doesn't do everything:

• No advanced digital signatures (basic signing only)
• No 3D PDF support
• No cloud sync
• No plugins/extensions

For 95% of users, these don't matter. For the 5% who need them, there's other tools.

What I learned

1. Feature subtraction is harder than feature addition. Saying "no" to features is difficult. Everyone wants their use case supported. But every feature has a cost in complexity, size, and maintenance.

2. Users care about speed more than features. The most common feedback: "It's so fast!" People are shocked when software just… works instantly.

3. Privacy as a feature, not just marketing. The "no cloud" requirement wasn't originally a selling point, it was an engineering decision to keep things simple. Turns out, people really care about this.

4. Different markets want different things. US users ask about features. European users ask about privacy and data handling. Both love the speed.

The code

RevPDF is closed-source for now.

Tech stack:

• Flutter, C++
• Cross-platform build system: CMake

Available for Windows, macOS, Linux, Android, and iOS. Desktop is completely free. Mobile (Android & iOS) is a $9.99 one-time purchase, no subscription, no ongoing fees.