Scope creep radar

Scope Creep Radar helps PMs spot hidden assumptions in stakeholder requests before they become delivery problems.

Comment

Inspiration

Scope creep usually does not start with a big formal change request. It often starts with a small message that sounds reasonable:

“Can we also add this before launch?” “Would it be possible to make this automatic?” “Can we include this in the dashboard too?”

As a project manager, I have seen how these requests are not necessarily bad ideas. The challenge is that they often hide work that is not obvious at first: design decisions, backend changes, data requirements, QA effort, permissions, timelines, or stakeholder alignment.

I built Scope Creep Radar to help PMs slow down for a moment before committing. The goal is not to reject change, but to make hidden assumptions visible early enough to have a clearer and more productive conversation.

What it does

Scope Creep Radar helps product and project managers review stakeholder requests before saying yes.

A user can paste a client message, internal request, meeting note, or transcript. They can also upload notes as .txt, .md, or .docx files and add reusable project context for different clients or teams.

The app returns:

  • a scope risk level: Low, Medium, High, or Critical
  • a quick summary of the risk
  • hidden assumptions behind the request
  • why the request may be bigger than it sounds
  • clarifying questions to ask before committing
  • a recommended next action
  • a suggested response the PM can send back

Users can also make the suggested response softer or firmer, copy only the response, copy the full analysis report, and clear the workspace when they want to start over.

How we built it

I built the project with Next.js, React, TypeScript, Tailwind CSS, and the OpenAI API. The app is deployed on Vercel.

The workflow is straightforward:

  1. The user enters a request and optional project context.
  2. The frontend sends that information to a Next.js API route.
  3. The AI returns a structured JSON analysis.
  4. The frontend displays the result in clear, copyable cards.

I first tested the analysis logic in Python so I could focus on the prompt and the quality of the output before building the interface. Once the analysis felt useful, I moved the project into a Next.js app to make it feel more like a real product.

For the MVP, I kept the architecture intentionally simple. Saved project contexts are stored locally in the browser with localStorage, so the app does not need accounts or a database. File uploads are handled in the browser for supported formats, with Mammoth.js used to extract text from .docx files.

Challenges we ran into

The main challenge was calibrating the risk levels.

At first, some small requests were treated as too risky, while other requests that sounded simple were not flagged strongly enough. I tested the prompt with different scenarios, including copy changes, UI logic changes, export requests, integrations, and late-stage launch changes.

Another challenge was deciding how much output a PM actually needs. A long AI-generated explanation can be interesting, but it is not always useful in the middle of a workday. I tried to keep the result practical: a quick read, the key assumptions, a few good questions, and a response that could realistically be sent to a stakeholder.

I also had to make trade-offs around scope. I considered adding deeper integrations such as Google Drive or PDF parsing, but decided to focus on a reliable core workflow first. For this version, uploading .txt, .md, and .docx files was enough to support common notes and transcript use cases without adding too much complexity.

Accomplishments that we're proud of

I am proud that the final app feels more like a usable PM tool than a simple AI text box.

The project includes the full workflow I originally wanted to test: reusable project context, request analysis, risk breakdown, clarifying questions, suggested stakeholder responses, tone adjustment, file upload, and copyable reports.

I am also happy with the balance between usefulness and simplicity. The app does not try to replace a PM’s judgment. Instead, it gives the PM a structured starting point for thinking through a request before committing to it.

Another accomplishment was shipping the project end-to-end: from prompt testing, to frontend design, to API integration, to deployment on Vercel.

What we learned

This project reinforced that useful AI tools do not always need to automate an entire workflow. Sometimes the value is in helping someone make a better judgment at the right moment.

I also learned how important it is to design the prompt around real usage, not just around impressive outputs. For this tool, the analysis had to be structured, realistic, and careful about not overreacting to every request.

Finally, I learned that small product details matter. Saved project context, tone adjustment, file upload, and copyable reports made the app feel more useful than a simple text-in/text-out demo.

What's next for Scope Creep Radar

The next step would be to connect Scope Creep Radar more directly to the tools PMs already use.

Future improvements could include:

  • importing requests from Slack, email, Jira, or Linear
  • connecting to Google Drive or Google Docs for project briefs and meeting notes
  • supporting PDF uploads with reliable text extraction
  • saving project contexts in a real database with user accounts
  • tracking repeated scope risks across a project over time
  • generating internal notes for the delivery team, not just stakeholder responses

Longer term, I would like the tool to help PMs identify patterns across requests, such as which clients, projects, or phases tend to generate the most scope risk.

Built With

Share this project:

Updates