This post walks through an architecture we used for a local-first quoting client aimed at driveway / bay workflows — specifically auto detailing estimates — where offline is the default, not a fallback banner.

The problem (product → engineering)

A quoting tool that requires a round-trip to create a draft is a liability on site. Requirements that drove the stack:

1. Create and edit line-item quotes with zero network.

2. Attach compressed vehicle photos to the same record.

3. Generate a shareable PDF on device.

4. Schedule local reminders (draft unfinished, quote expiring, appointment coming up).

5. Optionally sync premium / ads later — never block the core path on auth.

Those constraints rule out “thin client + always-on API” as the primary path.

Stack choices (and why)

The important part is not the brand names — it is the local write path: every meaningful user action persists on device first.

Domain model that stays offline-friendly

Keep the quote as an aggregate you can serialize without joins to a remote user graph:

• Quote header: client, address, status (draft / sent / accepted / rejected), totals, validity date

• Line items: label, quantity, unit (hour / vehicle / job / stage), rate, amount

• Photos: local IDs + compressed data URLs (or filesystem URIs on native)

• Derived tools: vehicle size, paint-correction hours, interior multipliers, job time → become line items when the user taps “add to quote”

Statuses matter. A pipeline (“needs action”: unsent drafts, expiring sent quotes, this week’s appointments) is just local queries over timestamps — no CRM server required.

IndexedDB patterns that paid off

1. One database, versioned stores
   Quotes, appointments, and settings in one Dexie DB. Settings hold shop branding (name, logo, rates, PDF theme) so PDF generation stays a pure function of local state.

2. Live queries for lists
   History and dashboard screens subscribe to ordered collections. Users see updates immediately after save without inventing a sync event bus.

3. Draft session separate from committed quotes
   Autosave a draft snapshot while building. On cold start, offer resume/discard. This reduces “I lost the estimate when the OS killed the WebView” support pain.

4. Export quota as local counters (free tier)
   If you gate PDF exports, track unique quote IDs per calendar month in local storage/DB — still works offline; reconcile with entitlements when the store is reachable.

Photos without melting the WebView

Camera / gallery picks should be compressed before persistence. Practical rules we settled on:

• Cap count per quote

• Downscale + JPEG/WebP-style compression to data URL or native file

• Never block the UI thread on multi-megapixel originals

• Keep photos bound to the quote ID so PDF and history stay consistent

Capacitor’s camera plugin + a small compression helper is enough for field reference shots; this is not a Lightroom clone.

On-device PDF as a feature, not a microservice

Generating PDFs locally means:

• Lazy-load the PDF renderer so cold start stays light

• Themes (e.g. “canopy” band vs simple invoice) as style variants over the same data

• Share via Capacitor Share / Filesystem instead of uploading a blob to your API

• Premium variants can omit watermarks or hide internal shop rates on the customer-facing document

Failure mode to design for: renderer exceptions must surface a toast and leave the quote intact.

Reminders without a push backend

Local notifications cover a surprising amount of retention for solo operators:

• Unfinished draft after N hours

• Sent quote approaching validUntil

• Appointment N hours before start

• Quiet hours respected in scheduling logic

Rebuild the notification schedule when quotes/appointments change. Deep links back into /quote, /calendar, or /history/:id close the loop.

What we deliberately did not build first

• Multi-user shop permissions

• Cloud sync as a launch blocker

• Payment capture inside the estimate

• Marketplace lead gen

Those can arrive later. The first mile is: accurate number → professional PDF → booked time, with dead radios.

Takeaways

1. Model the quote as a complete offline aggregate.

2. Persist first; treat network as enhancement (entitlements, ads, calendar export URLs).

3. Use the OS for camera, share, and notifications instead of reinventing them in JS.

4. Keep PDF generation a pure transform of local state.

5. Pipeline UX (“needs action”) is mostly date math on local records.

If you are researching local-first contractor tooling, the public overview for the detailing-oriented build lives here: https://knoxstudios.net/apps/detailbid.html