Case Studies | AI Joe

Business problem: A contract manufacturer's salespeople could not answer the first question a prospect asks. Putting a price on a job meant routing it to estimators and waiting, so early conversations stalled on the one number that decides whether there is a conversation at all.
Architectural challenge: The tempting build is to ask a model for a price. But pricing is a decision with money attached, and a number nobody can explain is a number nobody can defend: the salesperson who says it out loud is committed to it. The company already held the answer in its own quoting history, so the real problem was not prediction. It was making that history usable, and choosing a method whose output could be shown to be reasonable rather than merely produced.
System created: A pricing model fitted on the manufacturer's own historical records using linear regression, so every estimate traces back to how the company has actually priced work and the factors driving a number can be named. It returns an indicative price immediately, deliberately positioned for preliminary discussion rather than as a binding quote, which leaves formal estimating where it belongs and keeps the system's authority matched to what it can support.
Result: Salespeople can put a defensible number in front of a prospect during the first conversation instead of after it.
Technologies: Python, linear regression, NetSuite, SuiteQL

Business problem: Structured intake forms get abandoned. The people with the answers are often on a call or a shop floor, and a form with thirty fields asks them to know, up front, which thirty things matter. The information existed; the interface for capturing it did not fit how people actually work.
Architectural challenge: A conversational interface is easy to build and hard to make useful, because the output has to be a record, not a transcript. The business system on the other end accepts only exact values: a picklist option renamed upstream causes a silent per-field rejection, so a confidently wrong answer is worse than a missing one. The conversation therefore has to be constrained by the schema it is filling, and has to distinguish between what it was told, what it inferred, and what it still does not know.
System created: A voice and text assistant that fills the gaps a document could not, driven by a stage definition per deployment rather than a single hard-coded script. Answers are written back as typed fields with their evidence attached, values are validated against the live option lists before they are sent, and anything still unresolved stays visibly unresolved rather than being guessed.
Result: Intake now starts from a conversation and produces records the downstream system accepts, with unanswered fields marked rather than filled.
Technologies: Pipecat, Google Gemini Multimodal Live, WebSockets, Python, FastAPI, Google Cloud Run, NetSuite

Business problem: Publishing a daily show is not one task but a chain of them: topic, script, audio, video, podcast host, video platform, newsletter, short-form clip. Each step depends on the last, each runs on a different service, and missing a day is visible to the audience.
Architectural challenge: The publishing steps are not idempotent. Podcast and video platforms mint a new identifier on every upload rather than updating in place, so a naive retry does not fix a bad episode, it publishes a second one. That rules out the usual answer of making every step safely repeatable. The pipeline instead has to be resumable at the step boundary, and has to put a human decision between production and anything irreversible.
System created: A config-driven orchestrator that runs an episode end to end, recording the status and outputs of each step so a rerun resumes rather than restarts. Production happens a day ahead and pauses at an approval gate; a person reviews the audio and the copy in a dashboard, and only after approval do the scheduled publishing steps run. Per-show behaviour lives in configuration, not in forked code.
Result: Three shows publish daily on a fixed schedule, with a human approving each episode before anything reaches an audience.
Technologies: Python, ElevenLabs, Google Gemini, FFmpeg, HeyGen, Buzzsprout, YouTube Data API, Windows Task Scheduler

Production work, explained clearly.