Machine learning development in Bengaluru
Bengaluru has no shortage of people who can train a model in a notebook. What startups here are short of is the step after: the churn model a data scientist built before leaving, still run by hand once a month; the demand forecast that operations overrides every week because nobody trusts it; the thousands of free-text tickets or delivery notes written a hundred different ways that nobody has time to read.
We take models out of notebooks and into the product, with the data pipeline, retraining schedule and monitoring that keep them honest after launch. We are equally willing to tell you a set of rules would do the job, because a rules engine you can read is often the better answer. On FM360 we clustered repeat faults across tens of thousands of maintenance work orders, and the same approach works for support tickets, returns reasons or field reports.
Bengaluru is where we live and work, so this page is less a pitch than a description of the market we see every week. The defining fact about it is that startups and global capability centres, the in-house engineering offices of foreign companies, are competing for the same engineers. A GCC can offer a larger salary, a guaranteed bonus and a stable employer. A Series A startup offers equity and a harder job. The engineer you want usually has more than one offer, a notice period to serve, and a counter-offer waiting. So the roadmap slips while the hiring plan catches up.
The companies that call us here come in a few recognisable shapes. Startups whose first backend was written by an engineer who has since left, often for one of those GCCs. SaaS companies built in Bengaluru and sold to customers in the US and Europe from the first year, now closing their first enterprise account and the feature list that comes with it. Deep tech teams in space, robotics, semiconductors and applied AI, where the core work is research or hardware and the software around it, the dashboards, device APIs and data pipelines, is nobody's job. And GCC leaders who need a working proof of concept before headquarters will approve the headcount to build the real thing.
What they need built is usually a defined piece rather than a whole product. A backend mapped, documented and made safe to change. Single sign-on, custom roles and tenant isolation for the enterprise deal. A device API and a dashboard for a robotics team whose engineers would rather be working on the robot. A proof of concept a GCC can demo to its parent company. We build those in your repository, in increments that ship, and write the architecture notes and runbooks as we go, so whoever you hire next can read them in their first week.
We share your time zone, so the working day is the same on both sides and a question asked in the morning is answered in the morning. Because we are in the same city, a kickoff or an architecture session can happen at your office rather than on a call. Most of the work still happens in writing, in your repository and your chat, because a decision written down survives the people who made it.
We are the right fit when you have a defined piece of work and want a senior engineer on it this month rather than after a hiring round. Start with a fixed-price two-week piece and judge us on what ships. We also cover the months before your next hire joins, and work white-label for Bengaluru agencies 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 Bengaluru teams.
Can we meet in person?+
Yes. We are in Bengaluru, so a kickoff, a design review or a whiteboard session at your office is easy to arrange. We share your time zone, so calls happen inside your normal working day. Day to day we work in your tools, Slack, GitHub and Linear or whatever you already use, and you talk directly to the engineer writing the code. In-person time is best spent on the first architecture discussion and the handover.
Do you build for Bengaluru SaaS companies selling abroad?+
Yes, and it is one of the most common pieces of work we see here. We build what the first overseas enterprise customer asks for: single sign-on, custom roles, tenant isolation that holds under a missing filter, a log of who changed what, and billing through Stripe that copes with several currencies. The work happens inside your product, in increments that ship, so the deal keeps moving while the list gets shorter.
How does your rate compare to hiring in Bengaluru?+
PayScale puts a mid-career software engineer in Bengaluru at about ₹18 lakh a year. Our published rate is $35 an hour, with a $5,000 minimum. For that you get 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. Begin with a fixed-price two-week piece at $2,800 and judge us on what ships.
We keep losing engineers to GCCs. How can you help?+
We add senior capacity while you rebuild the team. An engagement starts within days, so the roadmap keeps moving through the notice periods and counter-offers. We take a defined piece of work, ship it in your repository, and write the architecture notes and runbooks your next hire reads in their first week. The code belongs to you from the first commit, so picking it up later is a conversation, not a project.
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.