Business Cards Without the Cloud: PaddleOCR in React Native Sped Up from 7.8 to 3 Seconds

A business card scanner looks like a one-evening task: take a photo, send it to an API, get back a name and phone number. But the card doesn't belong to you; it belongs to a third party. Their name, number and job title end up on a server without their knowledge, and in Russian practice this runs into Federal Law 152-FZ. The team described by the author of an article on Habr solved the problem radically: the photo never leaves the phone.

What They Built and Why Without an LLM

The stack is PaddleOCR v5 running through ONNX Runtime inside a React Native app on Android. In other words, the recognition model lives on the device, and no network is needed to process the image.

The author specifically mentions that they ruled out an LLM. The announcement doesn't give details, but the reasons are usually clear. A large model on a phone is heavy and slow. If you call it in the cloud instead, you're back to the original problem: the photo leaves the device. For a business card, where you only need to extract a few short fields, classic OCR plus parsing rules often turns out to be more practical. This is not a conclusion of the article but a general engineering rule of thumb, though it explains the choice well.

A simple example. The user photographs a card, OCR finds the text blocks and reads them, and the app uses templates to decide which is the phone number, which is the email and which is the name. All of this happens locally, and in the end the person sees a filled-in contact card.

From 7.8 to 3 Seconds

The most striking figure in the announcement: image processing got faster, from 7.8 to 3 seconds. The difference is fundamental for the product. Nearly eight seconds of waiting after the shot feels to the user like a frozen app. Three seconds is still tolerable, though far from instant response.

The announcement doesn't say exactly how the speedup was achieved; for details you'll have to go to the full text. But on-device OCR on a phone has the usual places for optimization: input image size, the number of model runs in the pipeline, the weight format, and the way data is passed between JavaScript and native code. In React Native the last one is often the bottleneck.

ONNX Runtime's Hidden Telemetry

The most useful detail for practitioners is not about speed but about privacy. The author writes that ONNX Runtime sends something to Microsoft by default. The announcement doesn't specify what exactly or in which builds, so the exact scale of the leak can't be assessed. But the lesson itself matters: the words "the model runs locally" don't guarantee that the app makes no network calls at all.

For a product built on the argument that "data doesn't leave the device," this is critical. If your privacy policy promises one thing while a library quietly does another, you get both legal risk and a loss of trust.

What Developers and Product Managers Should Do

• Check the app's network traffic on a real device, not just the code. A proxy such as mitmproxy will show where requests go.
• Study the settings and builds of every dependency that handles user data, especially photos and documents. Disable everything you don't need.
• Build speed into your product metrics. Local processing is almost always slower than cloud processing, and the difference between 7.8 and 3 seconds decides whether people will use the feature.
• Don't reach for an LLM by default. For a narrow task with a clear structure, lightweight on-device OCR can win on privacy, cost and predictability.

Limitations

We saw only the announcement: it contains no full measurements, phone models, recognition accuracy or comparison with cloud solutions. The figures of 7.8 and 3 seconds apply to the team's specific configuration and may differ on other hardware. The legal interpretation of Federal Law 152-FZ also depends on your case, so the question is worth discussing with a lawyer.

Nevertheless, the case shows a workable path: a closed data perimeter, mature open-source OCR and careful verification of what dependencies actually do. For teams building apps that handle personal data, this is a good checklist for the next sprint.