TL;DR
- Estimate from a page inventory that separates layouts, content, integrations, QA and handover.
- Write the assumptions beside the number, and define what counts as a feedback round.
- Give a range only when the uncertainty is real, and keep a scope record so changes stay visible.
“Ten pages in Webflow” isn’t enough information for a reliable quote. Ten similar service pages can be straightforward. Ten different layouts with migrations, conditional forms and unfinished content can be a very different project.
I want an estimate to explain what the work includes and what would change it. A precise-looking number built on missing information is still a guess.
Count layouts and content separately
Start with a page inventory. Identify the unique layouts, the repeated pages and the CMS templates. Then count the content that needs entering or migrating.
A resource template might be built once, while 80 existing resources still need importing, checking and connecting to categories. Neither “one template” nor “80 pages” describes the effort on its own.
| Item | What to establish |
|---|---|
| Homepage | Final sections, interactions and responsive design |
| Service pages | Shared template or separate designs |
| Blog | Fields, authors, categories and archive size |
| Forms | Destinations, validation, consent and tracking |
| Migration | Existing URLs, assets, metadata and redirects |
| Handover | Editing tasks, access and training |
The inventory also exposes gaps. Error pages, thank-you pages and legal content still need a decision, even when they’re simple.
Identify the uncertain work
Some requirements can be estimated from the supplied design. Others need investigating first.
If a client asks for a “HubSpot integration”, ask what should happen to a submission. Is it an embedded form, a custom form sending through an API, a workflow with conditional fields or a booking connection? Who supplies the access? What counts as a successful test?
For an unfamiliar requirement, allow a small discovery task before quoting the full implementation. Testing one representative flow is usually cheaper than absorbing a surprise later.
Separate the work into stages
I normally distinguish setup, component development, page assembly, CMS work, integrations, QA and handover.
That isn’t an invitation to itemise every margin adjustment. It’s enough structure for the client to see what they’re buying, and for you to check whether an important stage is missing.
QA needs its own allowance. Responsive behaviour, long content, browser differences and real form delivery are part of the work. They shouldn’t depend on whatever time is left before launch. If a migration is involved, the Webflow migration service page lists the steps that usually need their own line.
Write assumptions next to the number
An estimate might assume final approved designs, client-supplied copy, one agreed CMS model and two consolidated rounds of feedback. Those assumptions need to be visible.
Define what a feedback round covers. Corrections to the agreed implementation belong in the delivery process. A new section or a changed content model may be additional scope. If every adjustment is called a revision, the boundary can’t be managed at all.
Also explain the dependencies. A two-week build can still miss its launch date if the client hasn’t supplied content or access. Separate working time from calendar time.
Use a range when the uncertainty is real
As an illustration, suppose an initial review suggests 40 to 55 hours. The lower end might assume clean content and one straightforward integration. The upper end might include manual cleanup and a more involved form flow.
Those are example figures, not a standard Webflow price. What matters is identifying what moves the estimate within the range.
If the unknowns are too large, give a discovery estimate and explain what that discovery will resolve. A wide range without reasons doesn’t help either side.
Make changes easy to discuss
Keep a short scope record. When a requirement changes, describe the extra work, its effect on the timeline and whether something else can come out to make room.
The client shouldn’t discover at invoicing that an ordinary-looking request had large consequences. You shouldn’t quietly absorb a different project because the original quote lacked boundaries.
For a Webflow build, a useful quote is one the client can question and you can deliver against. That takes enough detail to expose the assumptions, without turning the proposal into a technical manual. For WordPress clients weighing a move, the Webflow vs WordPress comparison covers the decision before the quote.