Machine learning development in Boston
Many Boston companies start with a model that already works, on the dataset in the paper. A spin-out from a university lab has a method that beat the benchmark, a founder who built it during a PhD, and customers asking to run it on their own data. What is missing is everything outside the notebook: a pipeline that prepares new data the same way the training data was prepared, a service that returns predictions reliably, and a way to notice when the model starts getting worse.
We build those parts around your model rather than replacing it. Preprocessing becomes versioned code shared by training and serving, so the two cannot quietly diverge. Inputs and predictions are logged and compared with outcomes as they arrive. 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. The founder stays the scientist, and stops being the only person who can run it.
Boston's software buyers mostly work in science, medicine, education and money: biotech and pharmaceutical companies in Cambridge and the Seaport, the hospital systems, digital health start-ups, the universities and the companies spun out of them, and the asset managers and insurers downtown. In most of them, software supports something else, an experiment, a patient or a portfolio. The people who commission it are often scientists and clinicians, many of whom write some code themselves and know exactly what they need the data to do. What they want from an engineer is not a new idea. It is the idea they already have, made reliable.
The work follows the science. Biotech labs need instrument output picked up as it lands and linked to the notebook entry that explains it, and internal tools that stay fast on thousands of assay results. Digital health companies need a backend that can read from a hospital's records system, and patient apps that save offline and keep the time each entry was made. Edtech companies selling to universities need platforms that know a teaching assistant from a department administrator. Lab suppliers need commerce that runs on purchase orders and negotiated prices, and the investment firms downtown need internal tools to replace the workbooks that run their operations.
Hiring has its own shape. Built In puts the average software engineer base salary in Boston at about $137,000, and the city's engineers are pulled between big tech offices, well-funded biotech and university spin-outs. The universities keep research talent in good supply. What teams more often lack is someone who has taken a system from a notebook or a prototype to something that runs unattended, is monitored, and survives its author going back to the lab. That gap, between a result that works once and a system that keeps working, is where we are most useful.
We are in Bengaluru and move our working day for Boston. Four hours of every working day overlap with your morning in Eastern time, stand-up included, so questions, reviews and decisions happen live with the engineer who writes the code. Runbooks and architecture notes are written as we go, so the system keeps running when the people who commissioned it go back to the lab.
We are the right fit for the gap between a result that works once and a system that keeps working: a pipeline, a hospital integration, a patient app, an internal tool. Senior capacity starts within days, the first piece is a fixed-price two-week engagement, and it can carry you from a funding round or grant to your first engineering hire.
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 Boston teams.
How do you work with teams in Boston?+
We are in Bengaluru and move our working day for Boston, so four hours of every working day overlap with your morning in Eastern time, stand-up included. We join your Slack, push to your GitHub and track the work in your Linear, so progress shows up where your team already looks. The person on every call is the engineer who writes the code, whether you are a scientist, a clinician or a CTO.
Do you build for Boston's biotech and life sciences companies?+
Yes. The work is usually the software around the science: pipelines that pick up plate reader, sequencer and imaging output as it lands and link it to the notebook entry, internal tools that stay fast on thousands of assay results, and search over protocols and SOPs that always cites the current version. We work alongside your computational scientists, turning what already works in their notebooks into systems that run unattended.
How does your rate compare to hiring in Boston?+
Built In puts the average software engineer base salary in Boston at about $137,000, before bonus and benefits. Our published rate is $35/hour, or $5,400 a month for an embedded engineer, with a $5,000 minimum. There is no recruiting time and no employment overhead, and work starts within days of the call. The first piece is a fixed-price two-week engagement at $2,800, so you judge us on what it produces.
What do the first two weeks look like?+
You share the context: the code, the data and the problem. Within two days you have a 30-minute call with the engineer who would do the work, and within a week a written plan. Then comes a fixed-price two-week piece at $2,800, such as turning one notebook or prototype into something that runs on its own. At the end you have working code in your repository, notes on how it runs, and a clear view of what comes next.
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.