Five sentences that mean your software project is going to be late

Software projects rarely fail loudly. They slip, quietly, in ordinary-sounding conversations that nobody flags at the time.

These five sentences come up again and again. None of them means the team is bad. All of them mean the same underlying thing — the scope has not been settled — and every one of them is fixable on the day you hear it, and expensive to fix six weeks later.

1. "We'll start development next week"

Asked before anyone has written down what is being built, this means development will start next week on something, and the something will change.

Starting is not the milestone. Knowing what you are starting is the milestone. A team that begins building while the requirements are still moving is not saving time; it is buying the same screens twice.

What to ask instead: what exactly is being built in the first two weeks, and who signed off on it?

2. "That's a simple change, don't worry about it"

Sometimes true. Often it means nobody has checked.

"Let users log in with a phone number instead of email" sounds like a form field. It touches registration, password recovery, notifications, the admin panel, existing accounts, and whatever assumed an email address was available. That is not a simple change. It might still be the right change — but it needs estimating, not reassuring.

The danger is not the work. It is that undocumented "simple changes" accumulate, none of them get added to the timeline, and the deadline is missed for reasons nobody can point to.

What to ask instead: what does that touch, and how many days?

3. "We'll figure out the details as we go"

This is an open invoice with a friendly face.

Some discovery genuinely does happen during a build; that is normal. But there is a difference between refining details inside an agreed scope and deciding what the product is while building it. The first is engineering. The second is a project with no defined end, and no defined end means no meaningful estimate — of time or of money.

What to ask instead: which details, and when do we decide them?

4. "We can do it for half that"

Half the price is half of something. Ask what.

Usually it is testing, or documentation, or the second user role, or the edge cases, or the handover. Occasionally it is genuinely a leaner team with lower overheads, which is a real and legitimate answer. But it is always half of something, and the cheapest version of the question is asking now rather than finding out at launch.

Be especially careful when the low quote arrives without any questions attached. A quote produced without questions was not calculated. It was guessed.

What to ask instead: what is in the higher quote that isn't in yours?

5. "The whole team is dedicated to your project"

At a small agency, this is rarely literally true, and it does not need to be. What matters is who is actually on your project and how much of their week you have.

The problem is not shared teams. The problem is a vague answer, because a vague answer means you will not notice when your two developers quietly become one.

What to ask instead: which people, what percentage of their time, and who replaces them if someone leaves?

The pattern

Every one of these sentences is a scope question wearing a schedule costume. They all resolve the same way: write down what is being built, who it is for, what it connects to, and what happens when it changes.

That document is boring to produce and it is the difference between a project that ships and one that is still "nearly done" in month nine.