When Rise came to IIT Palakkad to recruit engineers, Kshitij did what he always does with a job description: skipped straight to the stack.

"The first thing I look for in any JD is the skills required. Most companies list a stack you end up just working with, but Jurin was built on the T3 stack I would have chosen myself and had spent my college projects mastering. It felt as if the description was written specifically for me."

His family was cautious about the startup.

"They asked if this was a long-term commitment or a short-term risk. I told them I believed in the vision. They said if you believe in it, give it everything you've got."

He signed his contract the same day it arrived.

"Rise asked if I had even read it, and of course I had. But I had already made up my mind during the interview process. I recognized the caliber of the team and their way of thinking, and I knew immediately that I wanted to build alongside them."

The company he walked into had few engineers. Nobody had a narrow job.

"Everyone carried immense responsibility and every single person's contribution was vital."

Within days he was handed his first real task. A customer needed an AI that could answer phone calls, and needed it fast.

"It was five to ten days of intense, non-stop execution while balancing my final-year academics. We had a prototype literally running off a server on my laptop for the live demo. I kept the machine awake the entire time to sustain the phone call. It was unconventional, but it proved the concept and it worked."

He built it with his best friend, and together they took it from that laptop into production. That was how most of the early product got built.

Most of what Kshitij built in those first months is still running in Jurin today.

"We began with a single agent, and I engineered that into an architecture capable of running millions of agents. Early on, we also didn’t have call logs. We had no way of tracking active session duration, which meant every minute cost us money."

Then came the massive architectural migration from Jurin 1.0 to Jurin 2.0, a high-stakes transition with no blueprint. Kshitij stepped up to single-handedly lay the foundational codebase that made the shift possible.

"That shift was a massive undertaking, and I took the lead on making that first critical cut. The team refined it later, but someone had to break the ground and build that initial bridge to get us across."

There's something about the early days Kshitij wants the people who join later to understand. Not just how hard it was, but how it felt.

"It was wartime. Every deal was make-or-break. A customer wanted a feature by a deadline, and missing it was never an option. The consequences were immediate: if we didn't ship, a customer left. That reality kept us intensely focused."

But seriousness and fun weren't mutually exclusive.

"We lived in adjacent dorm rooms, building, testing, and shipping features in rapid cycles. Today, I might send a message for a code review, but back then, I simply walked next door with my laptop. It is why I still advocate for direct calls over long chat threads. A bug you can resolve in five minutes face-to-face will easily consume thirty minutes in text. I hope we preserve that culture of immediate, direct collaboration as we scale."

Through all of it, Kshitij says he never doubted the company. But there was one moment when belief turned into conviction.

"English voice models were already solid, but Japanese, the critical pain point we were targeting, was still unsolved. When we got it right, prospects evaluating our competitors told us our Japanese voice was the best they had ever heard. That became our first pillar. Once that foundation was laid, I knew Jurin was here to stay."

In college, Kshitij wrote code. At Jurin he learned that shipping what a customer asked for and solving their problem are not always the same thing. He was the point of contact for a customer whose long list of demands all traced back to one small problem.

"They requested a completely different feature to solve one underlying issue, which taught me two major lessons. First, always dig into the 'why' behind a customer request. Second, since real people rely on our code, it must be both robust and highly intuitive. We had no designers in the early days, so engineers designed the product, and engineers naturally design for other engineers. That was the moment I began obsessing over how to build interfaces that regular users could actually navigate."

The title is affectionate. The people who do well at Jurin are the ones who live the culture, and Kshitij is one of the people who makes sure that keeps happening.

His favorite way to explain how he works is GTD: getting things done.

"Say you need to take the trash out tomorrow morning. Most people set an alarm or schedule a reminder. The most effective approach is to place the trash bag directly in front of your door before you go to sleep. You will inevitably see it when you wake up. Whenever there is a task to execute, I write it down and clear it from my mind. Before any one-on-one, I have already mapped out my talking points so we can drive straight to decisions."

Meeting notes are mandatory on his team, per the Jurin handbook, and he's done the arithmetic on why.

"If you miss a single critical question in a design session, you wait two days for the answer and another two to build and ship the solution. You cannot afford a four-day delay when the alternative was documenting a single clear line."

He holds onboarding to the same standard.

"If a new engineer reads the handbook thoroughly, they should not need to constantly sync with their onboarding buddy. If they do, the documentation itself is what needs fixing."

It's the same instinct as the engineering work: the process is the part you control, and results are a byproduct.

"When you genuinely love the craft of writing code, you pour everything into it, obsessing over the invisible details that no one explicitly asks for but everyone ultimately feels. If your only goal is merely checking off a feature, it is easy to ship something mediocre. But at Jurin, our standards are too high for that; we do not let low-effort work pass review. Ultimately, you must build the very product you would be proud to use yourself."

That was Kshitij's first impression of Jurin AI.

"I asked Rise where the idea originated. He told me he built an email auto-responder, realized people were willing to pay for it, and began selling it. He makes it sound incredibly straightforward, but it was anything but simple. Once 2.0 was fully deployed, I told him I was amazed at his foresight from two years prior. He simply replied that the vision had been clear in his head from day one."

His impression of the company today is still "crazy", but in a different sense.

"We are engineering a platform that empowers high performers by delegating repetitive workflows to AI, freeing people to focus on deep, meaningful work. If you ask me what truly distinguishes Jurin from our competitors, it is Rise and his singular product vision."

The phone agent he ran off his laptop in a dorm room now takes real customer calls. Ask him why he's still here and the answer hasn't changed since his first month.