Is It Out of Scope? — Web development
Is building a custom reporting dashboard out of scope for a web development project?
Yes, unless it was named in the original feature list. A reporting dashboard means a data pipeline, storage, and a UI to visualize it — a genuine feature build, not a small addition to an existing app.
The build shipped and covers the features in the original spec. The client then asks for a dashboard to track some set of metrics — usage, performance, whatever's relevant to their business — often assuming most of the pieces already exist since the app already generates the underlying data somewhere.
Is it out of scope?
Yes, unless a reporting dashboard was named as a feature originally. Even when the raw data already exists somewhere in the system, building a dashboard means deciding what to track, building the queries or pipeline to aggregate it, and designing and implementing the UI to display it — a real feature, not a quick add.
Clause typically implicated
Clause typically implicated
Deliverables clause→ — Lists the specific features built — a reporting dashboard, including the data pipeline behind it, has to be named explicitly to be included.
Example contract wording
Example contract wording (illustrative, not legal advice)
A dashboard wasn't part of the original feature list. Building one means figuring out what to track, aggregating the data, and building the UI to display it — real feature work even where some of the underlying data already exists. I can scope this properly once we've talked through what metrics matter most to you.
How MarginFlow flags it
MarginFlow checks the extracted feature list for anything resembling reporting or analytics before classifying — where nothing matches, the request is flagged outside_scope with an explanation noting the data pipeline and UI work involved, since dashboards are commonly underestimated as "just displaying data we already have."