How I'd build HVAC AI
I'd reach for Next.js for the frontend because HVAC shop owners need real-time dispatch visibility, Postgres for relational data modeling (customers, jobs, techs, quotes, maintenance schedules), Stripe for billing, and Twilio for SMS dispatch alerts. The backend would be Node.js with Express to keep the stack unified. Rough estimate is 320-350 hours to production, assuming you're comfortable launching with some rough edges on the quoting engine. I'd want another 30-40 hours post-launch for the first round of customer-discovered bugs.
Day-by-day plan
- Day 1: Provision Clerk for multi-tenant auth and RBAC (role-based access control). Build the foundational tenant model in Postgres. Wire permissions so shop managers see only their data.
- Days 2-3: Stripe integration across the three tiers. Set up webhook handlers for subscription events (new subscription, canceled, payment failed). Test the downgrade flow carefully - don't want customers losing data when their card declines.
- Days 4-5: Customer onboarding flow. Guided setup for uploading technician rosters, base labor rates by role, and service categories. Store this in Postgres tables so it becomes the seed data for quoting.
- Days 6-7: Dispatch board. Real-time job assignment, drag-and-drop tech-to-job mapping using WebSockets, and a conflict detection system that flags when a tech is assigned to overlapping jobs. This is where the complexity lives.
- Days 8-9: Quoting engine. Build the logic to calculate labor (base rate times regional multiplier, times estimated hours) plus parts. Initially, parts will be a flat estimate or customer-entered - we don't integrate a real catalog at launch. This will be a customer-churn risk, so we document the limitation clearly.
- Days 10-11: Maintenance reminder scheduling and Cadence job queue setup. Weekly cron checks technician service history and sends SMS reminders to customers when it's time for routine maintenance.
- Day 12: Twilio integration to route SMS dispatch alerts to assigned technicians. Hook it into the dispatch board so when you assign a job, the tech gets an SMS with the address and job code.
- Days 13-14: Build an analytics dashboard showing jobs completed, average quote-to-close ratio, and revenue by customer. This is where shop owners see if they're actually getting faster with the tool.
- Day 15: Staging environment on AWS, monitoring setup via Datadog, error tracking with Sentry, documentation in Linear, and runbook for common incidents. Prepare for handoff.
What's hard about this build
The core complexity is accurate quoting without a real parts catalog. HVAC work requires knowledge of local parts availability and pricing - a Carrier air handler in rural Montana costs differently than in Denver. Without integrating Grainger or Home Depot APIs (both have approval processes and rate limits), the quoting engine will be a collection of estimates and customer overrides, which creates immediate churn when real invoices don't match quotes. The dispatch board also requires robust conflict detection; a tech can't be in two places at once, and we need to flag double-bookings instantly. Lastly, multi-day jobs complicate the data model - if a furnace install spans three days, the scheduler needs to reserve the same technician across the full span, which adds state-machine complexity most SaaS tools still get wrong.
What's fast because of AI
Claude accelerates the scaffolding phase significantly - generating a Next.js layout with Postgres migrations, Stripe webhook handlers, and Twilio routing takes hours to do from scratch, but Claude produces 80-90% of the code in minutes, leaving me to fill in business logic. For the quoting engine, enumerating edge cases (flat-rate pricing, travel-time padding, seasonal markup, tech experience multipliers) is where Claude excels - I describe the rules in prose, Claude writes the state machine, and I validate against known quotes from the customer. Testing is another major accelerator; Claude writes comprehensive test suites for the dispatch conflict detector and billing subscription state, catching edge cases I'd otherwise miss in a rush. UI copy - onboarding screens, error messages, in-app hints for skeptical shop owners - Claude drafts these at a quality I'd struggle to match writing alone.
How I'd hand it off
I'd record a Loom walkthrough of the full onboarding, dispatch flow, quoting engine, and billing dashboard. Create a runbook in Linear documenting the architecture, Postgres schema, deployment steps, and incident response (what to do if Stripe webhooks fail, Twilio is down, etc). I'd rotate on-call for the first 30 days to catch critical bugs - database failures, billing reconciliation issues, Twilio outages. I'll transfer AWS IAM credentials, the Postgres connection string, all API keys (Stripe, Twilio, Clerk), and GitHub access so you can merge fixes immediately after I hand off. You'll be independent by day 31.