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.