Most companies buying here already employ engineers. That changes the question. You are not looking for someone who can write code, you are looking for someone to take work your own team should not be doing, and to leave behind something your team can live with afterwards. Get the boundary wrong and you buy an expensive dependency; get it right and you free the people who are meant to be building the product.
The verified supplier profiles are below. What follows is how to draw that boundary and how to test whether a firm respects it.
The San Francisco web development brief starts with what to keep in house
Draw a line between the product surface and everything that markets it. Anything behind authentication, anything touching customer data, and anything whose behaviour is the product usually belongs to your own engineers. The marketing site, the documentation shell, the careers section, the pricing and comparison pages, the campaign landing pages and the changelog are the things an outside firm can own without slowing anyone down.
Then be explicit about the shared edges. Signup and login flows straddle the line. So does anything that reads live data, such as status pages, customer counts or feature availability. Name each shared edge in the brief, decide which side owns it, and agree how a change to one side is communicated to the other. The most common failure in this market is not a bad build, it is two teams shipping into the same domain without a contract between them.
Rendering decisions in web development decide whether the site can be found
A marketing site built as a client rendered application is the default in some teams because that is what everyone knows. It is also the reason a company with an excellent product has pages that search engines index thinly, that take a long time to show content on a phone, and that break for anyone whose scripts fail to load. Ask each supplier what is rendered on the server or built ahead of time, and what depends on the browser.
Ask for the practical consequences too. How does an editor preview an unpublished page. How long does a content change take to appear, and does it require a deployment. What happens to page addresses, redirects and metadata when a page is renamed. How does the site behave for a visitor on a slow connection. These questions expose whether a firm has shipped marketing sites that had to perform, or only applications that had to work.
Build it so a launch does not need a sprint
Marketing teams here ship constantly, and the value of an outside build is largely in how much a non engineer can do alone afterwards. Ask what publishing a new landing page looks like, end to end, without a developer. Ask how experiments and page variants are handled, how tracking is attached to a new call to action, and how quickly a claim can be corrected across every page that repeats it.
Keep the marketing site out of the product repository unless there is a strong reason not to. Separate deployments mean a marketing change cannot break a release and a release cannot block a campaign. Web development that shares a pipeline with your product tends to end up queued behind it, which is exactly the situation you were trying to avoid when you hired an outside team.
Buying web development in a company that changes every quarter
Scope moves quickly here, so structure the engagement to survive that. Fixed price works for a defined rebuild with a stable specification. For continuing work, a capped time and materials arrangement with weekly reporting and a short notice period is usually more honest, provided you actually read the reports.
Whichever you choose, make leaving cheap. Repository in an account you own from the first week, deployment documented well enough that an incoming engineer can follow it, environment configuration recorded somewhere shared, and a written explanation of anything unusual. Ask what happens if you hire a web development lead next quarter and want to bring the work in house. A supplier who treats that as a normal outcome is the one worth signing.
Choosing between website development firms that all sound impressive
Ask for a site they built that is still live and still maintained by the client, and then look at how it performs on a phone. Ask which named people would work on yours and what else they are committed to. Ask how they handle a request that they think is a mistake, because you will make one. Prefer the firm that argues with the brief over the firm that praises it.
When you are ready for comparable numbers, outline the project and receive proposals from suppliers that match it, or browse the full list of web development companies and shortlist yourself. If the work is genuinely product engineering, compare software development firms instead, and if the brand and interface language still need to be defined, web design agencies cover that stage.
Questions to ask before hiring a web development company in San Francisco
Agency, studio or individual contractor?
A contractor is efficient and fragile, a studio buys continuity and process, an agency adds account management you may or may not need. Match it to how much internal coordination you can supply: the less time your team has, the more structure you should pay for.
Should the marketing site use the same design system as the product?
Share the tokens and the brand, not the component library. Product components carry interaction logic and constraints that marketing pages do not need, and coupling them means a product refactor can break a campaign page at an inconvenient moment.
How do we keep content changes from requiring engineers?
Insist on a content model rather than a set of hard coded pages, and test it before sign off by having a marketer create a page while you watch. If that exercise needs a developer, the model is wrong and it will not improve after launch.
What is a reasonable first web development engagement?
Something contained with its own acceptance criteria, delivered into production. A rebuilt section or a new template set tells you more about a supplier than any pitch, and it leaves you free to stop.