Case study · Digital identity

Ridid

Reading the machine-readable zone of an ID card accurately, on the device, at a reception desk, so a legal obligation becomes a few seconds of work.

Delivered · Client-led expansion

Engagement
Client-side applications and OCR engineering
Platforms
Android application and responsive web
Role
Applications and OCR; client built the server
Market
Spain and Andorra Verify before publishing
The Ridid system: an ID card being scanned at hotel reception with the MRZ highlighted, the auto-filled guest form with the signature pad, and the same flow mirrored on the web application.
Industry
Digital identity
Users
Hotel reception and managers
Technique
On-device OCR of the MRZ
Platforms
Android + web
Role
Client applications
Status
Delivered

01The business situation

A legal obligation should not be a paper ledger.

Hotels in Spain are required to keep guest identity records current with the authorities. Traditionally that means transcribing documents into a book at reception: slow, error-prone, and dependent on whoever is on shift. Every identity document already carries a machine-readable zone designed to be read by a machine. The product simply had to read it, accurately, on whatever hardware the front desk happened to have.

Core challenge

Extract the machine-readable zone accurately across many card variants, on the device, without the guest waiting at the desk.

Before

Documents transcribed by hand at reception

  • Manual Transcription
  • Paper Ledgers
  • Transcription Errors
  • Delayed Filing

After

Scanned, verified and filed while the guest checks in

  • Reception
  • MRZ Scan
  • Verified Form
  • Authority

Ridid Platform

02The system at a glance

One capture. Four connected parts.

  • Reception Web App Same flow at a front-desk terminal
  • Android Application Scan at the desk or on the move
  • OCR Pipeline MRZ extraction on the device
  • Guest Record Verified data and signature
Core PlatformOn-device extraction, server-side filing
  • MRZ Scanning
  • Card Variant Handling
  • Form Pre-fill
  • Address Capture
  • Signature Capture
  • Authority Submission

03Workflow 01

The document fills the form.

The guest hands over their card. The scan reads its machine-readable zone, and the fields that would have been typed appear already filled and already verified against the document itself.

Image placeholder The scanning flow: an ID card in the camera frame with its machine-readable zone highlighted, and the guest form beside it populated from the extracted data. assets/portfolio/ridid/workflow-scan.png · 16 / 11
  • Read, not retypedFields come from the document, which removes the transcription step and the errors that come with it.
  • Many card variantsDifferent national and document types are handled by the same capture flow.
  • Verified by constructionBecause the data comes from the machine-readable zone, what is filed matches what was presented.

04Workflow 02

Two clients, one accuracy problem, solved twice.

Keeping OCR on the device meant solving accuracy separately for Android and for the browser. Each got its own approach, tuned against the same set of real cards.

  1. 1Capture the card

    Image placeholder Camera capture with card alignment guides and the machine-readable zone detected at the foot of the document. assets/portfolio/ridid/step-capture.png · 1 / 2.04

  2. 2Extract & pre-fill

    Image placeholder Extracted fields shown for confirmation before they populate the guest form. assets/portfolio/ridid/step-extract.png · 1 / 2.04

  3. 3Address & signature

    Image placeholder The completed guest form with the address captured from the card and the on-screen signature pad. assets/portfolio/ridid/step-signature.png · 1 / 2.04

05Workflow 03

We built the front. The client built the back.

The client, Arturo Lopez, an entrepreneur from Andorra and a technologist himself, chose to own the server side, building his API in Flask. Our work was everything the guest and the receptionist touch, plus the extraction, with a clean API boundary between the two.

  • A clear API boundaryThe client’s server exposed the interface our applications submitted to, which let both sides move independently.
  • Parity across surfacesThe web application deliberately mirrors the mobile flow so reception staff learn one process.
  • Handed on for expansionA later machine-learning module for extraction was integrated for the client to take forward.
Image placeholder The responsive web application at a reception terminal: the same scan-and-fill flow as the mobile app, with the guest record ready for submission. assets/portfolio/ridid/web-application.png · 16 / 10
Image placeholder The Android application showing the completed capture and its submission state. assets/portfolio/ridid/android-app.png · 1 / 2.04

06Engineering behind the product

The system behind an accurate scan.

Almost all of the effort went into one number: how often the extraction is right, across every card someone might present.

  • Client-side OCR by design

    Extraction runs on the device rather than the server, which keeps the document data local and the capture responsive.

  • Two independent implementations

    Because the OCR is client-side, accuracy had to be achieved separately in the Android application and in the browser.

  • Library evaluation

    Tesseract-OCR and Google Vision AI were tested and tuned per platform, with Vision AI giving the best accuracy until a machine-learning module took over.

  • Card variant tolerance

    Considerable time went into holding accuracy across different national and document formats rather than one ideal card.

  • Form pre-fill from MRZ

    Extracted data populates the guest form directly, which is what makes the filing trustworthy.

  • Address capture and signature

    Later phases added address extraction from the card and an on-screen signature pad to the same flow.

  • Handover-ready ML integration

    A machine-learning extraction module procured by the client was integrated for later use.

    Verify before publishing

07Technical architecture

Under the hood

Extraction runs on the client, so accuracy had to be achieved twice: once in Kotlin, once in the browser. The client built the server side himself.

Android

  • Kotlin
  • Tesseract-OCR
  • Google Vision AI

Web

  • VueJS
  • Google Vision AI

Client-built API

  • Python 3.x
  • Flask

Hardware

  • 3D-printed IoT module (client-procured)

08Delivery journey

How the system was delivered.

  1. Initial feature

    Interactive form generation for the client

  2. Market study

    Client validates Android-first

  3. Android build

    Scanning application with on-device OCR

  4. Accuracy phase

    Tune extraction across card variants

  5. Web parity

    Mirror the flow for front-desk terminals

  6. Later phases

    Address capture and signature

  7. Handover

    Integrate the client’s ML module and transition

The client is testing with vendors and has taken the project forward himself, with our support through the transition. Dates and durations are withheld until confirmed. Verify before publishing

09What the system enabled

What the delivered system enabled

  • Guest identity captured from the document itself
  • On-device extraction across many card variants
  • The same flow on Android and at a web terminal
  • Address and signature captured in one pass
  • Records filed with the authority in real time
  • A supported handover to the client’s own team

Related systems

Clunker Busters

Vehicle Inspection · Marketplace · Web + Mobile

A connected platform for customers, inspectors, operations, reporting and payments.

NEMS

Healthcare · FHIR Scheduling · Web

A FHIR-compliant patient scheduling platform for one of the largest non-profit community healthcare providers in the United States.

View case study , NEMS

Compliance work is still product work.

We treat a legal obligation as a user experience problem, because someone still has to do it at 2am.

Discuss your system