MVP development in San Francisco
Investors in San Francisco have seen a great many AI demos, and the ones that stand out are the ones that work on real data rather than a curated example. An MVP here has to survive a partner pasting in their own document during the meeting.
We build MVPs that are narrow but real. The part that makes the product distinctive, usually the workflow around the model and the evaluation that proves it works, is built properly. Everything else, from sign-up to billing, uses the simplest thing that holds. Scope is fixed and the two-week starter is the usual beginning. The code is in your repository from the first commit, so diligence finds a codebase your next engineer can pick up, not a prototype nobody can extend.
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.
Every feature is marked essential. We work with you to find the one journey a user must complete for the idea to be proven or disproven, build that properly, and write the rest down as a list for after launch.
It was built with a no-code tool or over a weekend, and real users are now finding its limits. We keep what works, move the data somewhere you own, and rebuild the parts that break without taking the product offline.
A demo that works in the meeting and then has to become the product. We build it on a real database with real sign-in from the start, so the version you demo is the version you keep, not a mock-up you throw away.
You need someone to make the technical decisions and explain them in plain language. We write down every choice that is expensive to reverse, why we made it and what changing it would cost, so whoever you hire next can pick it up.
Began in 2024 as a script that turned monthly exports into charts, and grew step by step into a web app, a mobile app, a technician phone page and the one backend under all three.
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.
What does the fixed-price two-week starter cover?+
A defined slice of the product, agreed in writing before we start. For an MVP it is usually the core flow, working end to end against a real database. It costs $2,800. You get something running at the end and you keep the code either way, so you can judge us on output before committing to the rest of the build.
How long does an MVP take?+
It depends on what the smallest honest version is, which is why we scope before we quote. The two-week starter usually answers the question: by the end of it one flow works, and you have a written estimate for the rest with its assumptions listed. We would rather cut scope with you than promise a date we would miss.
Why Next.js and PostgreSQL?+
Because they are boring in the right way. Both are widely known, so you can hire for them later. Postgres will carry you a long way past your first paying customers, and Next.js gives you a web app and an API in one codebase. If the product is mobile-first, we build the app in React Native on the same backend.
Will we have to rewrite it later?+
Not if we do our job. The shortcuts we take are in scope, not in structure: fewer features, plainer screens, manual steps behind the scenes. The data model, sign-in, permissions and deploys are built properly from the first week, because those are the parts that force a rewrite when they are wrong.
Who owns the code and the accounts?+
You do, from the first commit. Repositories, hosting, domains and payment accounts are created in your name, not ours. If we set something up ourselves to save time, we transfer it to you before the first invoice. An MVP you cannot take to another team is a liability, not an asset.