Machine learning development in Mumbai
Collections and risk teams at Mumbai NBFCs make thousands of small decisions a day about which accounts to call, which to leave, and which early signs of trouble matter. Often the decision rules live in a spreadsheet maintained by one analyst, or a model was built once, scored a historical file well, and was never put into the daily workflow. The team goes back to instinct because instinct is at least available every morning.
We build models that run in the workflow: scored nightly on fresh data, surfaced where the team already works, and monitored so that drift shows up as an alert rather than a bad quarter. For lending decisions we favour models the credit and risk teams can interrogate over ones that score slightly better and explain nothing. And if a clear set of rules does the job, we will say so and build that instead.
Mumbai is India's financial capital. Both major stock exchanges are here, and so are many of the country's banks, NBFCs, brokers, wealth managers, insurers and fintechs. For these companies software is judged first on whether the money is right. A loan ledger that drifts from the bank statement, a payout released twice because a partner timed out, a portfolio screen showing yesterday's price: each one lands on an operations desk the next morning. What they need built is rarely a new product from nothing. It is a lending or payments backend that reconciles, a platform where each role sees exactly what it should, and approvals that need two people before money moves. Engineers who have built those systems are in demand across the city, so the work often waits for a hire.
The city's second industry is attention. The Hindi film industry, most of the country's television networks and many of its large publishers are based here, and their software problems are specific: traffic that arrives all at once on a release or a match day, rights and metadata that decide what can be shown where, and archives that are valuable only if someone can search them. A slow page on a publisher's site is lost revenue, because the readers came from search and will go straight back to it.
The third is consumer business in every size. Mumbai has D2C brands selling beauty, fashion and food through their own stores and every marketplace at once, and it is home to large family-owned groups and conglomerates whose older divisions still run on spreadsheets and exports from their accounting software. In the bigger groups the buyer is usually a digital team with a mandate, a budget and a procurement process, and the work has to survive that process as well as production.
We are in Bengaluru and share your time zone, so the working day is the same on both sides and a question asked in the morning is answered the same morning. You talk directly to the engineer who writes the code. The work happens in your repository and a shared chat channel, where every decision is written down, and the runbooks and architecture notes are written as we go rather than at the end.
We are the right fit when a Mumbai team has a defined piece of work and wants a senior engineer on it within days: a ledger that has to reconcile, a migration with an end date, or extra capacity while you hire. Start with a fixed-price two-week piece, or bring us in white-label for your agency's clients under your name.
Four ways this arrives.
Someone got good results on a laptop and nobody can reproduce them. We turn it into a training pipeline with pinned data and versioned artefacts, put a serving endpoint in front of it, and record what it was evaluated on so the next version can be compared.
Hundreds of conditions routing tickets or flagging risky orders, each added after an incident. We measure what the rules get wrong on your labelled history, then test whether a classifier beats them. Sometimes the answer is fewer, better rules, and we say so.
Demand, load or staffing estimates that miss often enough to be ignored. We start with a plain seasonal baseline, backtest against the periods you actually plan around, and add complexity only where it beats that baseline on those periods.
Duplicate records, recurring faults, near-identical products under different names. Embeddings group text by meaning where keyword matching cannot, and we build the screen that lets a person correct a group rather than trust it blindly.
Repeat-fault detection that began as UMAP and HDBSCAN over 33,000 work orders and shipped as nightly incremental clustering on the same embedding model.
Read the write-up →Asked by Mumbai teams.
How do you work with teams in Mumbai?+
We are in Bengaluru and share your time zone, so calls, reviews and releases fit inside your normal working day. We work in your tools, Slack, GitHub and Linear or whatever your team already uses, and every decision is written down in the repository or the channel. You talk directly to the engineer writing the code, from the first 30-minute call through to handover, with runbooks and architecture notes written as we go.
Do you build for Mumbai lenders, brokers and fintechs?+
Yes. We build the parts where the money has to be right: loan and payment ledgers that reconcile against the bank's records every day, retries that cannot turn a timeout into a double payout, maker-checker approvals where a second person signs off before money moves, and a full history of every change of state. We work inside the system you already run, in Node, Python and Next.js, and ship in increments.
How does your rate compare to hiring in Mumbai?+
PayScale puts a mid-career software engineer in Mumbai at about ₹15 lakh a year. Our published rate is $35 an hour, with a $5,000 minimum. That buys a senior engineer who writes the code, works in your Slack, GitHub and Linear, and starts within days, with no recruiting round, notice period or employment overhead. Start with a fixed-price two-week piece at $2,800 and judge us on the output before committing to more.
Can you work white-label for our Mumbai agency?+
Yes. Mumbai's digital and media agencies bring us in when a client needs a backend, a mobile app or a data pipeline alongside the design and campaign work. We work under your name, in your client's repositories and your channels, and sign an NDA before specifics. The code belongs to the client from the first commit. You keep the relationship, we write the code and the runbooks, and your team presents the work.
Do we need machine learning, or is a rules engine enough?+
Often a rules engine is enough, and it is cheaper to run, explain and audit. If the people who make the decision today can write it down, write it down. A model earns its place when the rules keep multiplying, the inputs are messy text or images, or the pattern shifts faster than anyone can edit the rules. We check against your history before recommending either.
Why not just call a hosted model API?+
Sometimes you should. With low volume, messy language and no labelled data, a hosted model and a good prompt ship quickly. A trained model wins when per-call pricing starts to hurt at your volume, when latency matters, when data cannot leave your systems, or when you have labelled examples a small model can learn from. We price both paths before you commit.
How much data do we need?+
For classification, usually fewer labelled examples than people fear, and embeddings can group text with no labels at all. Forecasting is the opposite: you need enough history to cover the cycles you plan around, and a single year says little about a yearly pattern. We give you an answer after looking at your data, not before.
What happens when the model gets worse?+
It will, because the world it learned from changes. We log inputs and predictions, compare them with outcomes as they arrive, and alert when accuracy or the input mix drifts past a threshold you agreed. Retraining is a scripted pipeline with an evaluation gate, so a new model replaces the old one only when it does better on the same test set.
Can you build a recommendation system?+
Yes, and we would start without a learned model. Co-occurrence and embedding similarity, served from Postgres or a vector index, beat a most-popular list for most catalogues and are easy to debug. A learned ranker comes after that, once you have enough interaction data to train and evaluate one. A learned ranker is something we build from our work with embeddings and clustering, starting from a simple baseline you can measure it against.