Build Our Ai Voice Agent - and related DB

I have a system that ingests public data, scores it, and feeds a voice-AI phone conversation that qualifies people and hands off to a human. It runs end to end and has extensive tests. Being straight with you: it was vibe-coded. Built fast with heavy AI assistance, optimising for "does it work" rather than "is this right," and never through a real engineer's hands. Some of it is solid. Some is probably wrong in ways I can't see. I need an owner, not a maintainer. Total freedom — redesign what's badly designed, throw away what should go. Tell me why, then do it. What I need back is that you own the outcome, not tickets. Required Voice AI / conversational agent experience. Non-negotiable. We're on GoHighLevel Voice AI today, so GHL experience is a real advantage — but I care more that you've shipped a voice agent and tuned it against real calls. Retell, Vapi, Bland, LiveKit, GHL, whatever. Strong on voice and average on backend beats the reverse. Fluent English. You'll be tuning conversations with American callers and reading transcripts to work out why calls die. Near-native, written and spoken. TypeScript / Node / PostgreSQL. Stack TypeScript (strict), Node 22, ESM, PostgreSQL, Vitest, Fastify, YAML config with Zod. CLI-first — almost everything runs through commands. GoHighLevel is both the CRM and, right now, the voice platform. That second part may change. There's a live decision pending on whether the call moves to a dedicated voice platform on our own SIP number, with GHL kept as CRM only. It's researched and costed but not settled — running that A/B and owning the migration if it goes ahead is likely one of the first real pieces of work. So: GHL knowledge is genuinely useful now, and GHL knowledge alone won't be enough for long. What you'd do Own the voice agent — prompt, conversation design, transcript review, working out why real calls fail. Judge what's sound and what isn't. Run the scheduled data ingestion. Wire vendors into existing seams. Keep the compliance gates honest (US telemarketing rules apply — improve them, don't remove them). The thing that matters The failures here are silent. A query that caps at 1,000 rows and reports it as the whole dataset. A field renamed upstream so a column fills with nulls and a whole segment looks empty rather than broken. Neither throws an error. Both already happened. Given how this was built, assume there are more — finding them is the part I'd value most in month one. If that sounds like an interesting problem rather than a tedious one, we'll get on well.