The Discovery Call Framework I Use to Close $20K+ Projects

TL;DR

Discovery calls are the single highest-leverage activity in my freelance business. I run free 30-minute calls through Calendly, and they are the reason I close projects between $8,000 and $80,000 without ever feeling like I am selling. I am not a sales guy. I am an engineer who got tired of writing proposals that went nowhere, attracting bad-fit clients, and starting projects with unclear scope that turned into nightmares. Over the past two years, I have refined a framework that lets me qualify a lead, understand the real problem, assess technical feasibility, and discuss budget honestly — all within 30 minutes. My conversion rate from discovery call to signed contract sits around 40%, and the projects that close are consistently better scoped, better paid, and more enjoyable to build. This article is the full breakdown — every question I ask, every red flag I watch for, and how I follow up with a proposal that converts.

Why Discovery Calls Matter

Most developers skip the discovery call. They get an inquiry, reply with "send me the details," receive a vague brief over email, spend three hours writing a proposal, and never hear back. I did this for months before I realized the problem was not my proposals — it was the fact that I had zero relationship with the person reading them.

A discovery call changes the dynamic completely. You stop being a faceless developer in someone's inbox and become a real person who listened to their problem and asked sharp questions they had not thought about. That alone puts you ahead of 90% of the developers they are evaluating.

But there is a deeper reason discovery calls matter. They protect you. Every bad project I have ever taken on — the scope creep disasters, the "I thought we agreed on something different" arguments, the clients who vanished after milestone two — every single one of those started without a proper discovery call. I either skipped it or treated it as a casual chat instead of a structured conversation.

The call is not about selling. It is about qualifying. You are trying to answer one question: should I work with this person? The client is simultaneously trying to answer the same question about you. A good discovery call makes that mutual evaluation honest and efficient.

Here is what a 30-minute discovery call gives you that email never will:

• Tone and urgency. You can hear whether this is a real project or someone shopping for quotes to compare against their current developer.
• Decision-making structure. You learn who makes the final call, who controls the budget, and whether the person on the call can actually say yes.
• Technical understanding. Five minutes of conversation reveals more about the client's technical literacy than twenty emails. This determines how you scope, price, and communicate.
• Chemistry. Some clients are a joy to work with. Others will drain your energy for months. You can feel this within ten minutes.

I offer my discovery calls for free because the ROI is absurd. A 30-minute call saves me hours of proposal writing for bad-fit leads and gives me the information I need to write proposals that actually close. I book them through Calendly with a simple intake form — name, company, brief description of the project, and estimated budget range. That last field alone filters out 30% of tire-kickers before the call even happens.

My 30-Minute Framework

I do not wing discovery calls. I follow a structure. Not a rigid script — I am not reading off a teleprompter — but a framework that ensures I cover everything I need to make a decision and write a proposal. Here is the breakdown:

Minutes 0-3: Warm-up and context. I thank them for booking the call, confirm how much time we have, and ask them to give me the two-minute version of what they are building and why. This is important — I want their framing first, before I start asking questions. It tells me what they think the project is, which is often different from what it actually is.

Minutes 3-12: Deep dive into the problem. This is where the real questions happen. I dig into the business problem, the users, the current state, and what success looks like. I am not asking about features yet — I am asking about outcomes. Most clients show up with a solution in mind. My job is to understand the problem behind the solution.

Minutes 12-18: Technical feasibility. Now I shift into engineer mode. Based on what they have described, I start thinking out loud about architecture, potential challenges, third-party integrations, and timeline realities. This is where I add obvious value — they can hear me thinking through their problem in real time, and it builds massive trust.

Minutes 18-23: Budget and timeline. I discuss budget directly. Not evasively, not "I will send you a quote." I give them a ballpark range on the call and explain what drives the number up or down. I also set realistic timeline expectations. If they need it in two weeks and it is a three-month project, I tell them on the call.

Minutes 23-28: Next steps and expectations. I explain my process — what the proposal will include, when they will receive it (always within 48 hours), and what the engagement looks like if they move forward. I also ask if they are talking to other developers, not because I am insecure about it, but because it affects my follow-up timing.

Minutes 28-30: Questions from them. I always leave time for their questions. Common ones: "What is your availability?" "Do you work with a team?" "Can I see similar work?" I answer honestly and specifically.

This structure is flexible. Some calls run 40 minutes because the problem is complex. Some wrap in 20 because the scope is straightforward. But the sequence — context, problem, feasibility, budget, next steps — stays the same every time.

The Questions I Always Ask

These are not hypothetical. These are the exact questions I ask on every discovery call, refined over two years and probably 200 calls. I keep them in a Notion doc and glance at it before every call.

Understanding the business

• "Tell me about your business — what do you do, who do you serve, and how does this project fit into the bigger picture?"
• "What is driving this project right now? Why this, why now?"
• "Who are the end users? How many? What is their technical comfort level?"
• "Is this replacing something that exists, or is it brand new?"
• "What does success look like six months after launch?"

Understanding the scope

• "Walk me through what a user would do from the moment they land on this — step by step."
• "What are the absolute must-haves for launch versus nice-to-haves for later?"
• "Are there any third-party tools or platforms this needs to integrate with?"
• "Do you have designs, wireframes, or a reference product you are modeling this after?"
• "Is there existing code, a database, or infrastructure I would be building on top of?"

Understanding the decision

• "Who else is involved in the decision to move forward?"
• "What is your ideal timeline? When do you need this live?"
• "Have you set a budget range for this project?"
• "Are you evaluating other developers or agencies for this?"
• "What would make you confident that I am the right person for this?"

Understanding the relationship

• "How do you prefer to communicate during a project — Slack, email, weekly calls?"
• "Have you worked with a freelance developer before? How did that go?"
• "What is the one thing that would make this project a bad experience for you?"

That last question is quietly the most powerful one I ask. It surfaces the client's biggest fear — whether that is scope creep, missed deadlines, lack of communication, or burning money without results. Once I know their fear, I can address it directly in the proposal and throughout the project. People hire people who understand what keeps them up at night.

How I Assess Technical Feasibility

I am an engineer first. The discovery call is not just a sales conversation — it is a technical evaluation. While the client is talking, I am running architecture in my head. By the time I hang up, I need to know three things:

1. Can I build this? Not "can this be built" — can I, specifically, with my stack and experience, build this well? If the project requires native iOS development and I am a web developer, that is a gap I need to be honest about. I have turned down projects because the technical requirements did not match my strengths, and I have never regretted it.

2. How complex is the hard part? Every project has an easy 80% and a hard 20%. The easy part is CRUD, layouts, basic auth — table stakes. The hard part is the thing that makes this project unique. Maybe it is real-time collaboration, a complex pricing algorithm, a blockchain integration, or a data pipeline that needs to process 50,000 records daily. I identify the hard part on the call and estimate how much uncertainty it carries.

3. What are the technical risks? Third-party API dependencies that might be unreliable. Data migration from a legacy system with no documentation. Performance requirements that constrain architecture choices. Browser compatibility requirements for enterprise clients running Internet Explorer. I flag these risks on the call, not to scare the client, but to show them I am thinking ahead.

I think out loud during this part of the call. I will say things like, "So the way I would approach this is Next.js for the frontend with Supabase on the backend, and for the real-time piece, we would probably use Supabase Realtime or build a custom WebSocket layer depending on the concurrency requirements." Clients love this. They can hear that I have done this before. It is the single biggest trust-builder in the entire call.

When I am uncertain about feasibility — and sometimes I am — I say so. "I have not built exactly this before, but I have built similar systems. I would want to spend a few hours doing a technical spike before I commit to a price." Honesty about what I do not know builds more trust than pretending I have done everything.

Discussing Budget — The Honest Way

Budget is where most developers choke. They are either afraid to name a number, or they ask the client what their budget is and then price to whatever the answer was. Both approaches are broken.

Here is how I handle it. By minute 18 of the call, I have enough information to give a ballpark. Not a quote — a range. I will say something like:

"Based on what you have described, a project like this typically falls between $15,000 and $25,000. The lower end assumes straightforward integrations and you providing the designs. The higher end accounts for custom design work, more complex user roles, and a longer testing phase. I will give you an exact number in the proposal, but I want to make sure we are in the same universe before I spend time on that."

That last sentence is critical. It gives the client permission to say "that is way over our budget" without either of us wasting time. If their budget is $5,000 and my ballpark is $20,000, better to know now than after I write a detailed proposal.

When clients ask me to lower my price, I do not negotiate against myself. Instead, I scope down. "I cannot build the full vision for $10,000, but here is what I can build — a solid MVP with the core functionality that lets you validate the idea. If it works, we can phase two the rest." This is genuinely useful advice, not a sales tactic. Most clients are trying to build too much at once anyway.

Three things I never do when discussing budget:

• I never ask "what is your budget?" as the first question. It puts the client on the defensive and it sounds like I am trying to maximize extraction. I earn the right to discuss budget by demonstrating understanding of their problem first.
• I never apologize for my prices. My rates reflect my experience, my stack, and the outcomes I deliver. If someone wants cheaper development, there are thousands of developers on Upwork who will happily take that on.
• I never send a price over email without context. A number without context is just a number. The discovery call provides the context that makes the number feel justified.

I wrote a full breakdown of how I calculate project prices in my article on pricing software development services. The discovery call is where I gather the inputs for that calculation.

Red Flags I Watch For

Not every lead is a good client. The discovery call is my filter, and I have learned — painfully, expensively — to trust the red flags when they appear.

"We need it yesterday." Urgency is fine. Panic is not. If a client needs something built in an impossibly short timeline, they are either underestimating the complexity or they had another developer bail on them. Both situations create pressure that leads to cut corners and burned relationships. I will ask why the timeline is so tight. Sometimes there is a legitimate reason — a product launch, a funding deadline. Sometimes they just want it fast because they want it fast. The latter is a red flag.

"Can you just give me a quick estimate?" If someone resists the discovery call and just wants a number, they are price shopping. They have no intention of evaluating my approach, my thinking, or my fit. They want the cheapest option. I am never the cheapest option, and I do not want to be.

"The last developer we hired was terrible." One bad experience is understandable. If every developer they have ever worked with was terrible, the common denominator is not the developers. I ask follow-up questions: what went wrong, how was scope defined, how was communication handled. If they take zero ownership of past failures, I am cautious.

No decision-maker on the call. If I am talking to someone who needs to "run it by" someone else who I will never meet, the sale gets exponentially harder. I am not saying I need the CEO on every call, but the person with budget authority needs to be involved at some point before a proposal goes out.

Scope that keeps growing during the call. "Oh, and it also needs to do this. And can it also integrate with that? And we probably need a mobile app too." If the scope doubles during a 30-minute call, imagine what happens over a three-month project. I flag this directly: "It sounds like the scope is larger than what you initially described. Let me put together a phased approach so we can prioritize."

Negotiating before the proposal. If a client is pushing back on a ballpark range before they have even seen a detailed proposal, they are telling me their budget is significantly lower than what this project requires. This is not inherently bad — maybe we can scope down — but it does tell me this person's first instinct is to negotiate on price rather than value.

I turn down roughly 30% of leads after the discovery call. That might sound high, but the math works. The projects I do take on are better scoped, better paid, and far less likely to become the kind of engagements that make you dread opening Slack on Monday morning.

Following Up — The Proposal

The discovery call ends, and now the clock starts. I send every proposal within 48 hours, and I aim for 24. Speed matters — the client's enthusiasm is highest right after the call, and every day you wait, that enthusiasm decays.

My proposals are not PDFs designed to impress. They are clear, structured documents that answer four questions:

1. What am I building? A plain-language summary of the scope, broken into phases or milestones. No jargon. The client should be able to read this to their business partner and have it make sense.

1. How am I building it? A brief technical overview — the stack, the architecture decisions, and why I chose them. This is not for the client — this is for the CTO or technical advisor who might review the proposal.

1. How long will it take? A timeline with milestones. I always pad by 20% and I am transparent about it. "The development timeline is 8 weeks. I have added a 2-week buffer for revisions and edge cases, for a total delivery window of 10 weeks."

1. What does it cost? The investment, payment schedule (typically 40% upfront, 30% at midpoint, 30% at delivery), and what is included versus excluded.

I also include a section I call "Assumptions and Risks" — things that could affect timeline or cost. Client-provided API access on time. Design approvals within five business days. Content provided before development begins. This section has saved me from more scope creep disputes than I can count.

The proposal directly references things discussed on the call. "As we discussed, the real-time notification system is the most technically complex component..." This reinforces that I listened, I understood, and I am building on our conversation — not sending a generic template.

If I do not hear back within five days, I send a single follow-up. Short, no pressure: "Hey — wanted to check if you had any questions about the proposal. Happy to jump on a quick call to walk through anything." If I do not hear back after that, I move on. Chasing cold leads is a waste of energy.

What I Learned from Bad Calls

My discovery calls were not always this structured. I have made every mistake, and each one taught me something I now build into the framework.

Talking too much. My first dozen discovery calls were basically me pitching for 25 minutes and asking "so, what do you think?" at the end. The client barely spoke. I was so eager to demonstrate competence that I forgot the call's primary purpose — to listen and understand. The ratio should be 70% client talking, 30% me. I had it inverted.

Not asking about budget early enough. I used to save budget for the very end, or worse, skip it entirely and put the number in the proposal. This led to proposals where the client had been expecting $3,000 and I quoted $25,000. Waste of everyone's time. Now I broach budget by minute 18, and the sticker shock — if there is any — happens on the call where I can contextualize it.

Taking on projects out of scarcity. In my first year, I said yes to everything because I was afraid the next project might not come. A client wanted a WordPress site for $2,000? Sure. Someone needed an app built in a framework I had never used? Why not. This led to mediocre work, missed deadlines, and clients who were not the right fit. Learning to say "this is not the right project for me" was one of the hardest and most profitable lessons.

Not recording calls. I started recording discovery calls (with permission) about a year ago, and it changed everything. I can go back and catch details I missed in the moment. I can hear my own patterns — the questions that unlock great answers and the ones that fall flat. If you are not recording your calls, start.

Skipping the intake form. For a while, I let anyone book a call with no pre-screening. I spent 30 minutes with people who had a $500 budget, people who wanted me to build their idea for equity, and people who just wanted free consulting. The intake form with a budget range field solved this overnight. It does not need to be invasive — name, email, project description, estimated budget range. Four fields. It filters out the noise.

Conversion Rate and What Affects It

My current conversion rate from discovery call to signed contract is approximately 40%. That means for every 10 calls, I close 4 projects. The average project value is around $22,000, so 10 calls generate roughly $88,000 in revenue. I typically do 6-8 calls per month.

Here is what I have found moves the conversion rate:

Speed of follow-up. When I send the proposal within 24 hours, my close rate jumps to around 55%. At 48 hours, it drops to 35%. After 48 hours, it falls off a cliff. The client talked to someone else, they got distracted, or they lost the urgency that made them book the call.

Specificity of the proposal. Generic proposals close at maybe 15%. Proposals that reference the exact problems, features, and concerns discussed on the call close at 45%+. People want to feel heard, not templated.

The ballpark on the call. When I give a range on the call and the proposal comes in within that range, the close rate is highest. No surprises. The client has already mentally committed to the investment.

Referrals versus cold leads. Referred clients close at roughly 60%. Cold inbound from my website is closer to 30%. This is not surprising — a referral comes with pre-built trust. I invest heavily in delivering great work because every completed project is a referral source.

Project size. Counterintuitively, larger projects ($30K+) have a higher close rate than smaller ones ($8K-$12K). My theory: clients spending $30K+ have already decided to invest seriously. They are evaluating approach and fit, not shopping for the cheapest option. Clients at $8K are more likely to be comparing you against five other developers and optimizing for price.

The numbers tell a clear story: the discovery call framework is not about being slick or persuasive. It is about being fast, specific, honest about pricing, and selective about who you work with. The calls where I am most "myself" — curious, direct, thinking out loud — are the ones that close.

Key Takeaways

• Every project starts with a 30-minute discovery call. No exceptions. No "just send me a quote." The call is where trust is built, scope is understood, and bad fits are filtered.

• Follow a structure, not a script. Context, problem, feasibility, budget, next steps — in that order. Stay flexible within the framework but never skip a section.

• Ask about outcomes, not features. "What does success look like six months after launch?" is worth more than "how many pages does the app need?"

• Discuss budget on the call. Give a range. Contextualize it. If the numbers do not align, find out now — not after you have spent three hours on a proposal.

• Trust the red flags. If the call feels wrong, it is wrong. Impossible timelines, price-first mentality, growing scope, no decision-maker present — any of these should make you cautious.

• Send the proposal within 24 hours. Speed is the single biggest variable in conversion rate. The client's excitement decays with every hour.

• Record your calls and review them. You will find patterns — questions that unlock great answers, moments where you talk too much, places where you could have dug deeper.

• Say no to bad-fit projects. The 30% of leads you turn down make room for the projects that are actually worth your time, energy, and reputation.

The discovery call is not a sales pitch. It is a diagnostic conversation. You are an engineer solving the first problem — is this project worth building, for this client, at this price, on this timeline? Answer that question well, and the sale takes care of itself.

*I am Uvin Vindula↗, a full-stack and Web3 engineer based between Sri Lanka and the UK. I build production-grade web applications, AI integrations, and blockchain systems for clients worldwide. My projects range from $8K MVPs to $80K enterprise platforms. If you have a project in mind, book a free discovery call — I would genuinely like to hear what you are building.*