FormBridge

Capture critical forms online, fill them offline, submit later, and prove success with a receipt.

Comment

Inspiration

Online forms are gateways to jobs, education, funding, and public support, yet the interaction model assumes that power, data, and connectivity will last for an entire careful application session.

That assumption excludes people unevenly. World Bank data reports that about 35% of Kenyans used the internet in 2024. A Communications Authority of Kenya and KNBS survey summary reports a much wider internal gap: 64.7% internet use in Nairobi and 9.1% in West Pokot. The ITU also continues to measure entry-level broadband affordability against a target of 2% of monthly GNI per capita.

The FormBridge thesis is: separate the human task from the network task—capture online, fill offline, submit later, and prove success with a receipt.

Sources and context are collected in the repository’s evidence pack.

What it does

FormBridge turns one approved online form into a deliberate five-stage workflow:

  1. Capture online: Playwright reads common native fields from a controlled local form or an exact allowlisted target and saves a visual preview.
  2. Review: an operator verifies the source, field mapping, warnings, and exact form version before approving it for local use.
  3. Fill offline: the applicant completes and reopens drafts in an offline-capable PWA. Answers and queue records stay in local IndexedDB.
  4. Submit later: reconnecting never submits automatically. The applicant reviews the exact target and approves one browser-assisted submission.
  5. Prove success: FormBridge stores confirmation metadata, a screenshot, and a privacy-safe activity timeline as a durable receipt.

How we built it

The prototype uses Node.js and browser-native JavaScript. Playwright powers controlled form capture and later replay. A service worker caches only the application shell, while IndexedDB stores validated form definitions, drafts, queue snapshots, and settings in the browser.

The server persists relay jobs, idempotency claims, and receipts as inspectable local artifacts. Each submission is restricted by exact URL policy, bound to explicit consent, serialized through a durable queue, and checked against a versioned idempotency key. The worker stops on changed form actions, stale selectors, popups, downloads, disallowed redirects, CAPTCHA, and authentication boundaries.

The receipt API reconstructs its response from allowlisted fields. It cannot expose saved answers, applicant labels, or filesystem paths even if a legacy or malformed receipt file contains them.

Challenges

The hardest part was defining “offline submission” honestly. A form cannot reach its destination without a network, so FormBridge does not pretend that it can. Instead, the applicant’s careful work is offline and local; the short network-dependent handoff happens later and only with consent.

Browser replay also creates safety and reliability risks. We kept the target surface narrow, built controlled fixtures, verified the live method and action before submission, prevented duplicates, made retry manual, and treated confirmation as terminal even if later screenshot storage fails.

Finally, proof must not become a new privacy leak. The timeline and receipt contracts expose only operational metadata and never application values.

Accomplishments

  • A complete capture-to-receipt happy path runs against controlled forms.
  • Draft answers survive a real browser no-network cycle and reload from local storage.
  • Reconnection alone cannot trigger submission; one exact target requires explicit consent.
  • Durable jobs and idempotency claims prevent concurrent or repeated duplicate submissions.
  • Failures include bounded diagnostics and a manual cooldown-aware retry path.
  • Receipts include a confirmation screenshot and five-stage audit timeline without returning answers through public APIs.
  • The dashboard is keyboard-accessible, mobile-aware, and uses visible text—not color alone—for state.
  • Deterministic fictional demo data and an isolated end-to-end test make the prototype reproducible.

What we learned

Offline-first design is not mainly a caching problem. It is a state, consent, and recovery problem. The product has to explain what is local, what needs the network, what has not happened yet, and what counts as final success.

We also learned that evidence needs its own failure semantics. Once the source confirms a submission, a later screenshot failure must not make the application retryable. Reliability means preserving the true state, not just retrying every error.

What is next

The current build deliberately supports controlled targets and common static native fields. It does not claim arbitrary-site compatibility.

Future work starts with user validation and broader test coverage for legitimate static form patterns. After that, FormBridge could add guided deployment for trusted community operators, encrypted transfer between an applicant device and an approved relay, clearer compatibility reports, and field studies that measure connected time saved and successful completion rates.

CAPTCHA bypass, authentication bypass, anti-detection behavior, and mass submission remain outside the product boundary.

Links and artifacts

Built With

Share this project:

Updates