Web platform development in San Francisco
The first enterprise customer arrives sooner than most San Francisco startups plan for, and its IT team brings a list. Sign-in through the identity provider they already use, automatic provisioning when someone joins or leaves, roles their own admin can manage, an activity log they can export, and a straight answer about where their data is stored and which model providers see it. A promising pilot can wait a quarter while those features are built.
We build that enterprise layer into web platforms: SAML and OIDC sign-in, SCIM provisioning, role-based permissions, exportable activity history, per-tenant settings for data retention and model use, and an admin console that lets customers manage it themselves. It is unglamorous work, and it is often the difference between a pilot and a signed contract. We write the architecture notes as we go, so your answers to the customer's questions are short and accurate.
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.
We replace the role column with a permission model that can express teams, access to individual resources and roles the customer defines, add SAML or OIDC sign-in, and write the audit log their security questionnaire will ask about.
Or very nearly did. We find every query that can cross a tenant boundary, enforce the tenant in one layer rather than in every handler, and add tests that try to read across that boundary on purpose.
We build the admin side properly: search across organisations, an audited view-as-user mode, and screens for access and usage. Support stops asking an engineer to run a query against production every time a customer says something looks wrong.
An early Next.js app with auth stitched into middleware, a custom server, and a release process that lives in someone's head. We move it forward in small steps, with preview environments and a pipeline anyone on the team can ship from.
A Next.js platform scoped per organisation, where an administrator can view the app as any other user and each Tableau report opens only for people granted it.
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 is wrong with a role column?+
Nothing, until you have more than one kind of customer. A role says who a user is; most real questions are about what they can do to one specific thing, inside one specific organisation. Encoded as role checks, every new requirement becomes a code change in many places. We model permissions as data, check them in one place, and test them like any other logic.
Should we use an auth provider or build our own?+
Use a provider for identity: passwords, magic links, SSO and multi-factor. It is a solved problem and getting it wrong is expensive. Authorisation, meaning what a signed-in user may do, is specific to your product and usually belongs in your own code and database. We wire the first to the second and keep the line between them clear.
How do you handle multi-tenancy?+
Usually one database with a tenant ID on every row, enforced in one place: Postgres row-level security, or a data-access layer every query has to pass through, rather than each handler remembering. A separate database per tenant is sometimes right, for one very large customer or strict isolation, and we will say if that applies to you.
Where does it get hosted?+
Wherever suits your team. Vercel is the least effort for Next.js and fine for most platforms. If cost or long-running background work make that awkward, we run it in containers on Railway, AWS or your own Kubernetes. The repository, the cloud accounts and the bill are in your name either way.
What do enterprise customers ask for, and can you build it?+
Single sign-on through SAML or OIDC, audit logs, role management, session controls, encryption and data export. We build each of them into the platform and help you answer the technical questions on a customer's checklist accurately, so the security conversation speeds the deal up instead of stalling it.