Maya had a genuinely good idea. A browser extension that pulled syllabi from her university's course portal and auto-generated a color-coded calendar. She sketched it in a notebook, gave herself six weeks, and opened Claude to start planning.
Three hours later she had a document describing: a Chrome extension, a companion iOS app, a shared study-group calendar sync, professor rating integration, grade prediction models, and a premium subscription tier. Every single feature had come from a conversation where she said "what if it also did X?" and the AI said "great idea — here's how."
Maya's six-week project had become a two-year startup. She hadn't noticed the moment it happened because nothing had felt like a wrong turn. The AI had never pushed back. It just kept helping.
This isn't a Maya problem. It's a design reality. Large language models are trained to be helpful, and "helpful" in a brainstorming context almost always means additive. When you ask "what else could this do?", the model doesn't have access to your energy levels, your deadline, your skill ceiling, or the opportunity cost of each feature. It just knows features.
The result is what product people call a yes machine — a collaborator that enthusiastically validates every expansion without ever asking whether expansion is the right move. Pre-AI, your ideas were naturally constrained by the friction of execution. You had to figure out how to build each feature yourself, and that friction acted as a filter. AI removes most of that friction, which sounds like a win but quietly eliminates a natural brake on scope.
Scope creep isn't new. Construction projects, film productions, and software teams have dealt with it forever. What's new is the speed and persuasiveness of AI-assisted scope creep. When a model generates a detailed implementation plan for your half-formed idea in thirty seconds, that idea starts to feel real and achievable — which makes it very hard to cut.
AI lowers the cost of imagining something so dramatically that imagination itself stops being the constraint. Execution time, focus, and user value become the real bottlenecks — but AI makes them invisible until you're already overcommitted.
Not all scope creep looks the same. In AI-assisted projects, three patterns show up most often:
Adding capabilities that aren't in the original problem statement. "It should also let users export to PDF." Each feature sounds small. Collectively they triple build time.
Expanding who you're building for. "Actually, this could work for high school students too. And maybe professors want a version." Every new audience requires redesign.
Adding platforms before the first one works. "Should we do a mobile app? What about an API for other tools?" Platforms multiply complexity, not just effort.
Raising standards beyond what the current version needs. "We should probably add proper error handling, onboarding flow, and analytics before launching." Perfect becomes the enemy of shipped.
Here's why this is hard to resist even when you know it's happening. When you're in a good brainstorming session with an AI, you're getting a hit of something that feels like progress. The document is growing. The vision is expanding. You can see the full picture of what this could be. That feeling is real — but it's the feeling of imagining progress, not making it.
Researchers studying motivation distinguish between approach goals (moving toward something) and completion. Brainstorming with AI keeps you in approach mode indefinitely because completion never has to happen. You can always add one more thing. The model never gets tired, never says "okay, let's actually build this now."
A lot of people in your position — building something on the side, between classes or jobs — fall into this trap specifically because their schedule doesn't allow for sustained execution sprints. So brainstorming with AI fills the time. It feels productive. And six weeks later nothing has shipped.
Before your next AI brainstorming session, write this at the top of your document: "The goal of this session is to NARROW, not expand." Then literally start the chat by saying: "I'm going to describe my project idea and I want you to help me cut it down to its smallest useful version, not add to it." This single prompt change reframes what the AI is optimizing for.
The antidote to scope creep isn't discipline in the abstract — it's a concrete definition of done that exists before you start building. Product teams call this a Definition of Done (DoD), and it's as useful for a solo side project as for a ten-person startup.
Your DoD has three parts: (1) a specific user action the product enables, (2) a specific user who would do that action, and (3) a binary test for whether the product works. Maya's original DoD was: "A college student can paste their syllabus URL and see a calendar with color-coded deadlines." That's testable. The moment she started adding grade prediction, the DoD blurred — and with it, any sense of what "finished" looked like.
Write your DoD before you open the AI. Not during. Before. The AI should be helping you reach your DoD, not expanding it.
You're going to describe a side project you're working on (or one you've thought about). Your AI lab partner will push back like a sharp advisor who's seen too many side projects die of over-ambition. They'll help you identify where scope has already crept, classify which type of creep it is, and draft a tight Definition of Done.
This isn't going to be all positive reinforcement. Expect the AI to ask hard questions about what your project actually needs to do versus what you want it to eventually do.
Jordan was a junior at a state school who'd been freelancing as a web developer since sophomore year. He wanted to build a tool that let small nonprofits create simple donation pages without knowing code — he'd seen his mother's community organization struggle with it. His budget: $0. His timeline: eight weeks before fall semester got too heavy.
Jordan had already been burned once. The previous summer he'd started building a "complete nonprofit management platform" that covered donations, volunteer scheduling, and event registration. He'd used AI to generate everything from database schemas to marketing copy. After four months, none of it worked end-to-end. He'd built features for an architecture that didn't exist yet.
This time he did one thing differently. Before opening any AI tool, he wrote a card: "Donation page. One nonprofit. Working by September 1." He taped it to his monitor. Then he used AI exclusively to pressure-test whether features belonged inside that boundary — not to generate what was possible outside it.
Jordan's card is a primitive version of what product teams call a scope container — a hard boundary defined before development begins. The container has a fixed outside wall, and everything generated during development goes through a test: does this fit inside, or does it expand the wall?
The conventional wisdom is to define scope by listing what's in. The problem is that lists grow. A better approach is to define scope by its constraints — the things that cannot change regardless of what the AI suggests. Jordan's constraints were: one nonprofit, one use case (donations), no backend complexity beyond what he could deploy for free, shipped by September 1. Anything that violated a constraint was automatically out.
This is counter-intuitive because it sounds like you're artificially limiting yourself. You're not. You're protecting your ability to ship. A working donation page beats a non-functional nonprofit platform every single time — for users, for your portfolio, and for your sanity.
Instead of asking "what should this include?" — ask "what would force me to miss my deadline or break my DoD?" Any feature that creates that risk is outside the container. This reframe turns AI from a feature generator into a scope protector.
A Minimum Viable Boundary (MVB) is built from three constraint categories. Every side project needs at least one from each:
Here's the move most people don't make: give your constraints to the AI at the start of every session. Not once at the beginning of the project — every session. Memory is short, context drifts, and an AI that helped you narrow scope last week will cheerfully help you expand it this week if you don't re-anchor it.
A re-anchoring prompt looks like this: "Before we start: my MVB is [describe it]. My ship date is [date]. My user is [person]. Any suggestions you make today should fit inside those constraints. If I propose something that doesn't, tell me."
This works because you're not asking the AI to have values — you're asking it to apply your values as a filter. That's something it can do consistently well. The judgment about what the constraints should be is still yours. The enforcement is something the AI can help with reliably.
Each session starts fresh. AI naturally drifts toward what's possible. Features accumulate across sessions without anyone tracking cumulative scope impact.
Each session starts with the boundary restated. AI flags suggestions that violate constraints. You make a deliberate choice to expand scope, not an accidental one.
One reason people resist scope containers is that they're afraid of losing good ideas. That fear is legitimate — AI sessions do generate genuinely useful feature ideas that don't belong in v1. The answer isn't to add them. It's to capture them without committing to them.
A parking lot is a separate document (or a clearly labeled section) called "v2 ideas" or "after ship." Every time a good idea comes up that's outside your MVB, you write it there and immediately return to the work. The idea is not lost. It's quarantined from your current scope. This satisfies the psychological need to capture the idea without letting it hijack the project.
Parking lots also do something valuable after you ship: they show you which ideas still seem important a month later versus which ones were just exciting in the moment. Most of the things in your parking lot, you'll never want to build. The ones you still want three months post-launch are the ones that might be worth v2.
Right now, write your MVB on a physical card (or phone note you'll see daily): your ship date, your specific user, your technical ceiling. Start every AI session with: "My MVB is [this]. Keep me inside it." Create a parking lot doc. Every idea that doesn't fit your MVB goes there — no exceptions, no "just this one."
You're going to work with your AI lab partner to build a real Minimum Viable Boundary for your project. This means drafting actual constraint statements — not vague intentions — for all three constraint types: time, user, and technical ceiling. The AI will pressure-test your constraints to make sure they're specific enough to actually hold.
Expect pushback if your constraints are too loose. "Ship when it's ready" isn't a time constraint. "Students" isn't a user constraint. The AI will tell you when you're being vague — take that seriously.
Darius was two weeks from launching his first Shopify app — a tool that let store owners schedule flash sales with a countdown timer. Clean, focused, genuinely useful. Then he got on a call with a friend who ran a small e-commerce brand.
The friend was excited. "This is great. But you know what would make it perfect? If it could automatically pause Google Ads during the sale so you're not paying for traffic you don't need. And send an email blast an hour before. And maybe integrate with Klaviyo..."
Darius opened his AI and spent three hours building specs for the Ads integration. It was technically feasible. The friend had a real problem. The AI generated excellent implementation plans. And Darius's two-week launch became six weeks, during which his friend's store launched a competitor product that did flash sales manually, got 200 customers, and validated the market Darius was still trying to perfect his way into.
Darius's problem wasn't that the Ads integration was a bad idea — it wasn't. His problem was that he had no framework for evaluating whether a good idea belonged in this version. Without a framework, every good idea is a green light. And in an AI-assisted project, good ideas arrive constantly.
A feature decision framework is a set of questions you ask about every proposed feature before it enters your backlog. The questions aren't about whether the feature is good in isolation — they're about whether it belongs here, now, in this version, for this user. The distinction matters because a feature can be genuinely valuable and still be wrong for your current version.
This is something your peers building with AI often skip. The assumption is that if the feature is good and the AI can help build it, you should build it. But you're not optimizing for "best possible product ever" — you're optimizing for "shipped product that helps a real user soon."
Every proposed feature goes through this filter before it touches your roadmap. A "no" on any question sends it to the parking lot.
This is the one that requires the most judgment and where AI can actually help well. You can ask: "If I ship without [feature X] and want to add it in v2, how hard is that architecturally?" The AI can give you a useful read on technical debt and reversibility.
Once you have the four-question filter, you can use AI to run it consistently. The prompt structure looks like this: "I'm considering adding [feature]. My current user is [person] whose goal is [specific action]. My ship date is [date]. My current planned scope is [brief list]. Run this feature through the four-question filter and tell me if it passes."
The AI's answer won't always be right — it doesn't know your energy levels or what you secretly know about your codebase — but it forces a structured evaluation instead of a gut-feel yes. And it creates a record: you can scroll back and see why you decided to park something, which prevents re-litigation of the same decision three sessions later.
Decision fatigue is real. When you're building something you care about, every feature decision feels high-stakes. A framework reduces that fatigue by turning value judgments into procedure. You're not deciding whether the Google Ads integration is good — you already know it's good. You're deciding whether it belongs in this version. That's a narrower, less emotionally charged question.
Here's the thing about Darius's story that's easy to miss: his friend's store didn't launch a competing product because the friend was smarter. The friend launched because the manual version was good enough to test the market. Darius was so busy making something perfect that he missed the window to learn whether anyone wanted the basic thing.
Every week you spend on features beyond your MVB is a week you're not getting user feedback, not discovering which assumptions about your user are wrong, and not building the next version based on actual behavior. Scope creep doesn't just delay launch — it delays learning. In a market that's moving, delayed learning is a real cost, not just an abstract one.
The question isn't "is this feature worth building?" It's "is this feature worth the market learning I'm trading for it?" For most v1 features beyond the core, the answer is no.
Copy the four-question filter into a note you can access while working. Every time you're tempted to add something new, run it through the filter before touching your project files. If it fails any question, it goes to the parking lot — immediately, without negotiation. The filter is your policy; you're not deciding each time, you're following the policy you already decided on.
You're going to bring three actual feature ideas for your project (or a sample project) and run each one through the four-question filter with your AI lab partner. The AI will ask you the questions in sequence and make you answer them — not give you a pass just because the feature sounds good. At the end, it will give you a clear in/park/cut verdict for each feature.
This lab works best if your features are ones you genuinely feel torn about — features you want to add but aren't sure you should. Easy yes or easy no features aren't interesting. Bring the hard ones.
Priya had been working on her project for four months. It had started as a tool to help nursing students create flashcard sets from their lecture PDFs. It was now, according to her Notion doc, a "comprehensive AI-powered learning platform for healthcare professionals featuring spaced repetition, progress analytics, peer study groups, a curated resource library, and integrations with three major medical reference databases."
Thirty percent of it worked. None of it worked end-to-end. She had impressive partial implementations of eight different features and zero deployable product. A classmate had launched a dead-simple Anki deck generator in November and already had 200 nursing students using it. Priya's project had more features in the README than users.
What she was about to do — what a lot of people do at this point — was keep building forward, hoping that finishing the next feature would somehow make the whole thing coherent. It wouldn't. What she actually needed was a different kind of session with her AI: not a building session, but a triage session.
A triage session is a deliberate, structured conversation with an AI — and yourself — designed to do one thing: find the smallest shippable thing hiding inside your over-built project. It's not about cutting features because you've failed. It's about recognizing that your actual product is probably already built; it's just buried under the features you added around it.
The triage session has four steps, and you need to be brutally honest with yourself at each one. The AI can facilitate, but you have to be the one making the calls.
When she ran the triage, Priya found that steps 1 and 2 of her PDF-to-flashcard pipeline worked end-to-end. She had a tool that could extract key terms from a nursing PDF and generate flashcard text. It wasn't beautiful. It had no spaced repetition, no analytics, no peer groups. But it did the core thing. She shipped it in a weekend. Fourteen nursing students used it the first week.
Here's the psychological block that stops most people from doing triage: you've spent time building things. AI made that time feel productive. The peer study group module took you a week. Throwing it into an archive folder feels like wasting that week. This is the sunk cost fallacy, and it's particularly vicious in AI-assisted projects because the AI made building feel easy and fast — which means you've built even more, which means there's even more to feel guilty about cutting.
The reframe that actually works: the work you did was research, not construction. You learned what the integration would require. You learned how complex the analytics would be. That learning is valuable even if the code never ships. You're not wasting it by parking the code — you're banking it for when you're ready to build v2 with real user feedback informing the design.
A lot of people your age are dealing with this right now — friends who started building something ambitious with AI in fall 2023 and are now sitting on a massive half-built project they can't ship and can't abandon. The triage approach is the way out of that specific trap.
Triage gets you back to a shippable state. But without structural changes to how you work, scope creep will return. The prevention after triage is different from the prevention at project start — you've already seen what your particular flavor of scope creep looks like, so you can target it specifically.
After triage, implement a weekly scope review: every Sunday (or whatever works for your schedule), spend fifteen minutes comparing your current to-do list against your DoD and MVB. Ask: has anything been added this week that's outside the container? If yes, move it immediately. Don't let the new additions accumulate — that's how you end up in triage again in three months.
Use your AI sessions differently post-triage. Before each session, state explicitly: "Last week I completed [X]. This week my goal is [Y]. My MVB is [Z]. Help me stay focused on Y and call me out if I drift." This is an accountability structure, and it works precisely because it gives the AI a specific behavior to watch for rather than a general instruction to be helpful.
If you have an over-built project sitting unshipped right now, schedule a two-hour triage session this week. Use the four steps: map what works, identify your core promise, match them, archive the rest. Set a ship date that's within two weeks of the triage session — not two months. The goal is to break the non-shipping pattern with a real deployment, however small.
There's something that happens when you actually ship something — even something small and imperfect — that no amount of building can replicate. You stop being a person who's building something and become a person who's built something. That shift in identity matters more than it sounds.
From a portfolio perspective, a deployed tool with 50 users tells a more compelling story than an elaborate GitHub repo with no deployment history. From a learning perspective, the feedback from those 50 users will do more to improve your next version than any amount of AI-assisted planning. And from a motivation perspective, seeing real people use something you made is the kind of reward that sustains work over time in a way that brainstorming sessions simply don't.
Scope creep, at its root, is often a form of avoidance. Building feels productive and safe. Shipping is exposure — someone might not like it, might not use it, might tell you the core premise was wrong. AI makes building so comfortable that it's easy to stay there indefinitely. Don't. The discomfort of shipping is where all the real learning lives.
This is the most direct lab in the module. You're going to describe where your project currently stands — what's built, what works, what doesn't, and what the original idea was — and your AI lab partner will run you through the four triage steps: map what works, identify core promise, match them, and archive the rest.
If you don't have an over-built project, describe a hypothetical one or use a project you know about. The AI needs real details to do this well — vague descriptions produce vague triage. Bring the actual state of something.
At the end, the AI will ask you to commit to a specific ship date out loud. That's the point of the lab.