A client came to us expecting a $40,000 build and we came back with a $147k estimate. No, we weren’t padding the invoice. The original estimate was just wrong, terribly wrong. It was the kind of wrong that kills projects halfway through, torches client relationships, and leaves agencies absorbing costs they never should have touched.
I’ve been scoping projects and building software projects for over 25 years, and I still regularly catch myself underestimating complexity. What separates the agencies that survive from the ones that slowly bleed out is how they handle the gap between expectation and reality for clients.
This is the full story of how we navigated a 3x estimate correction, kept the relationship intact, built a process that stops this kind of surprise from happening again, and even made a sale.
If you’ve ever sweated through a scope conversation where the numbers didn’t add up, this one’s for you.
A “Simple” Project That Wasn’t
The project landed on my desk looking manageable. The client needed a system built. Multiple integrations, a lot of custom logic, a user-facing portal. Standard stuff on the surface. Then I started digging. I said something to Michelle during our team meeting that pretty much summed it up:
The user concurrency is huge.
What looked like a straightforward build had layers. Authentication systems, role-based access, third-party API connections, data migration from legacy platforms, custom reporting dashboards, but the big killer was the user concurrency – 10k+ simultaneous users. Each “feature” on the client’s wish list was actually 3 to 5 times more complex due to the concurrency issue.
The original ballpark? Somewhere around $40,000 to $50,000. Not always. That number had been floating around based on early conversations before anyone had done real discovery work. Generous interpretation: it was an optimistic placeholder. Honest interpretation: it was a guess.
We needed to fix that. Fast.
Why Estimates Go Sideways
Before I walk through what we did, let’s talk about why this keeps happening, because if you’re running an agency or managing projects, you’ve probably been here. Maybe you’re here right now?
Most estimates fall apart for one of three reasons:
- Surface-level scoping. Someone hears “build me a portal” and prices a portal without asking what it actually does, who uses it, what systems it connects to, or what happens when things break.
- Anchoring to client budget instead of actual work. The client mentions they’ve got $50K, and the estimate magically lands at $48,000. That’s not estimating. That’s wish fulfillment.
- Skipping the boring parts. Nobody forgets to estimate the flashy features. They forget about error handling, testing, deployment pipelines, documentation, admin tools, and the 47 edge cases that eat 25% of development time.
In our case, it was mostly reason number one. Early conversations had been high-level and nobody had cracked open the hood yet. Once we did, the engine was a lot bigger than the car suggested.
To be fair, but here’s the thing most agencies will not admit. Sometimes you don’t know what you don’t know until you start doing the work. That is not incompetence, that’s the nature of building custom software. The trick is having a process that catches the gap before it becomes a disaster.
PERT Pricing and Straightforward Breakdowns
So we had a problem. Client expecting roughly $50K. Actual scope closer to $150K. How do you bridge that gap without the client feeling ambushed?
Step one: PERT pricing (I think it’s technically PERT estimation, but in our case it’s the same thing).
If you’re not familiar, PERT stands for Program Evaluation and Review Technique. (Sounds fancy. It’s actually just simple math.) Here’s how it works:
For each task, you estimate three numbers: – Optimistic time (everything goes perfectly, no surprises) – Most likely time (realistic scenario based on experience) – Pessimistic time (everything that can go wrong does). We call it min, max, most likely.
Then you weight them: (Optimistic + 4x Most Likely + Pessimistic) / 6 = Expected Duration
This gives you a number grounded in reality rather than hope. And it gives the client a range they can actually understand. “Best case it takes 20 hours, worst case 45, most likely around 30” is a lot more honest than “it’ll take 30 hours.” Same number in the middle, completely different level of trust. Worth repeating. Every time we do an estimate we run every single line item through this formula. Every single time.
Step two: Break the estimate into components that the client can understand.
This is where a lot of teams drop the ball. They hand over a single number, maybe with a few line items, and expect the client to just nod. That’s not how business people work though, especially not people who are about to spend $147,000.
As usual, we built the estimate as a detailed breakdown. Not just “Frontend Development: $45,000” but specific features, specific integrations, each with their own PERT range. And as usual, the client could see exactly where every dollar was going.
Step three: Present the estimate as a conversation, not a document.
Put simply, we don’t email PDF and wait, at least not on big items like this. We walk through it live. Every section, every assumption, every risk. We also give the client room to push back, ask questions, and prioritize.
Usually, think about it, and they appreciate it, even if it really is outside of their budget.
The Resource Allocation Problem (A Parallel Lesson)
Stefan, one of our Strategists and Account Managers, was working with a different client who had limited monthly hours, and two competing priorities landed at the same time. Broken links needed fixing across the site, and the client had a new offering that needed messaging work. Both mattered and both couldn’t happen in the same month with the hours available.
Stefan handled it perfectly. He went to the client and laid it out plainly:
We’ve these two topics which are pretty central. Which one do you want to handle this month?
No assumptions. No deciding for the client. No trying to squeeze both into a timeline that was never going to work, just a clear, honest question. Then he offered flexibility:
If there’s stuff that’s more urgent, maybe we could consider me doing some of that next month instead.
This is the same muscle you use in big estimates – transparency about constraints, combined with options the client controls. Whether you’re talking about a $147,000 build or a 10-hour monthly retainer, the principle is the same.
It’s also worth noting: you’re not the one who should be deciding what matters most to the client’s business. You’re the one who should be giving them the information they need to make that call themselves.
What Worked And What I’d Do Differently This time
What Worked
As usual, PERT pricing eliminated the guesswork. Instead of arguing about whether something would take 20 hours or 40, we had a method. Numbers backed by a formula are harder to dismiss than numbers backed by “trust me.”
The thing is, – Granular breakdowns built trust. The client could see we’d done our homework. Every line item showed we’d thought about their project more deeply than anyone else they’d talked to.
Honestly, walking through it live prevented sticker shock. When you present a $147K estimate in a conversation, you can read reactions, answer questions in real time, and provide context. An email with that number lands like a bomb. Giving the client control over priorities kept them engaged. Both with the big project and Stefan’s retainer client, letting the client choose what mattered most made them partners in the decision rather than victims of it.
What I’d Do Differently
- Deeper discovery earlier. The gap between $50K and $147K shouldn’t have existed. We should have run a paid discovery phase before any numbers were discussed. We do this often, but not for smaller companies that we know aren’t going to go for it. Besides, I like to give people some idea of about what they are looking at. A lot of people over the years have asked me “Is it 5k, 50k, or 500k? I just want to know what range I am looking at.” Which is a very fair question that I like to help people with if I can. In this case, I probably should have kept my mouth shut.
- Set expectations about estimate ranges from the very first conversation. Even before you scope anything, tell clients: “Our initial conversations will give us a rough range. Detailed estimates come after discovery. Fair point. They sometimes look very different from early guesses.” Planting that seed early makes the big number less jarring later.
- Build in a phased approach from the start. $147K is a lot of money. But $147K broken into three phases of $49K each? Suddenly, it’s a bit more digestible. Each phase delivers something working. The client can evaluate results before committing to the next phase. We did eventually structure it this way, but I wish we’d led with it.
How to Handle Complex Estimates
Here’s the process we now follow for any project over $50K.
- Ask about the complexity of the system and really go through the project with the client as soon as you can. If they don’t want to go deep, they are not going to be a good client.
- Try to understand how much the client really understands their own project. If they don’t know what they are doing and they want something really big, they also may not be a good client. It’s certainly not always the case, but it is more often than not.
- Offer a paid discovery – this is really the trick. Big clients with large projects understand the need to have a great plan and they are happy to pay you to create that plan for them. In many cases, they have to get a business case created to pitch the deal to their leadership anyway and you creating the plan is rock solid way for them to do it, as long as you are good at project planning.
- Go deep on the estimate and quote docs. Every feature, every email, every simple design and every complex application broken into 4-hour or less time blocks.
- Present large projects live (digital in our case) and go through each item. When a potential client sees blocks of 2 to 4 hours over and over and over and everything really does line up, it builds trust. And is should because you probably spent a ton of time figuring this stuff out.
- Take big projects slow – phase them in as needed to make sure you are a good fit for them and they are a good fit for you. Make sure that at every phase the client could technically walk away and use what you did with another shop. This process has landed and kept some of our biggest projects. These are deals that run into the millions of dollars.
- This isn’t an estimation piece, but I wanted to throw it in. Customers stick with us because we deliver, over and over and over again. We deliver because we have great project and product management. I could write a whole book on that as well, but I wanted to be sure to say it that great estimates start with great referrals and great referrals happen because you created great work to begin with. So always start there.
Oh, and that sale…
We didn’t actually get the $147k sale, it really was outside of budget for the client. The numbers just didn’t work for what they wanted to achieve. But we helped them understand their own issues which made them realize that maybe the direction they were going wasn’t going to work as well as they thought. At the end of the day though, they ended up buying our largest non-customized plan for SupportMy.Website, which they desperately needed to better drive revenue through their web and SEO channels. It is a great purchase for them and for us. In the end, everybody won this time!
I hope this was helpful. If you have questions, just ask!
