Mumbai, India Engineering · Product · Emerging Tech

I turn messy problems into systems people can use.

I’m Kshitij, an engineer and builder interested in the point where technology meets an operating problem. I work across data, applied AI, automation and product, choosing the stack after the problem is understood, not before.

NOW

Building Aarambha, an AI-operated GTM intelligence product, while growing toward forward-deployed engineering: owning ambiguous problems end to end, close to the people who live with them.

Portrait of Kshitij Datar
Engineer · Builder · Founder Based in Mumbai

Selected work

Problems I’ve taken ownership of.

The technology matters, but it is not the identity. I care about understanding the bottleneck, designing the right operating model, and carrying one useful path all the way into the real workflow.

02 Founder & engineer · live GTM product

Aarambha: build the intelligence layer before outbound starts.

Aarambha grew from a practical GTM problem: teams can send at scale, but still spend too much human effort deciding who is worth contacting, researching why, and keeping message quality high. I’m building the product and taking that operating model into client conversations.

research→qualify→review→reach→learn
  • Turns account research, qualification, messaging context and campaign learning into a reusable operating layer.
  • Uses explicit fit and quality gates so weak prospects can be rejected before outreach is created.
  • Built as a client-facing product, where feedback from real GTM motions shapes what gets engineered next.

How I work

Start with the problem. Earn the architecture.

The role I’m building toward is forward-deployed engineering: working close to users, learning the constraints quickly, and taking responsibility for the system that gets a real outcome, not just one technical layer of it.

01

Understand the operating reality.

Before choosing a tool, understand who is doing the work, where context gets lost, what is repeated, what is risky, and what “better” would actually change for them.

02

Cross boundaries when the problem does.

A useful solution may need data modeling, an API, automation, an AI component, a small interface, or a process change. I’m more interested in the complete system than protecting a narrow technical lane.

03

Stay close until it works in practice.

Shipping is not the end of the loop. Observe how people use it, explain the trade-offs, keep the state visible, and use real feedback to decide what deserves to be built next.

Guest sessions & technical education

I like explaining how the pieces connect.

I speak with engineering students about emerging technology through the lens of real systems: what happens between the concept in a classroom and something that has to work for an actual user or business.

PAST SESSION

From learning AI to owning a real engineering slice.

I’ve spoken with students about Data Science, AI and Machine Learning careers, and about why problem framing, deployment, monitoring and ownership matter beyond the model itself.

See the alumni session note
POSSIBLE SESSION THEMES guest lecture · alumni session · workshop
01
AI / ML beyond the demoproblem framing · data · deployment · evaluation · monitoring
02
Building useful AI systemscontext · agents · human review · reliability · product decisions
03
Data, APIs & automation as one systemhow information moves from source to decision to action
04
Networking & modern infrastructureconnecting fundamentals to cloud, distributed systems and the AI era
05
Careers in emerging technologyprojects · learning depth · communication · ownership · industry context
FOR ENGINEERING COLLEGES

Looking for a practical guest session around AI, data, systems, product building or emerging technology?

Invite me to speak

A little more context

Builder first. Tools second.

My background gives me a strong data and systems foundation, but the broader pattern in my work is problem ownership: understand the workflow, find the constraint, build across layers, and make the result understandable to the people using it.

Building Aarambha has pushed that further into product, customers and GTM. Teaching and guest sessions push the same skill in another direction: if I understand a system well, I should be able to explain it clearly. As I progress through my master’s, I’m intentionally building toward roles where those instincts come together, especially forward-deployed engineering.

OPERATING RANGE tools change; the work does not
Discoverusers · workflow · bottleneck · success condition
Structuredata · state · rules · interfaces · system boundaries
Buildsoftware · automation · applied AI · integrations
Deployhandoffs · reliability · feedback · iteration
Productizecustomer learning · GTM context · reusable workflows
Explaindemos · documentation · guest sessions · classrooms
Open to good problems and good rooms

A system to build, a product problem to untangle, or a room of engineers to teach?

I’m interested in work that needs both building and explaining.