is responsive design out of scope?

Often, yes — which is exactly why silence in a contract tends to favor inclusion. If the prevailing norm for the kind of site you agreed to is that it works across phones and tablets, a client who said 'build me a website' can reasonably expect that. The norm isn't universal, though, and it doesn't override an explicit desktop-only scope. Treat strong professional default as a thumb on the scale toward In Scope, not as an automatic verdict.

It depends on how far the original scope sat from a responsive build. If desktop-only was genuinely the agreed deliverable, adding mobile means new layouts, additional breakpoints, and a separate round of cross-device testing — real, scopeable effort that warrants its own fee. Price it by what those additions cost, not as a flat percentage, since a simple site and a complex one differ enormously. If responsive was always the reasonable default, there may be nothing extra to charge at all.

Neither side automatically, which is the honest answer. A bare 'website' is filled in by professional norms and by how the project was priced and scheduled. If both point toward a modern responsive build, inclusion is the fair reading; if the budget and timeline only ever fit desktop, exclusion is. When the signals genuinely conflict, the grown-up move is to name the ambiguity and split it fairly rather than insist on whichever interpretation pays you more.

Then you have a shared blind spot rather than a violation, and the response is to resolve it on the merits. Ask whether responsive was implied by what you agreed and how it was priced. If it was the reasonable default, build it; if it genuinely wasn't, scope it as an add-on and explain why. The fact that the client is only now raising it doesn't decide the question — what the contract and the norms imply does.

Yes, and it's the single best fix. Listing target devices or specific breakpoints in the deliverables turns an assumption into an agreement, so neither side is guessing later. You can state exactly which viewports are supported, what testing is included, and what falls outside. A few precise lines about screen support prevent the most common version of this dispute, because there's nothing left for either party to fill in with wishful thinking.

Often, and it's a clean way to handle a true ambiguity. Shipping the desktop build against the original scope and offering responsive as a defined follow-on lets the client get value now and decide on mobile with a clear price in front of them. Scope phase two like any deliverable — layouts, breakpoints, testing, fee — so it doesn't bleed back into the first. This works best when you flag the split before building, not after the client assumed mobile was coming.