The 48-hour scope: how to quote a web project without padding

A fixed-price web project quote in 48 hours sounds like a setup for padding — quote high, hide the buffer, hope you guessed right. That's how most agencies do it, and it's why clients have learned to distrust fixed prices. I've scoped and fixed-priced dozens of projects over roughly 19 years, and the trick is the opposite of padding: do enough discovery up front that almost nothing is left to guess. The estimate stops being a gamble wrapped in margin and becomes arithmetic on a scope both sides actually understand. When I can't get there in 48 hours, I don't pad — I tell you the project needs paid discovery first, and I explain exactly why.

This is the process I use to scope a web project fast and price it honestly, whether it's a marketing site, a headless commerce build, or an internal tool.

Why a fixed price is safer for both sides

The standard advice is "always bill time-and-materials, fixed price is a trap." That's true when scoping is lazy. It's backwards when scoping is done right.

Under time-and-materials, the client carries all the risk. Every estimate I miss, every rabbit hole, every "while we're in here" — they pay for it. They have no ceiling and no way to plan cash flow. My incentive is quietly to go slower.

Under a real fixed price, I carry the risk of my own efficiency, and the client gets a number they can take to a board, a co-founder, or a bank. My incentive flips: finish clean, finish early. The catch is the phrase "done right." A fixed price on a vague scope is just me transferring my uncertainty onto your invoice as a fat buffer. A fixed price on a precise scope is a fair trade — I eat the variance in exchange for charging a confident, un-padded number.

So the whole game is moving uncertainty out of the price and into the discovery. That's what the 48 hours is for.

The discovery questions that remove the guessing

Padding comes from unknowns. Kill the unknowns and the padding has nowhere to hide. I run a 45–60 minute call, then a short written follow-up. These are the questions that do the most work.

What exactly are we replacing or competing with?

"Build us a site like X" tells me more than three paragraphs of requirements. If you point at a reference, I can scope the real surface area in minutes — page types, interaction patterns, content volume. When Trivandi came to me, the reference plus their content model made a Next.js + Sanity build trivially scopeable. No reference means we're designing in the dark, and that's a different, longer conversation.

Who owns the content, and what shape is it in?

This is the question that silently doubles timelines. A content-driven site lives or dies on the CMS model and who fills it. I need to know how many page templates, how many languages, who writes the copy, and whether the content exists yet. Bilingual content alone — the kind I model with field-level localization in Sanity — reshapes the schema, the QA matrix, and the launch date. If the answer is "we'll write it during the build," that's a flag, not a detail.

What has to integrate, and do those systems already work?

Payments, auth, a PIM, an ERP, a CRM, an inventory feed. Integrations are where fixed prices go to die, because the unknown isn't my code — it's the quality of the system on the other end. For commerce work, I ask whether you're on Shopify Hydrogen or want owned Medusa infrastructure, because that single answer reshapes the estimate. On the NIO regional EV platform the configurator-to-checkout flow touched several systems, and I priced the integration risk explicitly instead of burying it.

What's the real definition of "done"?

Is done launch? Done plus a month of post-launch fixes? Done including SEO, analytics, and a CMS handover so your team is self-sufficient? Each interpretation is a different number. I make the client say it out loud, then I write it down, because "done" is the single most expensive word in any proposal.

Who decides, and how fast?

A project with one decision-maker who answers in a day ships at a different price than one with a committee that meets fortnightly. Decision latency is a real cost. I don't pad for it silently — I name it, and I put review SLAs in the proposal.

Red flags that mean the project needs more discovery, not a quote

Sometimes 48 hours isn't enough, and the honest move is to say so. These are the signals that tell me to propose a paid discovery sprint instead of a fixed price:

• The scope is described in outcomes, not features. "We want to dominate our market" is a goal, not a spec. I can fixed-price features; I can't fixed-price ambition.
• Nobody can name the integrations. If "it needs to talk to our systems" can't be turned into a list of named systems with documentation, the unknown is too big to price.
• The requirements arrive as a 40-page PDF nobody will defend. Long documents feel safe and usually hide contradictions. I'd rather have a one-page brief and a sharp 60-minute call.
• The data model is genuinely novel. Most sites are variations on patterns I've shipped. When the core domain is actually new — a pricing engine, a matching algorithm, a mobile app with offline sync like PropertyCheck — I spike it before I price it.
• AI is in the brief but the use case isn't. "Add AI" is not a scope. I've shipped AI features clients actually use with the Vercel AI SDK, and the ones that worked started from a specific job, not the technology.

Proposing discovery here isn't losing the deal. It's the cheapest insurance both of us will ever buy. A few paid days routinely turn a project I'd have padded by 40% into one I can quote tight.

How I structure the proposal

Once discovery is done, the proposal almost writes itself. I keep it to a few pages and a fixed shape.

1. Scope as a list of what's included — and a matching list of what's not. The exclusions are the most valuable part. They're where scope creep gets stopped before it starts. "Three-language content entry" sits next to "translation copy supplied by client."
2. A fixed price, in phases. I break the work into milestones with their own deliverables and payments. Phasing lets the client start without committing the whole budget, and it gives both of us a clean checkpoint. For a headless commerce build that might be foundation and CMS, then catalogue and product pages, then checkout and integrations, then launch.
3. The stack, named and justified. I tell you what I'm building on and why — React and Next.js for an app, Laravel for a content-heavy backend, Umbraco where the client's team already lives in it like Emarat. No mystery, no lock-in by obscurity.
4. What changes the price. A short, explicit change-request clause. New scope is welcome — it's just a new line item, priced the same honest way. This is what lets a fixed price survive contact with reality.
5. A timeline with the client's homework on it. The dates depend on content and reviews arriving on time, so those dependencies live in the timeline, not the fine print.

That's it. Nothing left to pad — the unknowns got resolved in discovery, the exclusions cap the surface area, and the change clause handles whatever I genuinely couldn't foresee.

What a fixed price actually promises

A fixed price isn't a magic trick or a sales tactic. It's a promise I can only make after I've removed enough uncertainty to keep it. The 48 hours buys a confident number; the discovery behind it is what makes the number fair. If a project is too fuzzy to scope honestly in two days, I'll tell you that too — and we'll spend a few paid days making it scopeable, which is cheaper than the padding you'd otherwise pay without knowing it.

If you're choosing between a fractional CTO and an agency, and one of them quotes a big round number an hour after the call, ask which unknowns they resolved to get there. The answer tells you everything.