Offline-first PWA for field data capture

Two connected pieces: a progressive web app used by field workers in agriculture, and a public verification page that a QR code resolves to. **1. Field app (PWA)** Installs to the home screen. Not a native app, no app store submission. Usable one-handed, outdoors, on a mid-range Android phone. - Register source plots with GPS coordinates; each gets a permanent QR identifier - Harvest logging: scan the source QR, submit. Target interaction under ten seconds - **Transfers: every physical handoff creates its own scan and its own ledger entry.** Location derives from the scan sequence, not hand entry. The chain must remain unbroken from harvest through bottling, with no skippable stages - Consolidation: scan each contributing source, record the quantity contributed by each, seal the combination. Once sealed, immutable - Laboratory step: upload the lab report file (PDF or image, up to 10MB) and manually enter the headline values plus the lab's accreditation reference, attached to a sealed consolidation. The uploaded file is hashed and that hash committed to the ledger, so the stored document can be shown to be the one originally submitted. Upload and storage are in scope; automated extraction of values is not - Bottling: create the lot, set volume and unit count, generate per-unit codes - **Full chain view for any lot**, showing every stage from source registration through to the live bottle QR - Always-visible sync status - Single operator account. No role hierarchy, no multi-tenancy **2. Offline operation — the hard requirement** There is no cell signal where this is used. The app must capture a complete record with no connection, persist it locally, survive the browser being closed, and sync without duplication or loss when connectivity returns. Queued file uploads must survive the same way. If you haven't built this before, this isn't the right job. Your reply should explain how you've handled sync conflicts. **3. QR generation and numbering** Permanent codes for source plots at registration. At bottling, each unit gets a sequential number within its lot and a QR resolving to that individual unit's verification URL. The lot's declared count is a hard ceiling — a scan above it must be rejected and shown as failed verification. Codes exportable as a plain sheet. Label artwork and print layout are not in scope. **4. Record chain and combined-hash requirement** Read this section carefully. It is the part of the build most likely to be implemented incorrectly. - Append-only ledger. Each entry carries a timestamp, an operator identifier, and a SHA-256 hash of the preceding entry's content, so any later alteration breaks the chain detectably. - **A consolidation and its laboratory results must be committed as a single hash computed over both together** — the contributing source identifiers and the chemical values concatenated into one input, in fixed field positions. Two separate records joined by a foreign key does not satisfy this. Altering either element must break the same hash. - **The verification page must retrieve chemistry and source identity in a single operation**, not two queries joined at read time. The stored structure has to make that possible. - A lightweight external anchor publishing the chain head periodically to an independent public location. I will supply the exact field order and concatenation format. You implement it as specified. **5. Validation rule** Compare input quantities against output unit counts and flag any lot outside a configurable plausible yield range. Both the yield flag and an invalid unit number must be unmistakable to a non-technical reader on the public page. **6. Public verification page** Fast, mobile-first, no login. Each unit resolves to its own permanent URL showing: every contributing source with its quantity and share of the blend, the custody timeline with timestamps, the laboratory values for that specific source combination with the lab reference and a link to the report on file, and the record's integrity status. A failed verification must be visually obvious. Under two seconds to load. I'll provide a working HTML design reference. **7. Acceptance criteria** The build is complete when these can be demonstrated live. Full list supplied with the spec; these four give you the shape of it: 1. A harvest is logged in airplane mode, the browser is closed and reopened, the record survives, and it syncs on reconnect without duplication 2. Three sources are consolidated with distinct quantities, sealed, and lab values attached — after which the record is immutable 3. Altering a historical ledger entry directly in the database causes the public page to display a failed verification state 4. A bottle number above the lot's declared count is rejected as invalid, and a lot with an implausible input-to-output ratio is flagged on the public page --- **Stack** React or Svelte; Node or Python; PostgreSQL; object storage for uploaded files; low-cost managed hosting. Your call on specifics — tell me why. Repository owned by me from the first commit. **How this works** I supply the specification, data model, and acceptance criteria. You build to them; you are not being asked to design the schema. Hourly, capped at 20 hours per week, milestone reviews. No fixed-price bids. NDA and IP assignment before detailed specs are released; assignment vests as each milestone is paid. **Explicitly not in scope** — proposals including these will be treated as non-responsive: Native iOS/Android apps · App Store or Play Store submission · IoT or environmental sensors · NFC · laboratory or third-party API integration · AI or automated PDF extraction · weather data · electronic signatures · multi-tenant or white-label architecture · interactive mapping beyond a coordinate display · self-serve onboarding · e-commerce or payments · print-ready label design · blockchain **Process** Written proposal → shortlist → paid technical exercise ($150, ~3 hours) building one offline capture screen against a stub endpoint → contract. **In your proposal, include:** 1. How you handle offline persistence and sync conflict resolution, in your own words 2. Two examples of offline or field data work, with links to running systems if possible 3. Your proposed stack and reasoning 4. Your hourly rate and weekly availability 5. Your own effort estimate once you've seen the spec 6. Anything here you think is under-specified or unrealistic — flagging genuine gaps counts in your favor