---
title: "About Arpit Khandelwal"
description: "Background, how sprints run, and which engagements are a good or bad fit."
canonical: https://www.arpitkhandelwal.com/about
---
# About Arpit Khandelwal

Arpit Khandelwal is a fractional AI and backend engineer based in Bengaluru, India, working with founders and small product teams on fixed-scope build sprints of two to six weeks.

## What this practice is

This is a one-person engineering practice, not an agency and not a staffing firm. Engagements are fixed-scope, fixed-window build sprints: a single senior engineer joins an existing team or an existing codebase, ships a named outcome, and hands the work back with documentation the team can act on.

The work concentrates on the parts of a product that are awkward to hire for and easy to get wrong: authentication, data models, integrations with third-party systems, AI agents that have to survive real users, browser automation against surfaces that were never meant to be automated, and the operational glue between all of it.

## Background

Previously an AI and backend engineer at Avici Money, building AI concierge infrastructure for ordering, booking, and task execution, and a software developer at Hewlett Packard Enterprise working on microservice integrations across security tooling including WebInspect, Burp Suite, OWASP ZAP, and OpenVAS.

Alongside client work there is a long public archive of shipped experiments: MCP servers, retrieval-backed chatbots, Solana programs and dApps, media pipelines, and automation bots. Those projects exist because the fastest way to know whether a technique survives production is to put it in production.

## How sprints run

A sprint starts with a scoping call, usually within 48 hours of first contact. Scope is written down and signed off before any code is written, and pricing is flat per sprint and tied to a shipped outcome rather than billed hourly.

During the sprint the cadence is weekly: merged pull requests, a working demo, and a short note covering what changed and which tradeoffs were taken. At the end, handoff documentation goes to the team so the work keeps moving without a dependency on the person who wrote it.

## Good and bad fits

A good fit looks like an AI, automation, retrieval, or backend problem with a real user-facing outcome attached, or a prototype that needs a credible production path. A bad fit looks like landing-page polish, a vague idea with no defined users or decisions, or discovery work that is mostly meetings.

Saying no to a bad fit quickly is part of the service. Every inbound brief gets a reply within 24 hours, including the ones that are not a fit.