The discovery call is not a sales call
The 30 minutes we spend on a first call has one job: extract the actual problem. Not "we need a website" — that's a solution someone landed on before calling us. Not "we want more leads" — that's a metric without a mechanism. The actual problem is the underlying friction that makes the current situation unsustainable.
We document four things during every call:
- Current state — what exists, what it does, what it breaks on
- Desired state — what "fixed" looks like in the words of the person who has to live with it
- Constraints — hard deadline, budget range, technical debt, who maintains it afterward
- Stakeholders — who needs to approve, who uses it daily, who will inadvertently break it
That last one gets skipped more than any other. We've killed scopes that looked clean on paper because nobody had surfaced that the real decision-maker wasn't on the call — and that person had a different definition of "done" than everyone else. It's faster to find that out in minute 20 of a discovery call than in week 5 of a build.
"We need a website" is not a scope. "Our current site doesn't convert mobile visitors and our competitor's does" is.
What happens in the first 24 hours
The call ends. Notes get organized — not transcribed wholesale, but distilled into the four categories above. That same afternoon, we run the constraints against our standard service tiers.
If the project fits a known shape — a Webflow marketing site with a HubSpot integration, say, or a 5-page Next.js build with a blog — we cross-reference against similar past work, flag anything unusual (a non-standard payment processor, a particularly tight 3-week deadline, content that's still being written), and draft the deliverable list. Most of this takes 60–90 minutes.
Custom builds take longer in hour one. A multi-step AI agent that reads incoming emails, qualifies leads against a scoring rubric, and posts a summary to Slack looks simple in conversation. It's not simple. The first 24 hours for a project like that is largely about identifying the unknown-unknowns: where does the "simple" integration actually touch a database, what happens when the upstream API rate-limits us, what's the fallback when the model's confidence score is too low to act? Those questions don't all need answers before the proposal, but they need to be named.
By end of day one, we have a working scope that answers three things: what are we building, what are we explicitly not building, and what is the realistic timeline given current workload.
What we deliberately leave out
No mockups in the proposal. No wireframes, no design concepts, no color palettes. We don't design anything until the scope is agreed and the project deposit is confirmed.
This sounds rigid. It protects you more than it protects us. A design presented before scope is locked will almost always need revision once the actual requirements surface — which means you've seen something, gotten attached to it, and then watched it change. Better to agree precisely on what we're building, then design the right thing for that exact scope.
We also don't include vague revision language. Every phase in every proposal we send has a specific revision count — typically two rounds per phase, with a clear definition of what counts as a revision versus a scope change. Scope creep is the single biggest reason web and AI projects exceed budget — not overpriced agencies, not complex technology. Our proposals are designed to prevent it by naming the boundary before work starts.
The cheapest project is the one with a clear scope. The most expensive is the one that grew.
What you get at hour 48
A document, not a pitch deck. Typically 3–5 pages covering:
- Scope summary — what we're building and, just as importantly, what we're not
- Deliverables broken down by phase, with acceptance criteria for each
- Timeline with milestones and the two or three decision points that can shift it
- Investment and payment schedule — usually 50% to start, 50% at launch
- A short paragraph on change handling — because something always changes, and how it gets handled is worth reading before you sign
We ask for a decision within 5 business days. Not because we're inflexible — if a project has a genuine approval process that takes longer, we talk about it — but because most scopes involve timelines. A 2-week delay in decision usually means a 2-week delay in launch, and some launch windows actually matter.
If the proposal is wrong — scope too large, budget misaligned, timeline impossible — we'd rather hear that in day 3 than week 6. We've sent proposals that weren't the right fit and pointed the client toward a better option. That conversation is easier at the proposal stage than after a deposit.
Check our services page if you want a sense of what standard packages look like, or the FAQ for what's worth preparing before the call. If you want to see this process firsthand, book a discovery call and you'll have a scoped proposal within 48 hours of hanging up.
— Cole