The message came in with a number attached that made me reread it twice. A full SaaS build, a real budget, a client who seemed to already know exactly what they wanted. Every instinct said say yes immediately before they change their mind.
I turned it down two weeks later, after the initial excitement wore off enough to actually see what I'd been ignoring.
The Project That Looked Perfect on Paper
Everything about the opening conversation checked the boxes that usually matter. Clear budget, stated upfront, well above my usual range. A timeline that sounded reasonable. A client who spoke like someone who'd hired developers before and knew roughly what they were asking for.
I said yes to an initial call almost immediately. The excitement of a project at that size is real, and it's easy to let that excitement do the thinking that should actually be happening more carefully.
The First Signs I Talked Myself Out of Noticing
The scope shifted three times before the first call even happened, each time getting bigger, with no acknowledgment that a bigger scope might mean a different number. I told myself this was just normal early-stage planning, not a pattern.
The client mentioned, almost in passing, that the last two developers they'd worked with "didn't work out." No specifics offered, and I didn't ask for any. In hindsight, that's one of the clearest things a potential client can tell you, and one of the easiest things to let slide past when there's a big number attached to the conversation.
Every question I asked about the actual business the SaaS was meant to serve got a vague answer that circled back to features instead. Not a problem being solved for real users, a growing list of features that sounded impressive in a pitch deck.
What Actually Made Me Walk Away
The moment that clarified everything was a single sentence, dropped casually near the end of a call: "We'll figure out the exact scope as we go, I trust you to just build what makes sense."
That sentence sounds like trust. It's actually the opposite of a scope. A client who cannot describe what they specifically need, however large the budget, is not handing you flexibility, they're handing you an undefined amount of work with a fixed price attached, and eventually a disagreement about what "makes sense" was supposed to mean.
Combined with the shifting scope before we'd even started and the vague answer about previous developers, the pattern became impossible to keep explaining away. This wasn't a big opportunity with some rough edges. It was a project heading toward exactly the kind of dispute that ends with unpaid work and a bad review, regardless of how skilled the work itself turned out to be.
What It Actually Taught Me
A big number is not the same as a good project. It's easy to let budget size override every other signal, since budget is the easiest thing to evaluate quickly, and the other signals take actual attention to notice. The size of a number says nothing about whether the underlying project is well-defined, well-intentioned, or realistic.
"Trust you to figure it out" is not flexibility, it's a missing scope wearing a compliment. Genuine trust from a client shows up as clear communication and reasonable boundaries, not an open-ended request dressed up as confidence in you.
A history of "developers who didn't work out" deserves a real follow-up question, not a polite nod. Sometimes there's a genuinely reasonable explanation. Often there isn't, and the only way to know is actually asking, not assuming the best case because you want the project to work out.
Walking away from money now can protect a lot more money later. The actual cost of a bad-fit project isn't just the stress during it, it's the unpaid disputed hours, the bad review that follows you afterward, and the months of energy that could have gone toward better-fit clients instead.
What I Do Differently Now
Every serious inquiry, regardless of budget size, gets the same real questions before any scope discussion starts. What specific problem is this solving, for whom, and how will you know it worked. Vague or evasive answers to those three questions are worth taking seriously now, not explaining away because the number attached looked good.
A scope document happens before a number gets agreed on, not after, and "we'll figure it out as we go" is now a direct conversation starter, not something I let pass by quietly. If a client can't get more specific than that after being asked directly, that's information, not an inconvenience to work around.
The Uncomfortable Truth About This
Saying no to that project felt genuinely hard in the moment. It's much easier to write a story afterward about how it was obviously the right call than it was to actually turn down real money based on a feeling that something was off, backed by evidence I had been quietly ignoring for two weeks.
The projects that actually go well rarely need this kind of internal debate. The client is specific, the scope is real, and the conversation feels straightforward from the start. When it doesn't feel that way, the budget size is usually the thing making it hardest to trust that discomfort.
If you're weighing a project that has a great number attached and a feeling you can't quite explain, that feeling is usually worth more attention than the number is.
Get in touch: https://pixelanas.com/contact
Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751