DEV Community: Ritusmoi Kaushik

I built a HEIC to JPG converter that never uploads your photos (WebAssembly + libheif)

Ritusmoi Kaushik — Tue, 14 Jul 2026 06:08:42 +0000

The privacy problem with "online HEIC converters", and how running libheif in the browser fixes it.

If you've ever helped a non-technical person get an iPhone photo to open on a Windows laptop, you've hit HEIC. Since iOS 11, iPhones save photos as .heic by default — roughly half the size of JPG at the same quality — and the rest of the computing world still chokes on it. Windows shows a black thumbnail, upload forms reject the extension, older apps just shrug.

The usual fix is to Google "HEIC to JPG converter", click the first result, and upload your photos to a server you know nothing about. That's the part that always bothered me. A camera roll isn't holiday snaps — it's ID scans, medical documents, kids, things people photographed because they were private. Shipping those to a stranger's box for a format conversion, then trusting an unverifiable "deleted after 1 hour" banner, is a bad trade.

So I built the converter to run entirely in the browser — no upload, no server, nothing leaves the device. Here's how it works and what tripped me up.

The core idea: decode HEIC where the file already is

HEIC is HEVC-compressed image data in a container. Browsers can't decode it natively (that's the whole problem), so you ship the decoder yourself. Under the hood that's libheif compiled to WebAssembly — I use the heic2any wrapper around it, which handles the decode-and-re-encode in one call.

The flow is entirely client-side — no fetch, no upload endpoint, no backend:

File (.heic)
  → heic2any (libheif WASM) decodes + re-encodes
  → Blob (image/jpeg or image/png)
  → URL.createObjectURL → download

You can prove it: open DevTools → Network tab, drop a file, and watch nothing happen. The page loads, then silence.

The whole conversion is a few lines. Two decisions matter: lazy-load the decoder and process files one at a time.

const MAX_INPUT_BYTES = 25 * 1024 * 1024;

async function processFiles(files: File[]) {
  // Reject oversized files up front — HEIC decode is memory-heavy (see below)
  const tooBig = files.find((f) => f.size > MAX_INPUT_BYTES);
  if (tooBig) return fail(`${tooBig.name} is over 25MB.`);

  // Dynamic import: the WASM decoder only downloads when someone actually
  // converts — it stays out of the initial page bundle entirely.
  const heic2any = (await import("heic2any")).default;

  const out = [];
  // Sequential, NOT Promise.all — a parallel batch blows the heap (see below)
  for (const file of files) {
    const blob = await heic2any({
      blob: file,
      toType: outputFormat,      // "image/jpeg" | "image/png"
      quality: quality / 100,    // slider, defaults to 0.9
    });
    const finalBlob = Array.isArray(blob) ? blob[0] : blob; // heic2any can return Blob[]
    out.push({ name: rename(file), url: URL.createObjectURL(finalBlob) });
  }
  return out;
}

Three things that tripped me up

1. The first conversion is slow — and that's fine. The libheif WASM module is chunky (over a megabyte). Because it's behind a dynamic import(), it only downloads the first time someone actually converts — it never touches the initial page load — and the browser caches it after that, so every conversion afterward feels instant. Compared to the typical converter site loading 4–6 MB of ad scripts before you can even drop a file, one lazy-loaded module is a good deal. I just made the "first HEIC takes longer (decoder loading)" state explicit in the UI so the first hit doesn't feel broken.

2. Memory, not CPU, is the real ceiling. Decoding HEIC allocates a full RGBA bitmap — width × height × 4 bytes. A 48 MP photo is ~190 MB decoded, before you've even re-encoded it. On desktop, fine. On a mobile Safari tab with a hard memory cap, big files kill the tab. So I cap input at 25 MB per file and run the batch sequentially — the for … await loop above, not Promise.all — so ten files don't allocate ten bitmaps at once.

3. Lossy → lossy needs a quality escape hatch. HEIC → JPG re-encodes already-decoded pixels into another lossy format. At quality: 0.9 it's visually identical for photos; below ~0.8 you start seeing it on smooth gradients (sky, skin). I exposed a quality slider and default it to 90, and offer PNG for anyone who wants zero loss after the decode step.

Why bother when Apple's "Most Compatible" setting exists

You can tell an iPhone to save JPG going forward (Settings → Camera → Formats → Most Compatible), and everyone should. But that does nothing for the thousands of HEICs already in the camera roll — those still need converting, and that's the job this tool does without asking anyone to upload anything.

If you want the deeper non-technical version of the HEIC-on-Windows mess — the black-thumbnail bug, the Microsoft extensions, why some files won't open even after you install everything — I wrote that up here: Why HEIC files won't open on Windows.

And the tool itself, if you want to poke at it (or watch the Network tab stay empty): HEIC to JPG converter.

Takeaway

For a whole class of "convert this file" tools, the server is a liability, not a feature. WASM builds of the underlying C libraries — libheif, libvips, mozjpeg, pdfium — are good enough now that the file never has to leave the device. Faster for the user, zero privacy surface for you, and no infra to run. That's the direction I'm taking the rest of the tools too.

What other file conversions are you still uploading to a server that could run locally? Curious what people are stuck on.

Why Your iPhone Photos Won't Open on Windows (and the 5-Second Fix)

Ritusmoi Kaushik — Fri, 10 Jul 2026 08:57:07 +0000

Your phone saves them as HEIC. Your laptop shrugs. Here's what's actually going on — and how to stop fighting it.

About once a week, someone I know forwards me the same panicked message. iPhone in one hand, Windows laptop open in front of them, and a photo called something like IMG_4821.heic that just… won't open. They double-click it. Nothing. They email it to themselves and try again. Same shrug from Windows. By the time they message me, they're half-convinced the photo is corrupted or their laptop is broken.

It's neither. The photo is fine. The laptop is fine. What you're running into is a quiet decade-old standoff between Apple and the rest of the computing world, and once you understand it, the fix takes about five seconds.

The one-sentence version of what's happening

Since 2017, iPhones save photos as HEIC instead of JPG by default. HEIC is a genuinely better format — roughly half the file size at the same visible quality — which is why your 256 GB phone lasts as long as it does. The catch: Windows, most web upload forms, older email clients, government portals, and a long tail of everyday software never fully caught up. So the moment a HEIC file leaves the Apple ecosystem, it hits a wall.

That's the whole problem. Not malware, not corruption, not your fault. Just a format your iPhone loves and your laptop doesn't recognize.

Why Windows specifically chokes on it

Windows didn't support HEIC natively until late in the Windows 10 cycle, and even then you had to go install an extension from the Microsoft Store to get it working. Windows 11 looks like it should handle HEIC out of the box — it ships with partial support — but in practice you'll still often see a black or blank thumbnail in Explorer, or the Photos app throwing an "unsupported format" error.

And here's the part that trips people up even after they fix the viewing problem: being able to view a HEIC file and being able to upload one are two completely different things. You can install every Microsoft extension there is, get gorgeous HEIC previews in Explorer, and still have a job-application form or a bank's KYC portal reject your .heic on the spot — because those forms check the file extension, not whether your operating system happens to have a decoder. For anything you need to send or upload, JPG is still the only format that works everywhere, every time.

Fix #1: Stop the bleeding at the source

If you regularly share photos with Windows users or upload to forms, the cleanest long-term fix is to tell your iPhone to just save JPG from now on:

Settings → Camera → Formats → Most Compatible.

Every new photo from that point forward saves as a standard JPG. Old photos stay as HEIC, but you stop creating new ones. You give up a little of that storage efficiency, but for most people the "it just opens anywhere" tradeoff is worth it.

Fix #2: Convert the HEIC photos you already have

The setting above only helps going forward. For the photos already sitting in your camera roll, you need to convert them — and this is where most people make a small mistake that I'd rather you avoid.

The typical move is to Google "HEIC to JPG converter," click the first result, and upload your photos to some random server for conversion. For holiday snaps, fine. But think about what's usually in a camera roll: ID scans, medical documents, kids, things you took a photo of specifically because they were private. Uploading those to a stranger's server for a format conversion, and trusting an unverifiable "deleted after one hour" promise, is a worse deal than people realize.

You don't have to. Modern browsers are fast enough to do the entire conversion locally, on your own device, without a single byte leaving your machine. I've been using Fileoholic's HEIC to JPG converter for exactly this — you drop the file in, it converts in the browser tab using a local WebAssembly decoder, and you download the JPG. No upload, no signup, no daily limit. If you're the paranoid type (healthy instinct), open your browser's DevTools, watch the Network tab, and drop a file: you'll see the page load and then silence. Your photo never goes anywhere.

The honest take

Apple made the right technical call with HEIC. They arguably made the wrong product call by flipping every iPhone to it by default in 2017, years before Windows, Android, and the web were ready. We've all been quietly cleaning up that mismatch ever since — which is why "convert HEIC to JPG" remains one of the most-searched file-format questions on the internet.

If you want the deeper version of all this — the Windows 11 quirks, the black-thumbnail bug, the Microsoft extensions, and why some HEIC files still won't open even after you install everything — I wrote a full walkthrough here: Why HEIC files won't open on Windows (and the simple fix).

But if you just need the photo to open right now: change the camera setting, convert the ones you already have in your browser, and get on with your day. It's a five-second tax for an inbox that just works.

Billing a Bulk Endpoint Where Any Row Might Be Free

Ritusmoi Kaushik — Fri, 10 Jul 2026 07:35:32 +0000

I already had per-invoice billing working: reserve a credit, do the expensive call, settle or refund. Then I added a bulk endpoint — paste a list, verify them all — and the neat single-item model fell apart, because in a batch some rows cost money and some are free, and you don't know which is which until you've done the work.

This is the metering design behind the bulk GSTIN verification tool on GSTExtract — a solo GST SaaS — and the two bugs I hit building it. The interesting part isn't the happy path. It's that "charge for a batch" quietly becomes "charge for the subset of the batch that turned out to be billable, without overselling and without spending the paid API on rows the user can't pay for."

The setup

A user pastes up to 50 GST numbers. For each, I call a paid third-party registry API and return the business name, status, and address. Each fresh API call costs me real money, so the rule is 1 credit per fresh successful lookup. But three kinds of rows are free:

Cached — I cache every result for 30 days. A repeat lookup of the same number costs me nothing, so it costs the user nothing.
Not found — the API has no record. No data delivered, no charge.
Invalid format — rejected by a regex before any call. Obviously free.

So a "50-item" request might bill for 12. And I can't know the 12 up front — cached vs fresh I can tell, but found vs not-found needs the call. That's the whole problem in one sentence.

Why the single-item model doesn't lift

My invoice path uses the classic reserve → settle → refund: reserve one credit before the vision-model call, settle the real count after, refund on failure. For a batch, the temptation is to do it once for the whole thing: read balance, fetch everyone, charge the found count at the end.

bal = current_balance(db, uid)
to_fetch = fresh[:bal]              # cap to what they can afford
results = await fetch_all(to_fetch)
found = sum(1 for r in results if r["found"])
charge(db, uid, found, allow_partial=True)   # <-- the hole

This oversells. Two concurrent requests both read bal = 10, both fetch 10, both try to charge — the first charges 10, the second charges 0 because allow_partial floors at zero, and that second user just got 10 paid API calls for free. It's the exact race the single-item path was designed to avoid, reintroduced the moment I batched it. Read-then-write is not atomic no matter how you dress it up.

Reserve per item, refund the misses

The fix is to keep the atomic reserve, but do it per GSTIN, and refund the ones that turn out free:

async def one(g):
    key = f"gstinbulk:{base}:{g}"
    # atomic reserve of 1 credit — a single conditional UPDATE, gated on rowcount,
    # so two concurrent reserves for the last credit can't both win
    if not reserve_one(uid, key):
        return g, None, "deferred"          # out of credits — don't call the API
    async with sem:                          # bound API concurrency
        r = await asyncio.to_thread(fetch, g)
    if r["found"]:
        return g, r, "charged"               # keep the reserved credit
    refund_one(uid, key)                      # not-found / failed = free
    return g, r, "free"

Each item reserves before its own paid call. A reserve failure means the balance is gone — that row is deferred, and crucially no API call is made for it, so you never burn the paid quota on a row nobody paid for. Found rows keep the reserve. Everything else refunds. The billable total is just the count of "charged", and it's correct under concurrency because the atomicity lives in the credit reserve, not in a Python-side balance read.

The reserve itself is a conditional update, not a read-modify-write:

UPDATE credit_lots SET remaining = remaining - 1
WHERE id = :lot AND remaining >= 1

Gate on rowcount: exactly one of two racing reserves for the last credit gets rowcount = 1; the other gets 0 and is told it's out of credits. SQLite serializes writers, so this holds without an explicit lock.

One more subtlety: the refund on a not-found must not feed the abuse counter. My invoice path counts a refunded failure toward a per-user daily "unreadable file" budget — a junk-upload guard. A not-found GSTIN is a perfectly normal result, not abuse, so bulk uses a plain reserve-release, not the failure-counting refund. Same primitive, different accounting.

The bug that actually cost me an hour

My first version ran the reserve inside asyncio.to_thread, alongside the fetch, thinking "offload all the blocking work." The tests immediately threw:

sqlite3.InterfaceError: bad parameter or other API misuse

The reserves were now happening on worker threads, several at once, against one SQLite connection. A SQLite connection isn't safe to share across threads like that. The fetch — an HTTP call — genuinely belongs in a thread. The DB writes do not.

The fix is a one-line conceptual rule: DB stays on the event loop; only the slow HTTP call is offloaded.

if not reserve_one(uid, key):     # sync, on the loop — fast local write
    return g, None, "deferred"
async with sem:
    r = await asyncio.to_thread(fetch, g)   # only this leaves the loop

The reserves are quick local writes; running them on the loop serializes them naturally and keeps them single-threaded, which is exactly what SQLite wants. The concurrency I actually needed was for the network calls, and those are the only thing that fans out now. This mirrors how the invoice path already worked — I'd just forgotten why it worked when I reached for to_thread on the DB.

The free tier, and one export gotcha

Anonymous users get a small daily cap of free fresh lookups (for the SEO/demo value), metered per IP; cached hits don't count, so re-checking the same list is always free. Logged-in users draw from credits as above.

And a non-billing one worth flagging: the results export to an .xlsx, and the values include names pulled from the registry plus, in the export path, client-submitted rows. A cell value starting with =, +, -, or @ is a formula-injection vector when the file is opened. Prefix those with a quote:

if s and s[0] in ("=", "+", "-", "@", "\t", "\r"):
    s = "'" + s

Cheap, and it turns a "download to Excel" feature into one that can't ship a live formula from untrusted input.

The takeaway

"Meter a batch" is three problems wearing one coat: the count is unknown until the work runs, some of the work is free, and it all happens concurrently. Reserve per item and the three collapse into one — each row gates itself, pays for itself, or refunds itself, and the total falls out correct. Keep the DB writes on the loop and let only the network fan out.

If you want to see the endpoint from the outside, it's the bulk GSTIN verification tool; the invoice-extraction engine it sits next to is open source. The billing primitives are the same ones from the earlier write-up on the single-item ledger — this is what happened when I pointed them at a batch.

Metering a Paid API Without Overselling: the Credit Ledger Behind a Solo SaaS

Ritusmoi Kaushik — Tue, 16 Jun 2026 07:10:36 +0000

I charge per invoice extracted. One upload of a five-invoice PDF should cost five credits, a failed extraction should cost nothing, and a user with one credit left must never get two. That last rule is where it got interesting.

This is the billing design behind GSTExtract — a tool that reads Indian GST invoice PDFs into Excel — and the concurrency bug a second-pass audit found in it. Writing it up because "meter a paid API correctly" is one of those problems that looks trivial until you hold it up to the light.

The shape of the problem

Each extraction calls a vision model, which costs me real money. So the user spends a credit per invoice. The catch: I don't know how many invoices are in a PDF until after the model reads it. A single page can hold three invoices; a "10-page" file might be one. I can't charge up front because I don't know the count, and I can't charge after without a window where a user with a zero balance has already burned my API budget.

The answer most billing systems land on is reserve → settle → refund:

Reserve one credit before doing the expensive work. This is the gate — if it fails, the user is out of credits and nothing runs.
Settle after success: charge the actual count minus the one already reserved.
Refund the reserve if the extraction failed, so failures are never billed.

Money and credits are integers. Every change is also written to an append-only ledger with an idempotency key, so a retry can never double-charge. Balance is derived: the sum of remaining credits across non-expired "lots" (a lot is one grant — a signup bonus, a purchase). Consumption is FIFO by soonest expiry, so credits get used before they lapse.

That part worked. The bug was in the word "atomic."

The bug: two uploads, one credit

The original charge function did the obvious thing:

# read the balance
bal = current_balance(db, user_id)
if bal < n:
    return False, 0
# ... then walk the lots and decrement in Python
for lot in lots:
    take = min(lot.remaining, remaining)
    lot.remaining -= take          # <-- writes an ABSOLUTE value

Read the balance, decide, write the new value. Single-threaded, this is fine. Now picture a user with exactly one credit firing two uploads at the same moment (a double-click, or two tabs):

Request A reads remaining = 1. Decides it's allowed.
Request B reads remaining = 1. Also decides it's allowed.
A writes remaining = 0, inserts a -1 ledger row.
B writes remaining = 0, inserts a -1 ledger row.

Both succeed. The user spent one credit and got two extractions. The idempotency key didn't save me — the two requests had different keys, because they're two genuinely different uploads. The read-then-write-absolute is the classic lost-update race.

The fix: let the database do the deciding

The cure is to stop computing the new value in Python and let the write itself be the gate — a conditional UPDATE that only fires if there's still enough left, checked under the row lock:

res = db.execute(
    update(CreditLot)
    .where(CreditLot.id == lot_id, CreditLot.remaining >= take)
    .values(remaining=CreditLot.remaining - take)
)
if res.rowcount == 1:
    taken += take      # we actually got it
# rowcount 0 → someone else took it first; move on or roll back

remaining = remaining - take instead of remaining = <number I computed>. The WHERE remaining >= take re-checks the balance at write time, and SQLite serializes writers, so the second request blocks, re-evaluates against the now-committed remaining = 0, gets rowcount = 0, and is correctly told it can't reserve. Exactly one upload wins. Balance can never go negative.

I proved it with a test that fires N concurrent reservers at a one-credit account on a real file-backed SQLite DB (WAL mode, busy timeout — same as production, because an in-memory shared-connection DB won't reproduce writer contention). Exactly one succeeds, every time.

The second bug: a retry that costs me money

There was a sneakier one, found in the same audit. The workspace retries an upload once on a dropped connection, reusing the same request_id so it doesn't double-charge. And it didn't double-charge — the ledger keys saw to that. But the idempotency cache was written after the model call, not before. So a retry that arrived while the first call was still in flight sailed past the cache check and fired a second vision-model call. No double charge, but I paid for two API calls and logged a duplicate usage event.

Fix: mark the request in-flight before the expensive call, while everything above it is still synchronous (so two requests can't both pass the check), and have a retry return 409 instead of re-running:

cached = _REQUESTS.get(rid)
if cached:
    if cached.get("in_flight"):
        return JSONResponse({"code": "in_progress"}, status_code=409)
    return JSONResponse(cached["response"])
# ... reserve the credit ...
_REQUESTS[rid] = {"in_flight": True}   # before the model call

The lesson that keeps repeating: idempotency has to cover the side effect, not just the database row. The charge was idempotent. The expensive API call wasn't.

Why an append-only ledger earns its keep

The thing that made all of this debuggable: nothing is ever updated or deleted in the transaction log. Every grant, charge, and refund is an immutable row with a signed delta. That gives you a reconciliation invariant you can assert on a schedule:

the sum of all ledger deltas for a user == the sum of remaining across all their lots

If those two numbers ever disagree, a write went wrong, and an alert fires. (I also learned to not fold a cache-freshness check into that alert — a balance cache that goes stale when a credit quietly expires is not corruption, and it had me chasing phantom "drift" emails for a day.)

Takeaways

Don't read-modify-write a balance. Make the write conditional (WHERE remaining >= n) and trust rowcount.
Reserve → settle → refund cleanly separates "can they pay" from "what did it actually cost."
Idempotency must guard the expensive side effect, not only the ledger insert.
An append-only ledger gives you a cheap, always-true invariant to reconcile against.
Write the concurrency test against a real on-disk DB, or it won't reproduce the race you're trying to kill.

The hosted tool has a free daily tier and twenty free credits on signup, with prepaid packs for heavier use — so this ledger runs on every extraction, and I'd rather it be boringly correct. If you want to see it in action, it's at gstextract.com; the extraction engine is open source, though the billing layer above is part of the hosted product.

If you've metered a paid API differently — especially how you handle the count-unknown-until-after problem — I'd genuinely like to hear it.

I Open-Sourced the Core of My GST Tool. Here's What I Kept Private.

Ritusmoi Kaushik — Tue, 21 Apr 2026 07:12:18 +0000

A few days ago I published the core extraction engine of GSTExtract on GitHub, MIT licensed. The repository is here. It's not the full product. It's a seven-week-old snapshot, and that gap is the whole strategy.

This post is about the decisions I made picking what to open-source and what to keep private. The deciding took longer than writing the code did, which surprised me. Writing it up in case anyone else is staring at the same question on their own project.

Context, Briefly

GSTExtract reads Indian GST invoice PDFs and pulls out the fields (GSTIN, invoice number, amounts, taxes) into Excel. Small businesses and accountants use it at month-end to avoid hand-typing supplier bills into Tally. The stack is Python — pdfplumber for digital PDFs, Tesseract OCR as fallback, regex + keyword-anchored extraction, openpyxl for Excel output. FastAPI wraps it for the hosted version. The hosted tool is free during early access, with a paid tier planned for high-volume users later.

So the question was: how do I open-source without giving away the commercial edge?

What Went Public

The deterministic regex plus keyword extraction pipeline. GSTIN parsing with the Luhn mod-36 checksum. Zone segmentation that splits an invoice into header and footer and routes fields by zone. Tax-line detection with keyword anchoring. Excel export. The test suite. Basically, the commoditised parsing work that anyone doing invoice extraction would eventually re-implement themselves if they cared enough.

If someone wants to understand how you pull GSTINs and invoice totals out of a messy PDF, the code is all there. Forkable, patchable, usable in their own pipelines.

What Stayed Private

The seven weeks of engine refinements since the cut point:

Multi-vendor accuracy tuning for Amazon, Flipkart, Swiggy, Zomato, BookMyShow, RedBus, and Myntra invoices (each one has a slightly different layout that breaks generic extraction)
Table-based tax extraction for borderless PDFs
Multi-invoice detection for combined bundles
Per-field confidence scoring refinements
Proprietorship invoice edge cases (handwritten-style templates that use bare "FROM" labels instead of "BILL FROM", single-digit invoice serials, and so on)

Plus the entire webapp: FastAPI layer, rate limiting, CSRF, file validation, the invoice validation gate that rejects credit notes and proforma bills, the batch upload flow, the learning-data logging. All of that stays closed.

Why the Time-Lag

This is the part I thought about most. Just publishing the latest engine would let anyone stand up a competing extraction site with the same accuracy I have. Publishing a snapshot from seven weeks ago means competitors get a working baseline, but not the current edge. The engineering work I do this month becomes public (maybe) in a few months, not immediately.

Redis, MongoDB, and Elastic have all done versions of this. The open-core pattern: community gets a real, working version of the core. Commercial version stays ahead by some time delta. Nobody feels cheated, but the pricing power stays intact.

For me, the specific cut was commit 0aa5f07 from 2 March 2026, labeled "Phase 12 production hardening" in the private repo. Engine is solid from there. Everything after is refinement.

What I Expect to Get From This

Honestly, the single biggest thing is the backlink. GitHub has domain authority 96. Having a public repo that links to gstextract.com from the README gives my young domain an authority signal it couldn't easily get any other way. On a site that's only a couple of months old and trying to rank for competitive GST queries, that one dofollow link is legitimately meaningful.

After that, in descending likelihood:

Credibility signal to technical readers who want to see how the extraction works. Some fraction of people evaluating a hosted tool will check if the code is worth trusting.
Issues and pull requests from people hitting edge cases I haven't seen. GST invoice formats are wilder than you'd think. Someone will inevitably send me a PDF from a vendor I've never heard of that breaks something.
Forks from people who need self-hosted extraction for their own use cases. Rare, but they become potential collaborators.

What I'm not expecting: hundreds of stars, viral adoption, a community forming around the repo. For a narrow Indian-GST tool, the realistic audience is small. A handful of serious users finding it and either using it or contributing is the bar, not hockey-stick open-source growth.

Honest Tradeoffs

What this might cost me:

Competitors can clone and study the extraction logic. They would eventually anyway, but I've shortened the path.
Time maintaining the public version even if nobody uses it. If I ignore it for months, it rots and becomes a bad signal.
Some fraction of potential paying customers might think "well, the core is free, I'll just self-host" and walk away. I don't think this is many people, but it's nonzero.

What I'm betting:

The moat is distribution plus the continuous-improvement time-lag, not the code itself.
Most competitors don't actually want to self-host and maintain a parser, deal with Tesseract and Poppler, manage their own uptime. Running the hosted tool is a service, not just code.
People who'll pay for the hosted version are paying for the current-version edge, the no-setup convenience, and whatever the product becomes post-launch. The snapshot on GitHub is closer to educational than competitive.

We'll see if that's right. If self-hosting forks start cutting into hosted usage in a measurable way, I'll revisit the cut-point. For now, the calculus feels fine.