Machine learning development in Pune
Predictive maintenance is the most oversold idea in Pune's plants. The vendor presentations promise failures predicted weeks ahead; the reality is often a handful of sensors, a few years of maintenance records written by hand, and not enough failures of any one kind to train a model. That does not make machine learning useless here. It means starting with the data you actually have.
Usually that means the maintenance log. On FM360 we clustered repeat faults across tens of thousands of work orders, and the same approach shows which machines and failure types keep coming back, which is what a maintenance manager needs first. Where machines do have sensors, simple anomaly detection on vibration, temperature or current often beats an elaborate model. We build these into the tools your team already uses, and we will tell you honestly when fixed rules are the better answer.
Pune runs two economies inside one metropolitan area. It is one of India's most important automobile and manufacturing hubs, with plants in Chakan, Pimpri-Chinchwad and Talegaon; Chakan alone hosts vehicle plants for Mercedes-Benz, Volkswagen, Bajaj Auto, Mahindra and Jaguar Land Rover, surrounded by hundreds of component suppliers. It is also one of the country's largest IT hubs, spread across Hinjewadi, Kharadi, Baner and Viman Nagar. And it makes vaccines: the Serum Institute of India, the world's largest vaccine manufacturer, is here too.
The most interesting software problems sit where those economies meet. Carmakers expect their suppliers to exchange schedules, shipping notices, drawings and quality documents electronically, and to keep up when the format changes. Plants want to know why a line stopped, which machine keeps failing and what the real output was per shift, but the data sits in machine controllers, a manufacturing execution system, an ERP and a supervisor's register, none of which agree. Industrial software startups, often founded by engineers who know those plants from the inside, are building products to fix exactly that, and selling them in India and abroad.
Our place is the software above the machines, working alongside your automation partner. We build the integrations that read what your machines and systems already expose, the data pipelines and dashboards that turn it into one picture, the supplier portals, the mobile apps for technicians and inspectors, and the SaaS products that package all of it. Pune also has a deep bench of IT services and engineering services firms, and a firm like ours can take a specialist piece of their larger programme, delivered under their name.
We are in Bengaluru and share your time zone, so the working day is the same on both sides and a problem raised in the morning gets a response that morning. Most of the work runs through your repository and a shared chat channel, and you talk directly to the engineer who writes the code. What we learn about your process, from calls, documents and photos of the floor, is written down as we go, so everyone works from the same picture.
We are the right fit for a defined build, an integration with an end date, or a product that needs to reach its first pilot plant before your own team is hired. Start with a fixed-price two-week piece and judge us on what ships. Pune's IT services and engineering firms can also bring us in white-label, under their 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 Pune teams.
How do you work with teams in Pune?+
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 you talk directly to the engineer writing the code. Photos, short videos and a walk-through call from the floor go a long way, and everything we learn is written into your repository as runbooks and architecture notes.
Can you connect to our machines and plant systems?+
Yes, through the data they already expose. We integrate with what your manufacturing execution system, historian, SCADA or machine gateways publish, whether that is a database, an API, a message broker or exported files, and build the pipelines, dashboards and apps on top. We work alongside your automation partner, who looks after the controllers, and help you specify any new data points worth adding to the line.
How does your rate compare to hiring in Pune?+
PayScale puts a mid-career software engineer in Pune at about ₹14 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. Begin with a fixed-price two-week piece at $2,800 and judge us on what ships.
Can you work white-label for our IT services firm?+
Yes. Work ships under your name, in your client's repositories and through your delivery process, and we sign an NDA before specifics. We stay behind your team unless you want us in the room. It works best for a well-defined specialist piece inside a larger programme, such as a data pipeline, a mobile app or an infrastructure migration, and the code belongs to your client from the first commit.
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.