Machine learning development in Los Angeles
Recommendation is the machine learning problem most Los Angeles media and creator platforms eventually face. It is also the easiest one to overbuild. A new platform has little viewing history, new titles have none, and the first model has to beat a very simple baseline, usually most popular this week, before it earns its complexity.
We build recommendation in stages. First the event data: what was shown, what was watched, for how long, and what was skipped, captured cleanly. Then a baseline that is hard to argue with, then models that use content metadata to handle new titles and new users, measured against that baseline on real engagement rather than offline scores alone. Every change ships behind an experiment, so you know whether it helped.
Los Angeles buys software for businesses that make things people watch, wear, listen to and fly. Entertainment and media are the obvious ones: studios, streaming services, post-production houses, music companies, games and the creator economy that grew up around them. Alongside them sit consumer brands selling direct to customers online, a fast-growing aerospace cluster around El Segundo and the South Bay, and the logistics trade that runs through the ports of Los Angeles and Long Beach. The buyer might be a creator with an audience, a studio's technology team or the operations lead at a launch company.
Each brings a different system. Media is heavy: video has to be ingested, transcoded, stored and served, storage and egress costs grow faster than anything else on the bill, and rights and territory windows decide who may watch what, where and when. Consumer brands live with launch-day spikes, when one post or one drop sends a surge of traffic in minutes. Creator platforms need moderation that keeps the product feeling fast. The South Bay's aerospace companies grow quickly and need the commercial software around the engineering: hiring and supplier portals, fan and merchandise stores, and the scheduling and operations tools a company outgrows spreadsheets for.
Built In puts the average base salary for a software engineer in Los Angeles at around $147,000, and studios, streamers and the large technology campuses in the city compete for the same people. Much of the work here also runs to a fixed date: a premiere, a new season, a product drop, a launch window. When the date is set and the team is short, a senior engineer who can start in days on a defined piece of work is often the quickest way to hit it.
We work from Bengaluru with four hours of live overlap every working day, placed across your morning in Los Angeles. Stand-ups, reviews and launch planning happen in that window, with the engineer who writes the code. Everything decided outside it goes into your repository, your tracker and the runbooks we write as we go, so each morning starts with a clear record of what moved.
We fit best around a fixed date: a store before a drop, a media pipeline before a new season, a creator app before launch, or commercial tools for a fast-growing South Bay company. Senior capacity starts in days, usually with a fixed-price two-week piece. Agencies can bring us in white-label, under their own 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 Los Angeles teams.
How do you work with teams in Los Angeles?+
We are in Bengaluru, with four hours of live overlap every working day placed across your Los Angeles morning. That window holds stand-ups, design reviews and launch planning, and you talk to the engineer who writes the code. We work in your Slack, your GitHub and your Linear, so progress shows up where your team already looks. Work finished outside the window is written up there too, ready when your day starts.
Do you build for media and entertainment companies?+
Yes. We build ingest and transcoding pipelines, rights and territory windows held as data, review platforms with expiring, watermarked links for outside collaborators, and archive search that finds a line of dialogue by its timecode. For labels and creator networks, we build the pipelines that turn platform statements into accurate payouts. Each piece is scoped to ship before the premiere, season or release date it is meant for.
How does your rate compare to hiring in Los Angeles?+
Built In puts the average base salary for a software engineer in Los Angeles at about $147,000, before equity, benefits and recruiting fees. Our published rate is $35 an hour, with a $5,000 minimum. You skip the months of recruiting and the employment overhead, and we can start within days. A fixed-price two-week piece at $2,800 is the usual beginning, so you judge us on what ships.
Can you work white-label for a Los Angeles agency?+
Yes. Many Los Angeles creative and digital agencies win the brief and then need engineering behind it. We build under your name: your client sees your agency and your process, and we work inside your Slack, tracker and repositories. We can join client calls in the overlap window or stay behind the scenes. An NDA comes first, 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.