Product & Architecture

Architecture summary

The PitchPad PWA runs on iOS and Android via the browser-installable Web App manifest — no app-store gates, no native build per platform. Voice capture happens on-device through the platform Speech-to-Text APIs with a fallback to OpenAI Whisper for low-noise conditions; the structured-scope inference runs on-device through a quantized Llama 3.2 1B model for utterances under 600 tokens, with a server fallback for longer or low-confidence utterances. The rate-card engine is a versioned JSON document per operator, served from the API and cached in the PWA for offline operation. The signature flow uses the platform Pointer Events API, and the deposit flow is a Stripe Checkout session created server-side and returned to the PWA as a redirect link. QuickBooks Online is the system-of-record for invoices and the calendar holds use ICS file delivery to the homeowner's email plus a Google Calendar / iCloud push to the operator. The whole front-end is offline-tolerant — a walk-through can be captured, priced, and signed without connectivity, then synced when the truck reaches a cellular signal.

We chose Astro over a Next.js or Remix stack because the site-content surface (the marketing pages, the founding-cohort application, and this investor brief) is static and benefits from Astro's island architecture; the PWA shell loads as a single React island when the operator installs it. We chose Postgres over a document store because the rate card, the proposal, and the homeowner record all have strong relational integrity requirements and the QuickBooks reconciliation flow demands transactional guarantees we did not want to hand-roll on a NoSQL store. The whole system runs on Render with Cloudflare in front for asset delivery and DDoS protection. △ Modeled Year-one operating burn for infrastructure is under $1,000 per month at the projected operator count.

Integrations

• Stripe — Checkout sessions for deposit collection; Connect later for crew-payout when we add the dispatcher tier. § Sourced
• QuickBooks Online — Invoice creation, customer record sync, deposit reconciliation. § Sourced
• Twilio — Outbound SMS for proposal links, deposit-receipt confirmations, and crew calendar notifications. △ Modeled
• SendGrid — Transactional email for homeowner proposal PDFs and calendar ICS delivery. △ Modeled
• Google Calendar + iCloud — Operator-side calendar push; ICS delivery to homeowner. § Sourced
• OpenAI Whisper (fallback) — Low-noise voice transcription when on-device confidence is below 0.78. △ Modeled
• Render + Cloudflare — Application hosting and asset delivery. § Sourced

Data model

Five canonical entities flow through the system. Operator is the owner-operator account, with billing tier, rate-card version pointer, and integration credentials (Stripe + QBO). RateCard is the versioned JSON document — categories, line-item templates, modifiers, hazard pricing, regional adjustments. WalkThrough is the captured voice + photo + structured-scope record, with timestamps and on-device confidence scores per utterance. Proposal is the priced output the homeowner sees: line items, totals, deposit amount, signature block, calendar hold. Homeowner is the customer record — address, contact, signed proposals, deposit history.

Each WalkThrough → Proposal transition is an event in an append-only log; this is how we will train the category-specific voice-to-line-item models as the corpus grows. Homeowner records are soft-linked across operators only if the operator explicitly opts in to the future cross-operator referral graph — by default each operator's homeowner records are isolated.

Security posture

Stripe handles all card data — PitchPad never touches a PAN. QuickBooks Online OAuth tokens are encrypted at rest with envelope encryption on the Render-managed Postgres instance. Voice recordings are encrypted in transit (TLS 1.3) and at rest (AES-256 on the audio object store), and are deletable on operator request — we treat the operator as the data controller and the homeowner as the data subject under the standard service-provider model. The on-device LLM runs in the browser's WebGPU sandbox; no inference data leaves the device unless the operator explicitly opts in to the server-fallback path for a specific utterance.

Scalability notes

Year-one ceiling is 5,000 paying operators at the current architecture before we need to shard the Postgres instance or move voice-fallback inference to a managed inference platform — both are well-understood next steps and neither is on the year-one critical path. The principal scaling risk is not application load (the per-operator request rate is low) but cold-start latency on the rate-card engine when a new operator opens the PWA after a day idle; we have a 12-hour pre-warm strategy in the queue. Trade-pub channel partnerships could spike sign-ups during a promotional window — the concierge onboarding pace (one operator-week per engineer-week) is the throttle, and we will hire the second engineer at the 50-operator mark.