Machine learning development in San Francisco
Fine-tuning a model for your product is now within reach of a small San Francisco team. The hard part arrives a month later, when a new version performs worse and nobody can say which data, which settings or which base model changed. Without a record, the team retrains by guesswork and ships whichever run looked best in a demo.
We build machine learning with provenance recorded from the first experiment. Every dataset is versioned with its source and contents, and every training run records the data, settings and base model it used, so any result can be traced and reproduced. Each model is measured against a simple baseline and your own evaluation set before anyone calls it an improvement. Beyond fine-tuning, the work is classifiers, ranking and forecasting, held to the same standard.
San Francisco's software market is, for now, largely an AI market. The city is home to the best-known model companies and to a much larger layer of venture-backed startups building products on top of their models, alongside the SaaS, fintech and developer-tool companies that were here before. Most buyers are young companies with funding, a deadline set by their next raise, and more product ideas than engineers.
What they need is rarely the model. It is everything around it: queues for requests that take most of a minute, streaming that survives a dropped connection, fallbacks when a provider is rate-limiting, a record of what each request cost, and evaluation sets that tell you whether last night's prompt change made things better or worse. Then, often within months, the first enterprise customer arrives, and its IT team asks for single sign-on, automatic provisioning, roles their own admin can manage and an activity log they can export. A backend built for a demo meeting that list is where many pilots stall. We build the product and the infrastructure that make a model useful to paying customers, and the enterprise layer that turns a pilot into a contract.
Built In puts the average base salary for a software engineer in San Francisco at around $181,000, and the model companies compete for the same people with equity most startups cannot match. For a seed or Series A company, every senior hire becomes a search measured in months, and the roadmap waits while it runs. The work that piles up in the meantime is usually well defined: a provider integration, an admin console, a move to usage-based billing, a mobile companion app. That is the work we pick up in days and deliver in pieces you can judge on their own.
We work from Bengaluru with four hours of live overlap every working day, placed across your morning in San Francisco. Stand-ups, design calls and code review happen in that window, with the engineer who writes the code. Everything decided outside it goes into your repository, your tracker and the architecture notes we write as we go, so you start each day knowing what moved.
We fit best when the work is defined and the roadmap will not wait for a hire: the product and infrastructure around a model, the enterprise features a first large customer asks for, or the months before your next engineer starts. Most teams begin 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 San Francisco teams.
How do you work with teams in San Francisco?+
We are in Bengaluru and overlap with you for four hours every working day, placed across your San Francisco morning. Stand-ups, design calls and code review happen live in that window, with the engineer who writes the code. We work inside your tools: Slack for conversation, GitHub for code and review, Linear for the plan. Anything decided outside the window is written down there, so nothing depends on memory.
Do you build for AI startups?+
Yes. Most of that work sits around the model rather than inside it: retrieval over your own data, evaluation sets that run on every prompt change, streaming interfaces, cost tracking per customer, fallbacks between providers, and logging that explains an answer after the fact. Then comes the enterprise layer your first large customer asks for: single sign-on, provisioning, admin roles and activity logs, built so the pilot can become a contract.
How does your rate compare to hiring in San Francisco?+
Built In puts the average base salary for a software engineer in San Francisco at about $181,000, before equity and benefits. Our published rate is $35 an hour, with a $5,000 minimum. There is no recruiting search and no employment overhead, and we can start within days. Most teams begin with a fixed-price two-week piece at $2,800, so you judge us on working code before committing to more.
Can you make our prototype ready for real customers?+
Yes, and it is a common place to start here. A prototype built fast for a demo usually needs the same things: model calls moved into queued, retried jobs, costs recorded per request, tests around the parts that change most, and deploys from CI. We read the code, send a written plan within a week, then take the most urgent piece as a fixed-price two-week job. The repository is yours throughout.
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.