Integrations

What needs wiring before the pilot is real

The app shell is only useful if the deploy path is honest. These settings keep the infrastructure shape clear and prevent a half-working inbox from becoming the new mess.

Inbox UX

Chatwoot

Workflow brain

Inngest

State store

Postgres

Current status

Integration stack

Chatwoot

Needs dedicated host

Self-host the inbox layer on its own box so Rails/Postgres/Redis load never competes with RoofQuote or voice-agent.

Twilio

Ready to wire

Point one pilot SMS number into Chatwoot first. Keep all outbound AI SMS inside the same thread so clients see a single history.

Inngest

Scaffolded here

Use event-driven functions for message intake, AI draft generation, and escalation bookkeeping instead of brittle n8n chains.

Postgres

Schema drafted

Own tenant config, AI state, and business-level events here even though Chatwoot renders the inbox.

My call

Recommended next deploy move

Do not squeeze Chatwoot onto the current 2GB revenue server. It’s the wrong place to learn whether the inbox stack is memory-hungry.

The safer path is a small dedicated VM for Chatwoot plus its own Postgres/Redis, then keep this Next app either on that same new box or on a lighter app host.

Once the pilot number is connected, the order is: inbound SMS into Chatwoot → webhook to this app → Inngest event → AI draft or human takeover → write business state to Postgres.