Swain-Tech Studio websites for small businesses and independent creatives

Red Flags in a Proposal

A proposal is the first sample of how someone works. Before it tells you what they will build, it tells you whether they are organised, whether they have thought about your situation, and whether the eventual disagreement will be resolvable.

Most of these signals are not about dishonesty. They are about vagueness, and vagueness is what disputes are made of. Where decisions rely on what people say rather than what can be observed, self-reporting bias is a useful caution about self-reported information.

The clear red flags

A single number with no breakdown. "Website: $4,000." You cannot tell what is included, cannot compare it with anything, and cannot query a line you disagree with. Ask for an itemised version; a reasonable request that some people find surprisingly difficult.

No mention of what you must supply. Every project stalls waiting for the client's words and images. A proposal silent on this has either not thought about it or is planning to blame you later.

Unlimited revisions. Sounds generous, is not. Either it is untrue and will be renegotiated when you use it, or it is true and priced into the number you are paying. Defined rounds plus a stated rate afterwards is the honest structure.

No timeline, or a timeline with no dependencies. "Four weeks" means nothing without saying four weeks from what, and what pauses the clock. For an independent reference beyond this site, Freelancer is a useful place to compare approaches.

Nothing about ownership. Domain, files, accounts, licences. Its absence is the most expensive omission on this list.

No payment schedule. Full payment upfront is a risk to you; full payment on completion is a risk to them. Staged payments tied to milestones protect both.

Guaranteed search rankings. Nobody can guarantee a position on a system they do not control. This is the one item on the list that is straightforwardly disqualifying.

Copy-paste that is not about you. A proposal referring to the wrong industry, or containing no sentence that could only have been written for your business, tells you how the project will go.

The softer signals

No questions asked before the proposal arrived. Someone who quoted without asking what you sell has quoted a template.

Everything is included and nothing is excluded. Real proposals have an exclusions section. Its absence means the exclusions still exist and you will meet them later.

A price that expires on Friday. Urgency is a sales technique, and a fair price is still fair next month.

Technology as the argument. A proposal built around platform names rather than around what your business needs has led with the tool.

No mention of what happens after launch. The site going live is the middle of the project. Silence here means support will be improvised.

Three phrases worth one more question

"SEO included." Ask what that means. It may mean sensible technical work — clean structure, fast pages, correct metadata, a sitemap — which is legitimate and should be standard. Or it may mean stuffing keywords, or an ongoing retainer described as part of the build. All three get called the same thing.

"Fully custom." Ask custom from what. A theme adapted to your brand is often the right choice and considerably cheaper; there is nothing wrong with it unless it is being billed as design from a blank page.

"Mobile responsive." In 2026 this is like advertising that a car has wheels. If it appears as a selling point, the proposal may be several years old.

What a good proposal has

Not length. Six things.

Your situation described back to you, in a way that shows they listened.

Itemised scope, with an explicit exclusions list.

What you supply, and by when.

A timeline with dependencies — what pauses the clock and what happens if it does.

Payment stages tied to milestones.

Ownership and post-launch arrangements, stated rather than implied.

Two pages containing those six beats twenty pages of process diagrams.

The test that works

Ask one hard question and watch the response.

What's not included? or what would make this go over? or what's the part of this you're least sure about?

Someone who answers specifically — naming a risk, explaining a dependency, admitting an unknown — will handle the actual project the same way. Someone who reassures you that nothing will go wrong is telling you how they will behave when something does.

That response tells you more than the document.

The short version