Is It Out of Scope? — Web design
Is adding a members-only login area out of scope for a web design project?
Yes. Authenticated areas involve their own UX patterns (login, password reset, gated content states) that a public marketing site's design scope typically never accounted for.
The site was scoped as fully public — no accounts, no gated content. A request to add a members-only area (a resource library behind a login, a client portal, a subscriber section) introduces an entire second design surface: login/signup flows, password reset, empty/loading states for gated content, and often account-management screens — none of which a public marketing site's page list ever included.
Is it out of scope?
Yes. This is a substantial addition of new page types and interaction states, not a variation on the public pages already designed — closer in scope to adding a small application than to adding a page.
Clause typically implicated
Clause typically implicated
Deliverables clause→ — The deliverables list covers the public page set — a gated/authenticated area is a distinct set of screens and states outside it.
Example contract wording
Example contract wording (illustrative, not legal advice)
Our scope covers the public site pages — it doesn't include an authenticated members area, which needs its own login/signup flows and gated-content states. I'd like to scope this properly given the number of new screens involved; can we set up a call to go through what members should be able to see and do?
How MarginFlow flags it
MarginFlow flags authentication/members-area requests outside_scope with high confidence against a public-site deliverables list, and the suggested charge reflects the multiple new screens typically involved (login, reset, gated states) rather than treating it as a single page — helping the account manager avoid underquoting what's really a small application's worth of design.