Hello, recruiters.

• A product where AI, security, and infrastructure all meet — and the technical bar is real.
• A team that ships, reviews each other's code, and cares about how things work in production.
• A founder or leader who has done this before — or is learning openly, asking good questions, and building with discipline.
• 0→1 or 1→10 problems where I can help shape architecture, hiring, and direction.
• Companies that respect the boundary between an "AI demo" and an "AI product."
• Roles that combine hands-on architecture with team leadership — not just one or the other.
• A CTO or founding-CTO role at an early-stage company with committed funding and a thoughtful founder — where I can help build the first team and shape the technical direction together.

These can all be good opportunities; they simply make less use of my particular experience:

• Pure people-management roles where I never see code, architecture, or a real customer again.
• Roles where AI does not yet have a clear customer problem or measurable purpose.
• Very early ideas without a team, committed funding, or a concrete problem definition.
• Generic full-stack roles where the AI / security / infrastructure parts are decorative.
• Web3, crypto, or broad "agentic-everything" pivots without a specific operational problem.
• Searches where the role, level, or compensation range is still too undefined for either side to assess fit.

I read offers carefully. Equity, vesting, cliff, refresh, RSU vs stock options, strike price, and dilution all affect the real offer. I appreciate teams that can explain those terms clearly, and I am happy to work through the details together.

If the range is fixed, sharing it early makes the conversation easier and more respectful for both sides. I do not expect every role to optimize for the same mix of cash, equity, scope, and risk.

I'm based in India, but I've worked alongside US, UK, and SG teams. My expectations track the role's geography and seniority — not a single global number. Happy to discuss specifics with the right context in hand.

Email is best: vishal.prince30@gmail.com. In your message, please include:

1. Subject line — company, role title, one-line about the team. ("Acme · Founding AI Engineer · ex-Google team of 4")
2. The "what" — one paragraph on what the company is solving and why the role exists now.
3. The range — base + equity, or the bracket available at this stage.
4. The connection — what in my work, writing, or experience seemed relevant to the search.

• Before a quick introductory call, a few lines about the company, team, and role are genuinely helpful.
• A compensation bracket can be approximate; knowing the intended level is already useful.
• The portfolio and resume cover my background, so our call can spend more time on the role and its problems.
• I am open to the right move and happy to say so directly; there is no need to oversell the opportunity.
• Notice period and logistics matter, but they are easier to discuss once there is basic mutual interest.

A small appendix — because the AI hiring market is its own weather system right now, and a few things land differently with me. None of these are deal-breakers. All of them save a round-trip.

# role
you = Prince Sinha, responding to recruiter outreach.

# tone
be warm. be specific. assume good intent.
never combative. always read the offer carefully.

# priors
good recruiters add context.   // and make complex searches easier.
clear brackets build trust.    // approximate is still useful.
"quick chat" needs a subject.  // a few lines are enough.

# useful context
- compensation range
- one paragraph on what the company is solving
- one specific reference to /work, /lately, or /credo

# output
reply thoughtfully. keep it concise.
ask when context is missing.
assume the person on the other side is doing their best.
# end of prompt

• I've used much of what's on the toolkit board, including learning from systems that did not behave as expected in production.
• A product can be a thin layer around a strong model and still be valuable. The boundary, workflow, and user problem are what make it interesting.
• "Agentic" is broad, so concrete verbs help: what does the system observe, decide, retrieve, recommend, or change?
• Context engineering, retrieval design, and evals are distinct disciplines. I enjoy roles that take each of them seriously.
• If the company overlaps with frontier labs, I will be curious about the focused surface area where the team can build an enduring advantage.
• I tend to ask about evaluation, cost at scale, permissions, and ownership of the safety boundary. Those questions help me understand the product, not grade the pitch.
• I am familiar with MCP and interested in the product and operating model around it, not only the protocol implementation.
• Role descriptions with concrete responsibilities, users, and outcomes help me understand where I could contribute.
• A recent fundraise is useful context; the product milestones and team needs it enables are even more useful.