Software Engineer — Supply & Fulfillment
Bengaluru (in-office) · Full-time · 3+ YOE
Our mission: bring AI to the physical world.
At Aviha, we believe AI in India can only reach its full potential when it is deeply integrated into the services economy, providing undeniable value to every consumer.
We stand at a singular, pivotal moment in human history, a threshold where the impossible is becoming inevitable. We refuse to let AI be a privilege of the few. It is a right for the many.
From the tailor's needle and the gardener's soil to the very soul of every household, AI should be deeply integrated. That integration doesn't happen in a browser tab. It happens when a real gardener, a real saathi and a real tailor can run their working day through systems we built. That's your half of the company.
The role
You own the supply side of Aviha. The products our vendors and saathis actually use and you own whether tasks get fulfilled. Not "you contribute to fulfillment." You own the number. If on-time rate drops in Indiranagar this week, that's yours to explain and yours to fix.
What you'll actually do
1. Build for the people who do the work. Vendors and saathis are not a secondary user group here. They are half the product. You will build both halves of what they touch: the screens they live in, and the AI that actually talks to them and walks them through the job. Getting a job, understanding it, accepting it, doing it, getting paid, being trusted again. For many of them the AI is the product, because a voice note in their own language will always beat a form they were never going to fill. Most of them are on a mid range Android phone with patchy data and no patience for your onboarding flow.
2. Own fulfillment as a number, not a feature. Time to first accept. On time rate. Completion rate. Redo rate. Cost per fulfilled task. Saathi utilisation. You will know these cold. You will know which one is holding us back this month, and you will be the person who moves it. When it moves the wrong way, you say so first.
3. Build an AI harness for each persona. The user, the saathi, the vendor and the ops desk each need a different agent, with different tools, different guardrails and different ways of failing. You will design those harnesses: the prompts, the tools, the context, the evals, the escalation paths. Then you will keep them honest as reality changes underneath them.
4. Ship agent workflows people actually depend on. Not demos. Agents that negotiate, schedule, chase, verify and hand off. Running live, against real vendors, with real money and real disappointment on the line when they get it wrong. You will design the points where a human steps in as carefully as you design the automation.
5. Build the systems we work with, not just the systems we sell. Aviha is AI native end to end: how we find a problem, how we decide what to build, how we measure it, how we iterate. Tha machinery is forever evolving. You will build some of it: the eval harnesses, the metric pipelines, the agents that read our own data and tell us what is breaking before a user does.
6. Go on the ground. Sit with a saathi and watch them use the thing you built. Ride along on a fulfillment. Sit with a tailor for a morning. You cannot design supply software for Bharat from a laptop in a room, and we will not pretend otherwise.
What we're looking for
Deep in one language, not shallow in five. You should know your main language's edges. How its concurrency actually works, where it gets slow, what its standard library already does so you do not rewrite it badly. We mostly write Python and TypeScript. If your depth is in Go, Java, Kotlin or Rust, that counts, and we will expect you to be productive in ours inside a month. Depth transfers. A list of frameworks does not.
System design judgment at our actual scale. We are one city, not Netflix. The right answer here is usually smaller than the one that would score well in a big company interview. A MongoDB collection and a cron job beats Kafka and a worker fleet, right up until it does not. We want the person who can say when it stops being true, with a number attached, and who builds the small thing until that number arrives.
You know what not to build. Shipping the ugly 80% version this week, out loud, on purpose, with the trade off named and a trigger written down for when we pay it back. That is a senior habit and we care about it more than years.
You use AI heavily, and you own what it writes. We expect most of your code to come out of an agent. We also expect you to have read every line of it and to be able to defend it without opening the file. If the model wrote something you cannot explain, that is yours, not the model's. Someone who ships three times faster with AI and still knows exactly what shipped is the profile.
You have put an LLM in production. Not a chatbot demo. Something that took real actions through tools, broke in a way you found, and got fixed in a way you can describe. We will ask what it got wrong and how you knew.
3+ years of experience. A sharp fresher who has shipped something real and can explain every decision in it is absolutely in scope. So is someone senior who is tired of shipping through four layers of approval.
The stack, so you know what you are walking into
Python, FastAPI, Pydantic v2, MongoDB. LangGraph for the agents, with Anthropic, OpenAI and Gemini behind them. Promptfoo and multi turn evals, so we test how the agent holds up across a whole conversation and not one reply. OpenTelemetry and Grafana for traces. Expo and React Native for the user and saathi apps, Next.js for the internal console. Pipecat and LiveKit for voice, Exotel for telephony. Docker everywhere.
You will not know all of that. Nobody here did on day one. We care how fast you pick something up, not what you already have on your CV.
9 mantras which define our culture
Execution over planning : We ship, learn, and iterate. A decent plan executed this week beats a perfect plan next month.
Problem first : We fall in love with problems, not solutions. Understand the problem deeply — who has it, why it matters, what causes it — before building anything.
User first : Every decision starts from the user — the households who trust us with their homes, and the partners who serve them. Trust is the product.
Long term thinking : We compound. We refuse short-term wins that cost long-term trust, optionality, or team health.
Experimentation over biases : Opinions are hypotheses. Data and experiments settle debates — not seniority, not who argues loudest.
Hire and grow exceptional talent : Every hire raises the bar. We grow people faster than the company grows.
Growth mindset : Feedback is fuel. Skills are built, not fixed. Curiosity beats ego.
How we do anything is how we do everything : Standards do not have small cases. The tone of a WhatsApp reply, the neatness of a vendor invoice and the polish of a release are the same decision, made again.
Crawl before you walk, before you run and before you fly : .We earn scale in stages. One street working, then one city, then the next. A stage skipped is a stage repeated, usually at a worse price.
The honest bit about this role
The conventional software engineering role is being rewritten in front of us. Writing and reviewing code is now the cheapest part of the job. The scarce part is knowing which thing to build, for whom, why it matters, and whether it worked.
So this is not a ticket-shaped job. You will spend real time away from the editor, with saathis, with vendors, in the data, in the ops desk's escalations and you will still be expected to ship more than an engineer who never leaves their chair, because you'll be using AI properly to do it.
If that sounds like a downgrade of the craft, this isn't the role. If it sounds like the craft finally getting interesting, keep reading.
You'll love it here if
You already build things nobody asked you to build, and you finish them.
You use AI like a limb, not a gimmick. You've built your own agents, harnesses, evals or tooling and you have opinions about why most of them don't survive contact with reality.
You get genuinely curious about a business metric, not just an error rate.
You'd rather sit in a workshop for an afternoon than read a requirements doc about one.
You're comfortable owning an outcome you don't fully control and chasing down the parts you don't.
Complex, ugly, physical-world problems energise you more than clean abstractions.
You'll hate it here if
You want a well-groomed backlog handed to you.
You think talking to users is somebody else's job.
"It works as specified" feels like a complete defence to you.
You measure your contribution in code merged rather than in numbers moved.
What you get
A competitive salary. 30-35LPA + ESOPs
Ownership. Supply and fulfillment, end to end, with the metrics to prove what you did.
Direct access to the founding team. Every day, no layers. Your decisions don't queue behind three reviews.
A genuinely AI-native environment. Not a company that bolted a copilot on. One where you're expected to build the systems that make everyone else faster.
Frontier problems with real stakes. Agents that move real money, coordinate real people, and fail in ways no benchmark covers.
The story of having been early to something that mattered, with the receipts to show it.
How to apply
Skip the cover letter. We won't read it.
Three things you'll need to apply
Something you built and shipped. A link, repo, product, tool, anything with users, even three of them. Plus three lines: what broke in production, and what you did about it.
An AI system you built for yourself. An agent, a harness, an eval suite, a workflow, however scrappy. Show us the actual prompts, tools and code, not a description of them. We care much more about your judgement here than your polish.
Three sentences on one number. Pick any fulfillment metric you'd expect us to be struggling with, say why, and name the first thing you'd ship to move it. Be specific. Be wrong if you have to. Be interesting.
We read the second one first. If it's good, we'll reply fast and the first conversation will be about a real problem in our fulfillment funnel, not a whiteboard puzzle.