Is It Out of Scope? — Web design
Is building a custom admin dashboard out of scope for a web design project?
Yes. A dashboard is an internal application UI with its own information-density and interaction-design demands, fundamentally different from designing public marketing pages.
The project was scoped as a public-facing site. Somewhere in the process — often once the client sees how the CMS works and starts imagining what else could be "designed nicely" — they ask for a custom admin dashboard: an internal tool for their team to manage something (orders, leads, content, users). Dashboard design is a genuinely different discipline from marketing-page design: dense data tables, filters, bulk actions, permission-aware UI — not a stylistic variation on the public site.
Is it out of scope?
Yes. This is a different kind of design work entirely — application/product UI rather than marketing-page design — and was never part of a site-design engagement's scope unless named explicitly.
Clause typically implicated
Clause typically implicated
Deliverables clause→ — The deliverables list names the public-facing pages being designed — an admin dashboard is a different product surface entirely.
Example contract wording
Example contract wording (illustrative, not legal advice)
Our scope covers the public-facing site design. A custom admin dashboard is application UI design — a different discipline with its own patterns (data tables, filters, permissions) — outside what we quoted. Happy to scope it separately once we understand what the dashboard needs to do; want to set up a short call?
How MarginFlow flags it
MarginFlow flags dashboard/internal-tool requests outside_scope with high confidence, since they virtually never overlap with a public-site deliverables list — the explanation notes the different design discipline involved (dense data UI vs. marketing pages), giving the account manager language that positions this as genuinely new work rather than scope ambiguity.