Never Let a Developer Name the Scope

The Word That Cost Founders Everything

I was on a coaching call with a developer team working on a SaaS product - a chatbot builder we're building to compete with tools like Chatbase. We're mid-build. Things are working, mostly. And one of the guys on the call opens with something like: "We came to a conclusion that what we built so far needs a revamp."

I let it hang there for a second.

Then I asked: what does that mean, exactly? Because when a developer says "revamp," they are not describing a task. They're describing a feeling. And feelings don't have a price tag. Feelings don't have a deadline. Feelings will drain your runway if you let them steer the meeting.

This is the thing most founders never figure out until they've burned through a development budget on something they never agreed to build: scope is a language problem before it's a planning problem. And the person least qualified to set the language is usually the person most confident doing it - your developer.

What "Revamp" Actually Means (And Why It's Dangerous)

Let me be clear - I'm not saying developers are trying to rip you off. They're not. In most cases, they genuinely believe they're giving you useful information when they say words like "revamp," "overhaul," "refactor," or "rethink." The problem is that these words exist in a completely different dialect than the one founders operate in.

When a developer says "revamp," they mean: something is wrong and fixing it will require significant effort. What a founder hears - or, more accurately, what a founder unconsciously agrees to - is: we are starting over, the clock resets, the budget expands, and we'll talk about what we built in a few months.

Those are two wildly different things.

The developer isn't lying. They're just speaking in a dialect that maps poorly to business decisions. And when you, the founder, nod along and say "yeah, okay, let's do a revamp" - you have just made a budget decision without knowing it. You've authorized something with no scope, no timeline, no deliverable list, and no definition of done.

That's how you end up in month seven of a three-month build wondering why nothing ships.

What I Did Instead

When the developer said "revamp," I didn't argue with it. I didn't say "no we're not doing a revamp." I just replaced it. Immediately. With tasks.

Here's what the actual conversation looked like:

I pulled up Chatbase - the competitor we're benchmarking against - and I started clicking around on a live call. I said: look, go to Chatbase.co and look at how their chat widget handles responsive mobile. When you click the input field, the message box pops to the top and the whole chatbot scrolls up. Full screen. Nothing above it, nothing below it. Now look at ours. There's extra space at the top. When you click to type, you still see dead space and you lose the context window. That is the bug. That specific thing. Not a "revamp."

And then I listed the actual atomic tasks:

• Do a side-by-side UI comparison between our chatbot and Chatbase - document every visual difference in a Notion file
• Fix the responsive layout so it's full screen with no extra space
• Fix the line break bug - messages sent as paragraphs on the feed side are rendering as one block on the user side
• Fix the initial question trigger - the "tell me about your business" prompt isn't firing the follow-up question correctly
• Auto-generate the suggested prompts using AI instead of using static hardcoded questions - we'll write a prompt so the bot generates 5-6 word suggestions based on the conversation context
• Create an Advanced Features tab in the chatbot dashboard where we can toggle experimental features on and off with checkboxes - and each checkbox needs a flag in the database so the system knows which features are active per chatbot ID

None of that is a revamp. That is six tasks. Some of them are probably a few hours each. Some might be a day. But they're all specific, they're all testable, and they all have a clear definition of done that does not require a single philosophy conversation.

That's the whole move. You kill the vague word and replace it with a numbered list before the meeting ends.

The Taxonomy of Vague Scope Words (And What to Replace Them With)

In my experience building and selling multiple SaaS products, there are a handful of words that should trigger an immediate translation reflex in your brain. Whenever a developer or contractor uses one of these, your job - before the conversation goes one sentence further - is to ask: what does that look like as a list of tasks?

Here's the hit list:

• "Revamp" → Which screens? Which behaviors? What does done look like?
• "Overhaul" → Which components are being replaced? What's staying?
• "Refactor" → Which files? What's the before and after for the end user?
• "Rethink" → What specifically isn't working? What user action is broken?
• "Clean it up" → List the specific things that are dirty.
• "It needs work" → What kind of work? How many hours? Which features are affected?

This isn't pedantry. This is money. Every vague word you let slide is an open-ended authorization. You are signing a blank check every time you nod along to language like this without converting it into tasks.

Scope Is Also a Technical Debt Conversation - And You Need to Know the Difference

Here's where it gets a little more nuanced, and I want to be honest about it because on this particular call, the dev team actually surfaced something real.

They explained that our chatbot builder was generating two separate files - a CSS file and a JS file - every time a new chatbot was created. Chatbase generates one file. That extra file is adding load time every time somebody deploys a widget. That's a real problem. It's not cosmetic. It's an architectural inefficiency that compounds over time as users scale.

But - and this is the key thing - they framed it correctly. They didn't say "we need to refactor the file generation system." They said: here's what's happening, here's the impact, here's what the fix looks like (merge CSS and JS into one file), and here's what the user experiences differently as a result (faster load time, no CSS delay on deploy).

That's the standard. I don't care if something is technically complex behind the scenes. I care whether the person asking me to authorize the work can describe:

1. What is currently broken or inefficient
2. What the fix actually changes for the end user or system
3. What done looks like

If they can answer those three things, you're not dealing with vague scope anymore. You're dealing with a real task that deserves a real conversation. If they can't answer all three, the task isn't ready to be discussed - let alone built.

The One-URL Rule

On this call, something else happened that I want to highlight because it's the cleanest version of the technique.

When the developer tried to explain the UI problems, we weren't aligned. Different people in the call had different mental models of what needed to change. So instead of talking about it abstractly, I said: open Chatbase.co - not Chatbase.com, the right one - and go to the chatbot widget. Watch what happens when you click the input field.

One URL. One live product. One comparison. Everything else in the meeting flowed from that single reference point.

This is the one-URL rule: when you're debating scope on a software product, find the competitor or reference product that does the thing you're trying to do, and use that as the living specification document. Stop arguing about what "full screen" means in the abstract. Go look at the product that already does it. Then your job is to list every visible difference between that product and yours.

You don't need a 40-page PRD. You need a Notion doc with a side-by-side comparison and a numbered list of gaps. That's your scope document. That's your definition of done. Anyone on your team can see it. Anyone can test against it. And it is extremely hard to expand into a "revamp" when you're working off a pixel-by-pixel diff of two live products.

Credits, Checkboxes, and Keeping Advanced Features Off the Critical Path

The other thing we worked through on this call was how to handle advanced features without blowing up the core product build.

We're adding a feature where the chatbot auto-generates suggested prompts based on the conversation context - so instead of static hardcoded questions sitting at the bottom of the widget, the AI generates five or six short, relevant suggestions dynamically. It makes the whole interface feel more intelligent and more interactive.

The problem is that this feature costs more compute. Every time those suggestions generate, it burns more AI credits than a standard response. And we're building a credit-based system. So if we just ship this feature and users unknowingly turn it on, they're going to burn through their credits faster than expected and come back pissed.

The solution is a checkbox. One toggle in an "Advanced Features" tab in the dashboard. Users opt in. They see clearly that enabling this feature increases their credit consumption. They make an informed decision. We store that preference as a boolean flag in the database against the chatbot ID, and the system references that flag every time the chatbot loads.

Simple. No drama. The feature ships without breaking anything else.

But here's the broader principle: advanced features should never live on the same timeline as bug fixes. When you mix them, everything slows down. The bug fixes feel less urgent because "we're working on the big feature anyway." The big feature bleeds scope because "while we're in there we might as well..." Keep them separated. Bug fixes are their own sprint. New features are their own scope conversation. Advanced features get a checkbox and an opt-in. That's the hygiene.

What This Looks Like When You Get It Right

By the end of this call, we had a clear output. Not a roadmap. Not a vision document. A task list.

Someone was going to put together a Notion file comparing our chatbot UI to Chatbase's - screen by screen, behavior by behavior - and share it with the team. That doc becomes the scope. Every item in it is a specific, testable change. The dev team wasn't being asked to "revamp" anything. They were being asked to close a list of specific gaps against a known reference point.

That's a completely different psychological contract. When you hand a developer a list of ten specific tasks, they can estimate it, ship it, and mark it done. When you hand them a vague directive like "clean up the UI" or "revamp the front end," you've handed them an open-ended project with no finish line. You will be talking about that project for a very long time.

The timeline question came up at the end of the call: do we have a timeline for the UI changes? And the answer was: we're scoping it tomorrow, building a list of everything that needs to be included, finding a template. That's the right answer. Not a date pulled from thin air, but a commitment to define the work first, then estimate it.

That's the sequence. Define. Estimate. Build. In that order. Not the other way around.

This Applies Beyond Software

I've written about this in the context of agency work too. The same trap exists in any project-based business. A client says they want a "brand refresh." An agency says they can help with a "website overhaul." A consultant proposes a "strategic rethink."

Nobody has defined anything. Everyone is nodding. And six weeks later you're in a scope dispute that poisons the client relationship.

The fix is always the same: convert the vague word into a task list before anyone agrees to anything. What does "brand refresh" mean as a deliverable list? New logo? New color palette? Updated deck template? Those are three different price points. Pick which ones you're including, document it, get the client to sign off on the list - not the word.

If you want my exact process for running the discovery conversation that pulls this out of a client before it becomes a problem, I put together a Discovery Call Framework that walks through exactly how to structure that first call so scope is locked before anyone does any work. It's free, it's fast, and it will save you from having the worst conversation in client management - the one where you argue over what you agreed to three months ago.

The Bottom Line

Developers are not your enemy. They're just speaking a different dialect. When they say "revamp," they're not trying to blow your budget - they're flagging that something needs significant attention and they don't yet know how to quantify it.

Your job, as the founder, is to be the translator. Every vague scope word that comes out of a dev meeting needs to be converted into a numbered list of atomic tasks before that meeting ends. One URL as a reference product. Three questions: what's broken, what does the fix change, what does done look like.

Do that consistently, and you will ship faster, spend less, and have a team that actually knows what they're building. Let the vague words stand, and you'll spend the next quarter talking about the same "revamp" that never quite finishes.

Kill the word. Build the list. Ship the thing.

If you want to work through your current build scope - or any part of your sales system, outbound strategy, or business model - that's exactly what we do inside Galadon Gold. Live calls, real feedback, no theory. Check it out.

And if you're running outbound to find your early users or SaaS customers while you're building, don't neglect the pipeline. I built ScraperCity specifically for this - unlimited B2B lead data and scrapers so you can build a real prospect list while your product is still in development. You don't need a finished product to start booking sales calls. You just need a clear offer and a list. We cover the lead strategy side of that here.