Voice AI
24/7 voice AI for inbound customer care
A production voice assistant that answers inbound calls, books appointments, resolves FAQs and updates the CRM — handing off to a human when the conversation needs one.
Case studies
Real builds, taken apart.
AI, voice and automation builds — each one runs the same way: what the client was actually stuck on, the architecture we chose, the calls we would still defend, and what shipped. Written by the engineers who built them.
- 10 case studies
- 7 categories
- Architecture, decisions, outcomes
The work
Every study, up close.
Twelve builds across voice, conversational AI, automation, trading infrastructure and app rescue. Open any one for the architecture, the decisions and what shipped.
FinTech
TraderOps: a multi-broker trading OS
Compose, backtest and run a strategy on one engine, across eight Indian brokers, with paisa-exact parity between the backtest and the live fill.
Conversational AI
Text and voice support in one secure session
A multimodal assistant for a fintech client that keeps text and voice inside a single session, and challenges a session that starts behaving like a script rather than putting a CAPTCHA in front of everyone.
Voice AI
Real estate voice AI that calls the lead first
An outbound pipeline that phones a lead seconds after the form is submitted, qualifies intent in natural dialogue and books the property tour.
Automation
Content autopilot, end to end
An agentic system that turns long-form writing into platform-shaped assets — short video, social posts, editorial — and publishes them on schedule.
NLP
Multilingual sentiment with a sense of culture
A sentiment engine that reads intent, politeness and escalation risk across 25+ languages, where standard tools misread polite frustration as satisfaction.
Voice AI
A dental concierge that answers at 2am
A voice assistant running the whole appointment lifecycle — answering the call, taking patient details, checking the calendar, confirming the slot.
Travel
Chat to booking, without an agent in the loop
A Telegram and WhatsApp concierge that suggests itineraries with live pricing across 50+ countries, qualifies the traveller and carries them to a booking.
SaaS
High-intent lead discovery on Reddit
A multi-tenant platform watching 1,000+ subreddits hourly, using a dual-layer scrape with shared caching so the cost does not scale with the tenant count.
SaaS
OutreachKits: find, qualify and reach out
Prospects scraped from Google Maps and YouTube, their sites audited into a pitch, and their numbers dialled by an AI agent — all from one dashboard.
App Rescue
The Lovable SaaS that broke on real users
A Shopify CRM that worked for its founder and fell over on paying users — rate limiting, caching and payments fixed in 24 hours.
App Rescue
Rescuing the Bolt app a business ran on
A whole operation running on one fragile Bolt-built app — stabilised fast, then rebuilt so a fix could stop breaking everything else.
About these write-ups
How to read a case study here.
What each one contains, where the figures come from, and what to do with them.
One engagement, worked through end to end: the problem as the client described it, the constraints that ruled options out, the architecture we chose and why, and what changed once it was live. The parts that were hard are the parts written about at length — a write-up where everything went smoothly is a brochure, not a case study.
Projects is the portfolio — what was built and on what stack, across everything. A case study takes one of those and goes down into it. If you are assessing range, read Projects. If you are assessing judgement, read one of these.
They are what was measured on the engagement, and each one appears on the case-study page it belongs to rather than only in a summary. Where a number is a client system’s rather than ours to publish, it is described instead of quoted. If a figure matters to your decision, ask on the call and we will tell you how it was measured.
It depends on the constraints, and the constraints are usually latency, cost per call and what has to be auditable. Typically: a hosted or open-weight model for the reasoning layer, a purpose-built orchestration loop rather than a framework where the control flow matters, Postgres and Redis for state, and whatever the integration surface demands — telephony, CRM, calendars. Each case study names what it actually ran on.
Email contact@thworks.org naming it, and say where your situation differs — the differences are the interesting part and they are what the scoping call will spend its time on. A build that rhymes with one we have done is the strongest signal either of us has.