At some point in every project manager's life, someone will say the following sentence:
"I know there's no spec yet, but can you just give me a rough number?"
Understand what's happening here. You're not being asked for a rough number. You're being asked for the budget. Whatever you say next will be written down, forwarded to finance, quoted back to you in four months and engraved on the project's gravestone. The word "rough" will never be seen again. It never is.
So it's worth getting good at this, and the uncomfortable truth is that you can. Estimating without a spec isn't guesswork, provided you've built a few websites and paid attention while doing it. I say "paid attention" advisedly, because for the first few years of my career I built websites and paid attention to almost nothing.
A brief history of my incompetence
Early on, as a developer, I was inept at estimating. Not slightly off. Inept. And with hindsight I know exactly why.
First, I was an eternal optimist during every scoping phase. Green, naive, and cheerfully certain that this project would be the one where nothing went wrong. Every estimate I gave assumed the client would send content on time, sign off designs first go, and never once say "can we just". I estimated the project I wanted, not the one I was about to get.
Second, and more fundamentally: you can only estimate what you know. I knew how to build the homepage. I knew how to build a contact form. What I didn't know was everything that happens after you've built the homepage and the contact form, and it turns out that's where most of the project lives.
Every developer knows the cliché that the last 10% of a project takes about 50% of the effort. It's a cliché because it's true, and it's true because the last 10% is made of things nobody lists at the start. The redirects. The cookie banner. The 404 page. The form that works perfectly but sends its emails to an address nobody checks. The third round of "small tweaks". The content that arrives the day before launch in a Word document with tracked changes still on. None of those things were in my estimates, because I'd never been burned by them yet. Experience is mostly the process of getting burned by things in a sensible order.
Eventually, after enough burns, I found my fix, and it was not sophisticated. Whatever time I thought something would take, I doubled it. That's it. No formula, no framework, just an honest admission that my first instinct was reliably about half of reality. And it worked, remarkably well, for years.
I've handed that rule to developers I've mentored ever since, always with the same caveat: your mileage will vary. Doubling was my number because my optimism ran at roughly 50%. Yours might run at 30%, or 80%, or vary wildly depending on the type of work. The rule isn't "double everything". The rule is find your own magic number, by comparing what you estimated with what actually happened until the pattern shows itself. Everybody has one. Most people just never check.
Then there's the second multiplier, the one that took me longest to trust because it isn't a number at all: gut feel about the client. It matters most in the later phases of a project, feedback, sign-off, content, launch, which is precisely where the last 10% lives. And in my experience it usually comes down to two things. The first is their communication style: do they reply in hours or weeks, do they answer the question you asked, do they send feedback from one person or seven? The second, worded as politely as I can manage, is how "hands on" you think they'll be. Some clients want to see the finished thing. Others want to be involved in every decision, every shade of blue and every button label, right up to the evening before launch. Neither is wrong. But one of them costs noticeably more, and if your estimate pretends otherwise, the difference comes out of your evenings.
You can't put "client seems quite hands on" in a proposal. You can quietly adjust the later phases to allow for it.
The good news: you've built this before
Here's what experience eventually hands you, and it's the whole trick. Most website builds share 80 to 90% of the same requirements.
A homepage, some content pages, navigation, a CMS, forms, responsive layouts, SEO basics, analytics, cookie consent, accessibility, browser and device testing, hosting, launch, and a round of training so the client can break it themselves. The branding changes. The industry changes. The client absolutely insists they're unique. But underneath, the skeleton is almost always the same one.
Which means when there's no spec, you're not estimating from nothing. You're estimating from your last ten projects, and only the 10 to 20% that's genuinely different needs actual thought. That changes the job from fortune-telling to arithmetic, with a small section of fortune-telling at the end.
The method
- Start from a baseline, not a blank page. Keep a template estimate built from your real past projects, with every phase in it: discovery, design, build, content, QA, launch, post-launch. Use actuals, not what you quoted at the time. Those are two very different numbers, and only one of them is useful.
- Isolate the unknowns. Now find the 10 to 20% that's different. It's usually one of a familiar list: integrations with other systems, custom functionality, content migration from an old site, e-commerce, multiple languages, or a booking engine someone describes as "just a simple one". These get estimated separately, as ranges, because they're where the actual risk lives. A payment integration you've never touched is not a 50% chance of costing more. It's a near certainty, and the only question is how much.
- Make the last 10% a line item. This is the lesson younger me paid for in unpaid evenings. The tail of the project isn't a surprise, it's a known cost that turns up every single time, so budget it by name: redirects, legal pages, cookie consent, favicons, error pages, form notifications, feedback rounds, content wrangling, launch-day DNS, and the week after launch where everything is fine except the one thing that isn't. If it's in the estimate, it's work. If it isn't, it's an argument.
- Write your assumptions down. Every number in a no-spec estimate rests on an assumption, so list them. "Client provides all content." "Two rounds of design feedback." "Up to 15 page templates." "No integration with the booking system." That list is the spec you don't have yet. When reality changes an assumption, you're no longer arguing about whether the estimate was wrong, you're pointing at the line that changed. It's dull. It works. Dull things that work are the entire profession.
- Give a range, not a number. I've written about this properly elsewhere, so the short version: one number is a promise, a range is a forecast. "Between £40k and £55k, most likely around £45k, depending mostly on the integration" is honest, useful, and much harder to engrave on a gravestone.
- Estimate discovery first. When the unknowns are big, don't estimate the whole build at all. Estimate a short discovery phase, charge for it, and use it to write the spec that should have existed in the first place. Then estimate the build properly. Clients occasionally resist paying to find out what they want. It's worth explaining that the alternative is paying considerably more to find out later.
The first number you say out loud
One last rule, the most important and the hardest to follow: be careful with the first number you say out loud. It will be the only one anyone remembers. Qualifications evaporate on contact with a spreadsheet. If you genuinely can't give a range yet, the honest answer is "I'll give you a proper range by Thursday", which is less satisfying in the meeting and considerably more satisfying in month four.
Estimating without a spec isn't about being clever. It's about being boring on purpose: a baseline built from real projects, the unknowns separated and priced as ranges, the last 10% budgeted by name, and every assumption written where everyone can see it. The optimism can stay, it's quite a nice quality in a person. It just doesn't belong in the numbers.