Portfolio — 2026

Rohan Katara

— AI Engineer

Available for opportunities

manifesto / 002

I build software that feels alive — voice first AI, autonomous agents, and immersive web experiences that don't sit still waiting to be read.

Selected Work · 04 entries

Things I've shipped
on my own

Each project below started as a question I couldn't stop thinking about and ended as something a stranger could click. Open one to see how it was built.

MockTalk

Voice to voice interview prep with sub 200ms response latency

2026 Next.js 15 · OpenAI Realtime API

Krishna.AI

Ancient wisdom answered through modern LLM prompt engineering

2024 React · ChatGPT API

Automate Pro

n8n + Gemini pipeline that saves an agency 20+ hours per week

2026 n8n · Google Gemini 2.5 Flash

Content Engine

One long form input, twelve platform native variants out

2025 LLM API · Prompt Engineering

About / 003

The engineer behind the code.

Hey I'm Rohan Katara, a recent B.Tech Computer Engineering graduate based in Ahmedabad, India. I firmly believe the web was never meant to be a stack of static, boring documents. It should be a living, breathing, interactive experience.

When I'm not obsessively tweaking the grind size on my coffee beans to pull a god-tier extraction from my espresso, I'm applying that exact same perfectionism to my code.

My true passion lies in the intersection of engineering and creativity whether that means architecting immersive web environments, tinkering with the latest Generative AI models, or building tools that actually feel alive.

Stack — what I reach for

ReactNext.jsTypeScriptPythonOpenAI Realtime APIGoogle Geminin8nThree.jsAstroGSAPTailwindNode.jsWebSocketsLLMsPrompt EngineeringVercelReactNext.jsTypeScriptPythonOpenAI Realtime APIGoogle Geminin8nThree.jsAstroGSAPTailwindNode.jsWebSocketsLLMsPrompt EngineeringVercel

Contact / 004

Let's build something.

rohankatara3@gmail.com

click to copy

01 / 04

MockTalk — Real Time AI Interview Simulator

Voice to voice interview prep with sub-200ms response latency

2025 · Solo build · Engineering & design

<200 ms

Latency

Next.js 15

Stack

OpenAI Realtime API

Realtime

WebSockets

Transport

Overview

MockTalk is a low latency, voice to voice web app that simulates high-pressure behavioral interviews. The candidate speaks. A custom-prompted LLM, roleplaying as a strict hiring manager, talks back in real time pacing, interrupting, and following up exactly the way a human interviewer would.

The hard part isn’t the LLM. It’s the audio loop: getting a microphone stream from the browser, into a model, and back out as speech without breaking the conversational rhythm humans expect.

How it works

The browser captures audio with MediaRecorder and the Web Audio API, chunks it on the fly, base64 encodes each chunk, and pushes it through a secure bidirectional WebSocket to the OpenAI Realtime API. Responses stream back the same way and play through a small audio queue tuned to avoid both stutters and overlap. The serverless route is a thin pass through the heavy lifting happens in browser native APIs to keep round trips short.

The interviewer “personality” comes from a tightly engineered system prompt that anchors the model to a specific role (Relationship Manager hiring) and gives it permission to interrupt, redirect, and probe. Without that, models default to polite Q&A and the simulation falls flat.

What I learned

Conversational latency is a budget, not a number. Every layer capture, encode, transport, model, decode, playback eats from the same 200ms.
Prompting an LLM to feel human means giving it explicit permission to be impatient.
Claude Code CLI flattened a lot of the React hook boilerplate around audio streaming. I leaned on it for rapid hook prototyping and serverless route scaffolding.

Reflection

This is the project that convinced me real time voice is the next interaction surface for AI. The moment the latency dropped under 250ms, the conversation stopped feeling like a chatbot and started feeling like a phone call. That gap is everything.

Next case study Krishna.AI →

02 / 04

Krishna.AI Bhagavad Gita Guidance

Ancient wisdom answered through modern LLM prompt engineering

2024 · Solo build · Engineering & narrative design

Bhagavad Gita

Source

ChatGPT API

Model

Web

Surface

General readers

Audience

Overview

Krishna.AI is a web platform that gives personalized life guidance grounded in the Bhagavad Gita. Users describe what they’re wrestling with financial stress, an ethical bind, a difficult choice and the system answers in the voice of the scripture, mapped to their actual situation.

The goal was to make 700 verses of dense classical text feel as approachable as a conversation with someone who has already read them.

How it works

A carefully tuned prompt holds the model inside the worldview of the Gita: it can paraphrase, reference verses, and reason through dharmic frames, but it stays out of generic life coach territory. The interface strips down to a single input and a single response so nothing competes with the answer.

The hardest design decision was how literal to be. Too literal and it reads like a Wikipedia quote. Too loose and it’s just another chatbot wearing a costume. The sweet spot is paraphrase plus a single grounding verse short enough to actually read, specific enough to feel like the text is talking to you.

What I learned

Prompt engineering is mostly editing. The first version of the system prompt was a wall of rules. The version that shipped is half the size and twice as obedient.
Subject matter projects live or die on tone. People can smell a generic LLM answer from a mile away voice has to come first.
Accessible doesn’t mean dumbedd own. The interface is plain because the content is the experience.

Reflection

A lot of AI projects answer questions that are easy to ask and not particularly meaningful. This one tries to do the opposite. It’s small, but it’s the one I’m proudest of for the framing.

Next case study Automate Pro →

03 / 04

Automate Pro — AI Lead Gatekeeper

n8n + Gemini pipeline that saves an agency 20+ hours per week

2025 · Client build · Automation engineering

20+ hrs/week

Saved

Gemini 2.5 Flash

Engine

n8n

Pipeline

Slack + Sheets

Routing

Overview

Automate Pro is a lead gatekeeper for an agency drowning in inbound forms. Before it shipped, a human read every submission, scored it by gut feel, and either escalated it to sales or filed it away. The bottleneck was the human.

After: an n8n pipeline scores every lead the moment it lands, routes the top 20% straight into Slack with full context, and quietly drops the bottom 80% into a Sheets nurture queue. The same agency now spends those 20 hours on actual sales calls.

How it works

Form → React frontend → n8n webhook → Gemini scoring → Slack | Sheets

The React frontend captures lead data with a dynamic form and behavioral tracking, what fields they edited, how long they spent on each posts to an n8n webhook. n8n hands the payload to Google Gemini 2.5 Flash with a scoring prompt that weighs project scope, budget signals, and stated urgency, returning a 0–10 quality score plus a one line rationale.

A router node branches on the score. 8 and up: Slack message to the sales channel with the lead, the rationale, and a click-to-respond button. Below 8: appended to a tiered Google Sheet that feeds the nurture sequence later.

What I learned

The model isn’t the product. The pipeline is. The Gemini call is 10% of the work; the other 90% is wiring it cleanly into systems the team already trusts.
Behavioral signals from the form (dwell time, edits) turned out to be a better quality signal than the form answers. Users overstate budget and understate timeline. They don’t fake how long they spent.
Gemini 2.5 Flash is shockingly cost-effective for high-frequency classification work like this.

Reflection

This is the project I point at when someone asks “what does AI actually do for a small business.” Not magic. Just a tireless reader sitting between the inbox and the team.

Demo

A short walkthrough video lives in the project assets. open the link below to see the full pipeline running on a real submission.

Demo

Next case study Content Engine →

04 / 04

AI Content Multiplier & Syndication Engine

One long-form input, twelve platform-native variants out

2024 · Solo build · Engineering & prompt design

1 long-form

Input

12 variants

Output

Multi-platform

Channels

Brand-locked

Voice

Overview

Content Engine takes one long form piece : a blog post, a video transcript, a launch announcement and spits out platform specific variants for every social channel a marketing team cares about. Twitter threads, LinkedIn carousels, Instagram captions, newsletter blurbs, all in the brand’s voice.

The pitch to a marketer is simple: write once, ship twelve places. The pitch to me as an engineer was: how tight can the prompt loop get before brand voice starts drifting?

How it works

The system pipes the source content through a chain of platform specific prompts. Each prompt knows the format constraints of its channel (character limits, optimal structure, hashtag conventions) and the brand voice rules. The voice rules are extracted up front from a sample corpus the user provides, everything that follows compares against that corpus instead of “generic helpful AI.”

The output preview lets the user accept, edit, or regenerate per channel before anything ships. Nothing posts automatically, the model is the writer, not the publisher.

What I learned

Brand voice is the killer feature. Generic LLM output is everywhere; output that sounds like the user is rare and hard.
Format follows function. A LinkedIn carousel and a Twitter thread aren’t just length different. They’re argument shape different. The prompts have to know that, not just “be shorter.”
Manual review at the end is non negotiable. Marketers will not let an LLM publish for them, and they’re right not to.

Reflection

The interesting tension here was between automation (the promise) and control (the reality). The version of this product that fully autoposts is a worse product than the one that drafts and asks. I think every AI workflow tool eventually learns that lesson.

Next case study MockTalk →