When Your AI Says One Thing and We Say Another

“I asked ChatGPT and it said this should take about a week.”

An AI software estimate turns up in our inbox more often now, and I want to be clear up front that it’s a completely fair thing to do. If you’re about to spend real money on something you can’t personally evaluate, getting a second opinion from a tool that answers instantly and doesn’t want your business is a sensible instinct. I’d probably do the same.

The awkward part is what happens next, when the answer you were given and the answer we give you don’t match, and you’re left in the middle trying to work out which one is the sales pitch. So it’s worth explaining, honestly, what’s actually going on when those two numbers diverge, because the reason is more interesting than “one of us is wrong.”

Why the AI’s answer sounds so reasonable

Because it usually is reasonable. That’s the thing worth understanding first.

Ask an AI how long it takes to build a customer login, a booking form, a product catalogue, and it will give you a well-informed answer about how long that thing takes to build in general. It has read an enormous amount of writing about software. The number it produces is a decent reflection of the typical case, described in tutorials, documentation and blog posts, built from scratch, by someone competent, with nothing in the way.

That’s a real answer to a real question. It just isn’t quite your question. Your question has a “for us” on the end of it, and everything expensive tends to live in that part of the sentence.

What an AI software estimate doesn’t know about you

It doesn’t know what you already have. That’s the short version, and it accounts for most of the gap.

A login system takes a week if you’re starting fresh. It takes considerably longer if it has to work with the twelve thousand customer accounts you already hold, half of which have duplicate email addresses from the platform migration in 2021, and it has to keep working for the people mid-way through a subscription, and it has to hand a session across to the booking system you bought separately, which authenticates its own way and can’t be changed because it’s a hosted product.

None of that is in the question you asked, because you had no particular reason to think it mattered. It isn’t a failure of the AI, and it isn’t a failure of yours. It’s just that the estimate was produced for a clean version of your problem that doesn’t exist anywhere except in the question.

The same gap shows up in a handful of predictable places:

The systems the new thing has to live alongside, and what those systems will and won’t allow. The data you already hold, and the state it’s actually in. Who has to be able to use the result, on what devices, at what volume. What happens when it fails, which nobody asks about until it does. Whether anyone needs to be able to run it afterwards without calling us. And the deeply unglamorous work of getting something from “it works on a developer’s machine” to “it’s live, monitored, backed up, and a real customer just used it at eleven at night.”

Is the AI ever the one that’s right?

Yes, and this part matters more than the rest of the article.

Sometimes you’ll bring us an AI answer that says there’s a simpler way to do what you’ve asked for, and it will be correct. It happens. A team can get attached to an approach, or carry a habit from the last project into this one, or quote for a custom build of something a well-chosen off-the-shelf product would handle for a fraction of the money. An outside answer with no stake in the outcome is a genuinely useful check on that, and a development partner who bristles at being asked to justify an approach is telling you something about themselves.

What you should get, when you raise it, is a specific reason. Not “AI doesn’t understand real development.” That’s an evasion. A real answer sounds like: “That’s right for a fresh build, and the reason it doesn’t apply here is that your stock data only updates overnight, so the live inventory approach it’s describing would show customers availability that’s up to a day out of date.” You may not be able to judge the technical claim. You can absolutely judge whether you were given one.

How to tell which answer to trust

You don’t need to become technical to work this out. A few questions do most of the job.

Ask what the AI software estimate assumes. Every number rests on assumptions. Ask both sources to state theirs. An AI will happily tell you it assumed a greenfield build with no existing data and no third-party constraints, which is often the moment the gap explains itself.

Feed your specifics back in. Go back to the AI and add the awkward details: the legacy accounts, the system that can’t change, the fact that this has to run during a sale weekend. The estimate usually moves, sometimes a long way. If it moves toward ours, that’s informative. If it doesn’t, bring that back to us, because now there’s a real disagreement worth having.

Ask what would have to be true for the cheap answer to be right. This is the most useful question in the set. It turns an argument about a number into a checkable list of conditions. Sometimes we look at that list and find that two of the five are actually true, and the job gets smaller. That’s a good outcome for everyone.

Notice who’s engaging with the specifics. The side dealing in your actual constraints is usually the side worth listening to, whichever side that turns out to be.

Bring us the transcript

Genuinely. Not as a challenge, and you don’t need to frame it apologetically either. A conversation you’ve had with an AI about your project is one of the more useful things you can walk in with, because it’s a record of what you were curious about, what you assumed, and where your thinking got to before anyone started charging you for it.

It makes a good agenda. It surfaces the options worth ruling in or out, it shows us the version of the project in your head, and it means the early conversation starts several steps further along than it otherwise would.

The tools are good, and they’re getting better, and pretending otherwise would be a strange position for a software company to take. What they can’t do yet is walk through your building, look at what’s behind your walls, and tell you what it’ll take to work with what’s already there. That part still needs someone to come and look.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He’d rather be asked to justify an estimate than have a client quietly wonder about it for six weeks. Reach out to Simon to talk through what your project actually involves.