Side projectProduct DesignSaaSWorkflow DesignBuilt with Claude Code
ScopeGuard: A Paper Trail for Scope Changes
On agency projects, scope changes get agreed on calls, in Figma comments and in Slack, and then nobody can find them. ScopeGuard gives every change a record: what was asked, what it costs, and what the client said. I designed it and built it as a working app.
Scope rarely grows through one big decision. It grows through small yeses that nobody writes down.
At the agency, I often sit between the client, the PM and the developers. ScopeGuard started from a pattern I kept running into there, and became a side project to practise designing a workflow tool end to end: deciding what it is, what it isn't, and what to cut.
01The problem, and who the tool is for.
02What the product deliberately doesn't do.
03Six product decisions, from status design to export.
04What I kept, changed and cut along the way, and why.
05How I used AI to build it, and where I didn't.
The Problem
On a typical project, scope moves in small steps:
01A feature gets cleared on a call, then turns out to need real engineering halfway through the build.
02A designer proposes an improvement without anyone saying it's extra scope.
03Client approvals happen over email and calls, and live in one person's inbox.
04Task trackers record the work, but not the decision behind it.
ScopeGuard tracks change, not work.
Task tools answer “who is doing what”. The questions I kept needing answered were different: what did we agree, what has changed since, and who approved it?
That made the core object a feature with a status and a history, not a ticket with an assignee.
Who It's For
Agency design and development teams working on client projects. Each role touches it differently:
Designer
Logs features as they're scoped, with the Figma link and a screenshot as proof of what was discussed.
Project manager
Raises change requests, records the client's answer after calls, and exports a clean list for sign-off.
Developer
Checks a feature's status before building it, instead of chasing the designer.
Client
Never logs in. Receives the export over email and answers yes or no.
I also considered brand managers and copywriters. I dropped them: the fit was loose, and they already have tools that work for them.
What it deliberately doesn't do
No task management
No document storage
No client portal or logins
No build or QA tracking
Writing this list early kept the product small. It is also what stops ScopeGuard from turning into a weaker version of tools teams already use.
Product Decisions
01
One Status That Follows the Whole Conversation
The first concept gave every feature two sets of tags: a scope status (In scope, Out of scope, Flagged, Changed) and a client approval (Pending, Approved, Rejected, Needs discussion).
Two badges per row meant two things to read and keep in sync, and they described the same journey.
I merged them into one lifecycle: Open, Flagged, Change Request Sent, Approved, Rejected, Deferred.
Deferred is not Rejected. It means “good idea, later phase”, which is how many of these conversations end.
Each status has its own colour, so a long table can be scanned without reading every row.
Editing a feature. Status is one required choice, not two.
02
A Dashboard That Answers “What Needs Me Today?”
The dashboard took the most iterations. I went through three directions:
Project firstRecent projects and their activity. It repeated the All Projects page, so it had no job of its own.
Data heavyChange request counts, approval states and progress indicators. More visible, but too much to take in at the start of a day.
FocusedTwo things only: the latest entries for each active project, and Needs Attention, every change request still waiting on the client.
The stats row from earlier versions moved out of the header into a quiet strip at the bottom of the page. Totals don't tell you what to do next. A list of open change requests does.
All Projects holds the full list, with search and archive, so the dashboard doesn't have to.The dashboard keeps only what needs action: recent updates and change requests waiting on the client.
03
Every Entry Is a Record, Not a To-Do
The point of ScopeGuard is proof, so each feature needs enough context to make sense months later.
Feature name and page are required. Notes, Figma link, Figma page, a screenshot and estimated hours are optional, but always in the same form.
Estimated hours let a change request carry its cost, so a “small” request can be discussed in numbers.
Filters by status and page, and bulk status changes for when a whole batch gets approved on one call.
Project links (Figma, Notion, the SOW) sit at the top of every project, one click from the scope.
A new project starts with its client and links to the source documents.
A project's features, with the notes, page and status of each change in one table.
04
Two Kinds of History
My original rule was “no manual snapshots”: the change log should update itself in the background. Building it showed me that wasn't enough.
What changed is automatic. Every status move is logged with its before and after, a date, and a note on why.
But a log can't answer “what did we agree at kickoff?” So I added saved versions: named checkpoints, like Initial scope or Pre-launch review, that capture the scope at that moment.
Edit history and saved checkpoints first lived in the same flow, and it was never clear which was which. Splitting them gave each one a single job.
The tab started as Updates. Once it held both, I renamed it History.
What changed: every status move, with a note on why it moved.Saved versions: named checkpoints to compare against later.
05
An Export Built for the Client Conversation
The client never logs in, so the export is the part of ScopeGuard they actually see.
It started as a single flagged items report. It became a filtered export, because different calls need different slices: everything pending this week, or everything on the product page.
Filter by status, page and date added, and preview exactly what will go out before exporting.
Estimated hours travel with each entry, so the cost sits next to the request.
It exports as a CSV, so it fits into whatever the PM already sends.
Filters on the left, a preview of exactly what the client will receive on the right.
06
The Quiet Parts of a Real Product
Settings and help aren't the interesting part, but a tool feels unfinished without them.
SettingsA default status for new features, plus date format and timezone, since exports go to clients in other regions.
HelpShort answers to what a new teammate would ask, starting with what a change request is.
ArchiveFinished projects leave the active view without being deleted.
Workspace settings, including the default status for new features.Help and support, written for someone opening the tool for the first time.
What I Kept, Changed and Cut
Most of the design work was deciding what not to build. Here's what moved between the first concept and the live app.
Cut
Stats row at the top of the dashboardTotals don't drive action. A quiet summary strip at the bottom does the same job without competing.
Quick add with just a nameA name without context isn't proof. Half-filled records are worse than none.
Separate client approval tagsMerged into one status lifecycle.
Brand managers and copywriters as usersA loose fit, and they already have tools that work.
Changed
Flagged items reportBecame a filtered export with a preview and hours.
Updates tabBecame History, split into What changed and Saved versions.
Generated first layoutsRebuilt by hand in Figma once the flows were right.
Added
Saved versionsReversing my own “no snapshots” rule, for the kickoff question.
Estimated hoursSo every change request carries its cost.
Deferred statusFor good ideas that belong to a later phase.
Kept
No client loginThe client still only sees the export.
Horizontal tabs for project pagesFeatures, History and Export sit as tabs on the project, not nested in the sidebar.
Automatic change logStatus moves are still recorded without anyone having to save.
Building It With AI
I started by generating layouts with Claude to test flows and structure quickly. The flows were useful. The interface was generic.
So I stepped back and set the hierarchy, type and colour myself in Figma: DM Serif Display for headings, Open Sans for the interface, and an olive palette checked for AA contrast.
Then I built it in React with Claude Code. My first approach was to perfect an HTML version and convert it later, which meant doing everything twice. Going straight to React and testing locally was much faster.
AI made it possible for one designer to ship a working product. The decisions about what to leave out were still mine.
What's Next
Real projects ship in phases, so the next step is grouping features into Phase 1, 2 and 3, and showing what moved to a later release. I'd also sort Needs Attention by how long each request has been waiting, so the oldest one rises to the top.
With a team using it, I'd measure how long change requests wait for a client answer, and how many entries have a Figma link or screenshot attached.
What I Learned
This project moved me from designing screens to designing a workflow. The question stopped being “does this screen look good?” and became “does this help a team make a clear decision faster?”
It also showed me how much of product design is deciding what not to build, and being willing to reverse my own rules when the product needed it.