SaaS development in San Francisco
Pricing an AI SaaS product per seat stops working the moment one customer runs ten times the model calls of another. San Francisco companies are moving to usage-based and credit-based plans, which turns billing from a subscription setting into a metering system that must be accurate, visible to the customer, and hard to game.
We build SaaS with metering designed in: every billable event recorded once, aggregated per tenant, reconciled against what the model providers charged you, and shown to customers before the invoice arrives. Plans, credits and overage rules live in data rather than code, so finance can change them without a release. Around that sits the usual SaaS foundation of tenant isolation, roles, SSO and activity logs, so the first enterprise customer does not force a second rebuild.
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.
Then SCIM, then role mapping, then a security questionnaire. We add SAML and OIDC through a provider or your own identity stack, provision users from their directory, and keep the permission model working for the self-serve customers who never asked for any of it.
Shared tables with a tenant column and every query trusted to filter on it. We enforce isolation below the application, with Postgres row-level security or separate schemas, and write tests that try to read across tenants and must fail.
Moving from seats to usage, adding a free tier, or selling annual contracts beside monthly plans. We model plans and entitlements separately from the payment provider, meter usage into a ledger you can audit, and make proration and dunning tested code rather than a monthly surprise.
Every larger customer asks who changed what, who can reach production and how access ends when someone leaves. We build exportable audit logs, least-privilege access and change control through pull requests, so your answer is a screen, not a spreadsheet.
A multi-tenant platform scoped per organisation, with admin screens for users, access and login alerts, and a way for an administrator to view the app as any user.
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.
Shared database, separate schemas, or a database per tenant?+
Shared tables with row-level security for most products, because it is the cheapest to run and the simplest to migrate. Separate schemas or databases when a customer contractually needs isolation, data kept in a particular region, or its own backup schedule. We design so a large tenant can move to its own database later without rewriting the application, because that request usually arrives with the biggest contract.
When should we add SSO and SCIM?+
Before the deal that needs them, not in the first month. Design the user and organisation model so SSO slots in without a data migration, then switch it on when a paying customer asks. A provider such as WorkOS saves you building SAML and SCIM yourself, which rarely pays off until enterprise customers are a large share of your revenue.
Stripe, or a merchant of record like Paddle?+
Stripe gives you the most control over plans, invoices and the checkout. A merchant of record such as Paddle takes a larger fee and becomes the seller, handling tax wherever you sell. For a small team selling internationally from the start, the merchant of record is often the simpler path. We lay out both at your price point before you choose.
Can you make the product ready for enterprise buyers?+
Yes. Enterprise buyers ask for the same things every time: single sign-on, directory provisioning, roles they can define, an audit log they can export, and admin screens their IT team can use. We design those into the data model early, so saying yes to the next large customer is a configuration change rather than a quarter of rework.
What have you built that carries over to SaaS?+
Multi-tenancy, per-organisation access and admin tooling run through most of what we build. FM360 is a multi-tenant platform with all three: organisations, apps and access managed per customer, usage analytics and login alerts. Subscriptions and billing logic we build inside the product, tested like any other code rather than left to a dashboard.