Problem-to-Architecture Analysis in Production AI & Infrastructure
Home | Experience | Projects | Publications | Skills | Contact
Most of my project write-ups describe what got built. This page describes how I got there — the problem as it was first handed to me, what I found once I dug in, why the obvious first approach usually didn't hold, and the architecture that did. Written for anyone evaluating problem-solving process rather than just output.
Problem: A client needed AI-powered access to their own internal documents and knowledge base, but would not send that data to any external service — regardless of encryption or access-control guarantees offered. That rules out essentially every standard RAG architecture, all of which assume documents get uploaded somewhere the model can reach.
Problem: Many businesses want the same fundamental thing: a support agent that knows their content and can talk to their customers. Building dedicated infrastructure per business doesn't scale. Naive shared infrastructure risks one tenant's data or conversational context surfacing in another's session.
Client: a Dubai-based luxury ground transportation company (engagement held by TechieMaya).
Problem: The company ran their entire B2B partner booking flow through WhatsApp groups. A partner posted a request; a human had to notice it, manually check vehicle and driver availability, calculate a fare, and reply. Typical turnaround was around 30 minutes with staff on hand — and well over two hours for requests arriving outside working hours. WhatsApp's official Business API offers no support for reading or acting on group messages, so there was no vendor-sanctioned automation path at all.
Client: an independent musician (engagement held by TechieMaya).
Problem: Active across dozens of community groups, receiving 1,000+ messages a day. Buried in that volume were the few that actually mattered — a booking request, a performance inquiry, someone asking about sessions — with no way to surface them short of reading everything. Separately, every time he had something to announce (a show, a release, a class), he had to manually repost it across a long list of individual contacts and groups.
Client: MGS Technology Pvt Ltd, via Quantashift Consultancy Services. Sole engineer on the engagement.
Problem: MGS's internal team had been blocked for months and could not get LiveKit's real-time video and infrastructure working — holding up a product meant to conduct interviews through a live photorealistic avatar rather than a plain audio bot. What existed was audio-only.
Problem: Different clients on the same voice platform needed fundamentally different conversational behavior. A higher-education consultancy wanted natural, unhurried outreach and follow-up calls — explicitly not salesy — to take pressure off their human counselors. A real estate client needed close to the opposite: a persistent, harder-to-brush-off cold-calling agent, because real estate cold calls are otherwise trivially easy to end in five seconds.
Problem: Maintaining a consistent brand presence on social media effectively requires a dedicated social media manager — daily posting, on-brand creative, and staying current with what's actually working. Most small and mid-size businesses don't have one, and two failure modes follow directly. First: businesses often don't know what to post. Second: even when there's a clear idea, execution is slow. A common real pattern — a CEO sees a post they like and wants the same concept with their own name, their own pricing, their own logo and colors — still requires a designer, a round of revisions, and days of turnaround for what is conceptually a small change.