Custom Field-Service Software for Pool Co.

Pool company needs custom field-service software — replacing a patchwork of Pool Brain, Skimmer, and House Call Pro — built around their own operating standards. The full project is scoped as a four-phase roadmap (Core Operations → Customer Portal → Field Intelligence → Offline/Advanced). This engagement is for Phase 1: Core Operations — price book, estimates, payment policy enforcement, invoicing approval, batch payments, QuickBooks sync, and job scheduling.
A working scaffold already exists (tech stack chosen, data model built, core business logic implemented and typechecked). This is not a greenfield build — it's finishing, hardening, and shipping what's already started.
Current State
Stack already decided:
• Field/office app: React + TypeScript, built as a Progressive Web App (one codebase, installable, offline-capable)
• Backend: Node.js + TypeScript, Express, Prisma ORM, PostgreSQL
• Shared Zod schemas between client and server
Already built and typechecked:
• Price book with good/better/best tiers, field-editable with a full edit log
• Live-priced estimates (draft pricing tracks the catalog; freezes on customer acceptance)
• Payment-required-before-booking enforcement, with warranty-exempt and override-with-note paths
• Invoicing approval workflow (preview screen, admin can opt out of individual steps before approving)
• Nightly batch payment run (cron job)
• Jobs list with status/tech filtering, job creation, and a scheduler with tech-conflict detection
• Offline write-queue foundation (IndexedDB) so Phase 4's offline requirements don't require a rebuild
Deliberately stubbed — real interfaces built, but need live credentials:
• Twilio (customer/tech SMS)
• QuickBooks Online sync (OAuth not yet connected)
• Stripe or other payment processor (card charging in the batch run)
• Auth (currently a minimal JWT scaffold, not a real provider)
Scope of This Engagement
Take the Phase 1 scaffold from a working prototype to something the office can actually run the business on:
1. Wire in real integrations — Twilio (SMS), Stripe or another processor (card charging), QuickBooks Online OAuth + invoice/customer sync. Built and tested against free sandbox/test accounts (Stripe test mode, a Twilio trial number, a QuickBooks Online sandbox company) rather than a real client's production accounts — there's no signed customer yet, and none of this integration work requires one.
2. Replace the auth scaffold with a real provider (e.g. Auth0, Clerk, or a custom email/password + session flow), with role-based access for Tech / Office Admin / Manager. Unlike the integrations above, this doesn't depend on having a signed client at all — it's needed no matter who eventually uses the app, so there's no reason to defer it.
3. Build the remaining Phase 1 UI: customer detail page, a proper day/week calendar view for scheduling (current scheduler is single-job/single-day), a manual "run batch payments now" admin control
4. Harden what's already built: input validation, error handling, test coverage on the business-logic-heavy services (payment policy enforcement, invoice approval, scheduling conflicts)
5. Deploy: set up a production/staging environment (database hosting, app hosting, environment secrets) and a basic CI pipeline
Out of scope for this engagement (later phases): the customer-facing portal, chemical-dosing rules engine, tech scorecards, and offline-first hardening beyond the foundation already in place.