The questions we ask before quoting a project, not after

Nearly every quote that turns out to be significantly wrong, in either direction, traces back to a question that wasn't asked clearly enough during scoping. Over enough projects, we've built up a specific list of questions that reliably surface the details that change a price, and asking them upfront avoids the much more uncomfortable conversation of a mid-project scope correction.

A project's complexity often lives in its integrations, not its visible features. "It needs to sync with our inventory system" can mean a clean, documented API or a decade-old system with no real API at all, and those two answers produce wildly different quotes for what sounds like the same feature request on the surface.

A quote built around one stakeholder's requirements can be substantially wrong if a second stakeholder, discovered midway through the project, has different requirements that weren't part of the original scoping conversation. We ask directly, at the start, who else needs to sign off on this, before finalizing scope, not after work has started.

"As soon as possible" isn't a real deadline, and treating it as flexible when it's actually tied to a fixed external event (a trade show, an investor demo, a contractual launch date) leads to either a rushed final stretch or a client relationship strained by a missed date nobody flagged as truly fixed. We ask what's driving the timeline specifically, not just what the timeline is.

Two people can agree a project is "a website redesign" and have meaningfully different mental pictures of the finished result. We ask for reference examples, specific pages the client considers close to what they want, before quoting, since a shared visual reference surfaces scope misalignment far earlier and more concretely than a written description alone.

Post-launch support terms, how bugs found in the first weeks get handled, whether that's included in the original quote or billed separately, need agreement before the project starts, not discovered as a surprise the first time something breaks after launch. It's an uncomfortable question to ask upfront and a far more uncomfortable one to negotiate after a client's site has an actual bug in production.

A quote for "a new website" can vary enormously depending on whether professional photography, written copy, and brand assets already exist and just need to be incorporated, or whether all of it needs to be created from scratch as part of the engagement. We ask specifically, item by item, what already exists in a usable, final state versus what's still aspirational, since a client who assumes their existing photos are usable when they're actually low-resolution and unlicensed for the intended use is a scope gap that's much cheaper to catch during scoping than midway through a design phase that assumed those assets were ready to use.

How we quote and staff a project shifts depending on whether the client expects a single, defined deliverable with no ongoing relationship afterward, or whether this project is explicitly the first phase of a longer-term, ongoing engagement. A one-time project gets priced and scoped tightly around its specific deliverable, while an engagement expected to continue often benefits from a slightly different staffing and pricing structure that accounts for the relationship-building and context-retention value of continuity. We ask this directly rather than assuming, since guessing wrong in either direction leads to a mismatch between what the client actually wanted and what got quoted.

A prospective client approaching us with a problem, low conversion rates, a slow site, poor search rankings, has often already tried something to address it, whether an in-house attempt, a previous vendor's engagement, or an off-the-shelf tool. We ask directly what's already been tried and, more importantly, why the client believes it didn't work, since a quote built without this context risks proposing the same approach that already failed, framed slightly differently, and running into the same underlying obstacle a second time. Understanding the specific reason a prior attempt fell short, a technical constraint, insufficient budget, a stakeholder who didn't buy in, changes what we'd actually recommend and how we scope around the risk of repeating the same outcome.

A project's actual scope depends partly on how much the client's own team can realistically contribute, providing timely feedback, supplying content, testing along the way, versus how much needs to be handled entirely by us. We ask directly about the client team's available bandwidth during the project timeline, since a client who confidently commits to fast feedback turnarounds but is actually understaffed and overcommitted elsewhere in their organization introduces a real risk to the timeline that a quote assuming ideal client responsiveness won't have accounted for. Where we sense a mismatch between stated and realistic client capacity, we build in buffer or propose a different collaboration model rather than quoting against an optimistic assumption likely to be tested within the first few weeks.

Every one of these questions gets asked in a live conversation, but the answers all get written down in a shared scoping document before a quote is finalized, not left as a shared verbal understanding that can quietly diverge in each side's memory over the following weeks. A written record of what was actually asked and answered during scoping becomes the reference point if a disagreement about scope surfaces later, and simply knowing the conversation is being documented tends to produce more careful, considered answers from clients in the moment than an informal chat would.