How to read a studio's proposal: the eight lines that decide everything

You asked three studios for the same thing and got three documents that agree on nothing — not the price, not the timeline, not even what the project is. The instinct is to compare the totals. The total is the least informative number on the page, because it is the only number every studio knew you would look at first.

We write these documents. We have also read a lot of other people's, usually while quoting to repair what they produced. Eight lines separate a proposal you can hold someone to from a nicely typeset hope. None of them is the price.

1. Who owns the work when the last invoice is paid

The sentence you want is short and boring: on final payment, the work transfers to you. What you often get instead is the word license — “we grant you a license to use the site”. A license is not ownership. It can carry conditions and it can end. Ask plainly what happens to the code if you stop working together.

There is a legitimate version of this. Studios reuse their own frameworks and components across clients, and those stay theirs — that is how anyone gets faster over time. It just has to be named in the document, and the work specific to your project still has to be yours. “Some of this is ours, here is exactly which part” is a professional answer. Silence is not.

2. Whose name is on the domain, the DNS and the hosting

Accounts get created in a hurry in week one, and whoever's email address was handy becomes the owner for the next ten years. The proposal should state that every account is created in your name, with the studio granted access. If it does not say, ask, and get the answer in writing before you sign anything.

This is the most expensive item on the list to fix later, and the only one that can end with lawyers. We wrote out the full ownership list separately, because the calls we get about it are the saddest ones in this business.

3. What happens the day after launch

Launch is not the end of the work. It is the moment you find out what the work does with real traffic, real customers and real data. A usable proposal names three things: how long defects are fixed at no charge, what counts as a defect rather than a change, and how quickly somebody responds when the site is down.

“Support included” without those three is decoration. The middle one matters most, because that is where the arguments happen — one side calls it a bug, the other calls it a new requirement, and whoever wrote the definition wins.

4. What is excluded

A scope with no exclusions list is not a scope, it is a mood. The items that quietly become invoices later are always the same ones: writing the content, photography, translations, migrating your old data, integrations with systems you do not control, third-party subscriptions, and training your team to use the thing.

A studio that lists these is not being difficult. It is the only one showing you the real budget. When you compare a proposal with an exclusions list against one without, you are usually comparing a full price against a deposit.

5. How change requests are priced

You will change your mind. Everyone does, because the work reveals things nobody could see at the start. So the question is not whether there will be changes — it is whether the cost of changing your mind is written down while you still have leverage. Look for a rate and a unit. “We can discuss it as we go” means you will discuss it mid-project, against a deadline, from the weakest position you will ever hold.

Be equally suspicious of unlimited revisions. Nobody works for free; unlimited revisions are priced into the base with a buffer large enough to survive the most indecisive client the studio has ever had. If that is not you, you just paid for somebody who was.

6. What “responsive” and “SEO-optimized” actually commit anyone to

Both phrases appear in nearly every proposal and neither has a test attached. Attach one. For responsive: which screen widths get checked, on which real devices. For SEO: which measurable thing improves, and by when.

The honest answer to the second one is uncomfortable, and you should want to hear it — nobody can promise rankings, because nobody controls the ranking. What a studio can control is structure, speed, crawlability and a content model that lets you publish without help. A studio that offers those and declines to promise position one is telling you the truth; a studio that guarantees rankings is telling you what you want to hear.

The same trick works on “fast”. Ask which number is being committed to and how it gets measured. We put speed targets into the scope with a threshold, and a release that misses the threshold does not go live. That is a promise you can check. “Blazing fast” is a mood.

7. The payment schedule against the delivery schedule

Put the two side by side on one page. If most of the money is due before anything is visible, you are financing somebody's cash flow with no leverage and no proof. Payments should attach to things you can look at: an approved design direction, a working site on a test address, a launched site, a completed handover.

Deposits are normal and fair — we take one. A deposit that amounts to most of the project is not a deposit, it is a prepayment, and prepayments are how projects end up finished on paper and abandoned in practice.

8. Who actually does the work

Ask for names and what each person will do. “Our team of experts” often means a subcontractor you will never speak to, which is fine when it is disclosed and a problem when it is not — because when something gets hard, you need the person who built it, not a relay carrying messages between you and somebody in another timezone.

This is our own bias in the open: we are small on purpose and you talk to the people building your product, so of course we think it matters. Judge the claim rather than the sentiment. Ask who answers your email in week six, and what happens if that person is on holiday.

Holding ourselves to it

Grading other people's documents is easy, so here is where ours land on the same eight lines. Work transfers on final payment, and we name the components we reuse. Accounts are created in your name in week one. Defects are ours for a fixed period after launch, with the definition of a defect written down rather than negotiated later. Exclusions are listed, including the ones that make the total look bigger than a competitor's. Changes have a rate and a unit. Speed is a number with a threshold, not an adjective. Payments attach to things you can open in a browser. And the people named are the people who answer your email.

We publish this partly because it is useful and partly because it is a commitment: a client who has read it can hold us to it, which is the point. If a studio is reluctant to be measured on these eight lines, that reluctance is the most reliable signal in the whole process.

Two questions that reveal more than the document

“If the budget dropped thirty percent tomorrow, what is the first thing you would cut?” A studio that thinks in outcomes answers immediately and cuts scope — fewer pages, fewer features, the same quality. A studio that thinks in deliverables goes vague, or offers to cut testing, which tells you exactly what it believes testing is for.

“Show me something you built two or three years ago that is still running, and tell me what broke.” The first half is a portfolio question anyone can answer. The second half is the real one. Everything breaks eventually; only the people who were still around afterwards know what broke and why. Vagueness here usually means they launched it and left.

When the expensive proposal is the right one

None of this argues for the cheapest quote. A high price with all eight lines answered is a lower-risk purchase than a low price with none of them. The expensive proposals we respect got expensive by including the invisible work — deciding what to build, testing it, migrating the old data, handing it over properly. The cheap ones are usually cheap because those four are missing, and you will buy them anyway, later, at a worse moment and a worse price.

So read the eight lines first, then read the total. If two proposals disagree, the disagreement is the useful part: it shows you which studio thought about the thing the other one left out. Line them up and the choice tends to make itself.