What a web studio actually does, and what it costs

Two studios quote for the same website. One says nine thousand, the other says ninety. Both describe the same deliverable. Somebody is wrong, and it is usually neither of them.

What the money is actually buying

The intuition most people bring is that a website costs what it costs to produce: pages made, pixels pushed, hours logged. That intuition is wrong in a specific and expensive way. On every project we have run, production is the cheapest part. The cost is in decisions.

Deciding what the thing is for. Deciding what goes on the first screen and what gets cut. Deciding whether the checkout is Stripe hosted or in your own flow, and who eats the failure when a card declines. Deciding what happens on a phone, on a slow connection, for a screen reader. Each of those is cheap to implement and expensive to get wrong, and a large part of what you are paying for is someone having got them wrong before, at their own expense, and remembering.

The five things a studio is actually doing

1. 01
   Working out what to build. Turning "we need a new site" into a definition specific enough to be finished. Most projects that go badly went badly here, months before anyone opened a design tool.
2. 02
   Design that survives contact with real content. Anything looks good with three perfect cards and lorem ipsum. The work is making it hold with a nine-word product name, an empty state, and a testimonial nobody wrote yet.
3. 03
   Building it. The genuinely mechanical part, and the part most people picture when they imagine what they are buying. On a normal project it is well under half the effort.
4. 04
   Putting it live. Hosting, domains, certificates, analytics, redirects from the old URLs, the search console, the thousand small things that are invisible when done and glaring when skipped.
5. 05
   Keeping it alive. Dependencies rot, platforms change their rules, and content goes stale. A site nobody maintains is a slowly depreciating asset.

How to read a quote

You are rarely in a position to judge whether a number is fair. You are always in a position to judge how it was arrived at. Four questions do most of the work:

• 
  What is explicitly not included? A quote that lists exclusions has been thought about. A quote that lists only inclusions is hiding the argument you will have in month three.
• 
  What happens when the scope changes? It will. The answer tells you whether you are buying a plan or a fantasy. "We would re-quote that piece" is a good answer. Silence is not.
• 
  Who owns the result? The code, the domain, the accounts, the design files. If the answer is unclear, you are renting your own business.
• 
  Who operates it after launch? This is the one that separates a supplier from a partner, and almost nobody asks it before signing.

When you should not hire anyone

Modern site builders are genuinely good now, and pretending otherwise to protect our own pricing would be dishonest. Webflow, Framer, Shopify and Squarespace will get you further than most studios like to admit.

Build it yourself when:

• 
  The site is largely content. Pages, posts, a contact form, a handful of sections.
• 
  You are still working out what the business is. Do not commission a custom build for a proposition that will change twice this quarter.
• 
  Standard commerce covers you. If Shopify's checkout does what you need, using it is not a compromise, it is the correct engineering decision.

Bring in a studio when:

• 
  The product is the interface. A dashboard, a configurator, a game, anything with real state. Builders fall apart quickly here.
• 
  You need systems talking to each other. When Being Juice needed a customer app, a Go backend, an admin dashboard, a kitchen display and analytics wired into the point of sale, no builder was going to hold that together.

• 
  The brand has to be specific. Templates are competent and they are shared. If you need to look like nobody else, that is bespoke work by definition.
• 
  Performance or accessibility is a requirement rather than a hope. Builders make this hard to control because they are optimising for the average case.

What we would want to be asked

Ask to see something that shipped and is still running. Not a showreel, not a concept, something with users on it today. Ask what broke on it and what they did about it, because everything breaks and the answer tells you whether they stayed.

For our part: our games are live on Reddit, one of them peaked at 42,000 daily players, and we still operate them. That is a more useful credential than any deck, and it is the standard we would hold someone else to.