At CODERCOPS, we have delivered 11 projects across healthcare, e-commerce, Web3, AI, and security. Every single one of them started the same way: a 45-minute discovery call where we asked seven specific questions. Not a casual chat. Not a pitch meeting. A structured conversation designed to surface the information that determines whether a project succeeds or fails.
We are sharing the exact questions here because we believe transparency about our process helps clients prepare for better conversations, and helps other agencies think more carefully about their own intake processes.
How a Discovery Call Gets Scheduled
Before we get into the questions themselves, let us walk through how a client actually reaches the discovery call stage. This pipeline matters because it sets the tone for the entire relationship.
The Calendly to WhatsApp to Discovery Call to Airtable Pipeline
Here is the exact flow:
Step 1: Initial Contact. A potential client finds us through our website at codercops.com, a referral, or our content. They fill out our contact form, which simultaneously does two things: it creates a record in our Airtable CRM and triggers an SMTP email notification to our team. Both happen in real time, so no lead sits unacknowledged.
Step 2: Calendly Scheduling. Within 24 hours (usually much faster), we respond with a Calendly link for a discovery call. Calendly handles the time zone conversion, calendar availability, and reminder emails. We offer 45-minute slots because that is enough time to ask all seven questions without rushing, but short enough to stay focused.
Step 3: WhatsApp Confirmation. Once the call is booked, we send a WhatsApp message confirming the appointment and sharing a brief pre-call questionnaire. WhatsApp is our primary async communication channel because it works better than email in the Indian and Southeast Asian markets where many of our clients operate. The pre-call questionnaire asks three simple things: what is your business, what do you want to build, and what is driving the timeline. This primes the conversation.
Step 4: The Discovery Call. The call itself follows the seven-question framework we detail below. Our CTO Prathviraj Singh joins these calls when the project has significant technical complexity. Otherwise, I handle them directly.
Step 5: Airtable CRM Update. Immediately after the call, we update the Airtable record with structured notes from each of the seven questions. This record becomes the single source of truth that our Strategy phase draws from. Every team member who touches the project can reference these discovery notes.
This pipeline means no lead falls through the cracks, every discovery call has context, and the transition from discovery to strategy is seamless because the data is already structured.
The 7 Questions
These questions are ordered deliberately. They move from the broadest strategic context to the most specific operational details. Reordering them changes the conversation dynamics in ways that matter.
Question 1: "What problem are you solving, and for whom?"
This is always the first question. Not "what do you want to build?" Not "tell me about your company." We start with the problem because everything else derives from it.
Why we ask it. The most common mistake in software development is building a solution before fully understanding the problem. When a client says "we need a mobile app," that is a solution, not a problem. The problem might be "our field technicians waste 3 hours a day on paperwork." The solution might be a mobile app, or it might be a web form, an integration with their existing system, or something else entirely.
Starting with the problem also surfaces who the end users are. "For whom" is the critical second half of this question. A healthcare dashboard for doctors has fundamentally different requirements than a healthcare dashboard for patients, even if the underlying data is identical.
What good answers look like. Good answers are specific and grounded in real pain. "Our customers abandon checkout at a 72% rate because our current flow requires 6 steps and forces account creation." That tells us the problem (high cart abandonment), the cause (friction in the flow), and the audience (customers completing a purchase). We can work with that.
Clients who have done customer interviews, have support ticket data, or can point to specific metrics tend to give the best answers. They have moved past assumptions and into evidence.
What red flag answers look like. "We just need a website." That is a solution with no problem attached. "Everyone needs an app these days." That is a trend, not a problem. "Our competitor has one." That is a reaction, not a strategy.
Red flag answers do not mean we reject the project. They mean we spend more time in this part of the conversation, asking follow-up questions until we uncover the actual problem. Sometimes clients have a clear problem in their head but have not articulated it before. Our job is to draw it out.
How this answer influences our approach. The problem statement becomes the North Star for the entire project. Every design decision, every feature prioritization, every technical choice gets evaluated against it. If a feature does not help solve the stated problem for the stated audience, it goes to the backlog, not the MVP.
Question 2: "What does success look like in 6 months?"
We ask specifically about 6 months because it forces clients to think beyond launch day without getting lost in multi-year fantasies.
Why we ask it. This question defines the project's success metrics before we start building. Without clear success criteria, you cannot know whether the project was worth doing. It also reveals whether the client has realistic expectations. If someone expects 100,000 users within 6 months of launching a niche B2B tool with no marketing budget, that is a conversation we need to have now, not after delivery.
What good answers look like. Measurable, specific outcomes. "We want to reduce our customer support ticket volume by 40% because the new self-service portal handles the top 10 FAQ categories." Or "We want to process 500 orders per day through the new system without manual intervention." Numbers and timeframes are what we look for.
The best answers tie back to business outcomes, not feature completion. "Success is having all 15 features live" is a weaker answer than "success is reducing our cost-per-acquisition from $45 to $28."
What red flag answers look like. "We just want it to look modern." That is subjective and unmeasurable. "We want to go viral." That is not a strategy. "We will figure that out later." That suggests the project does not have clear executive sponsorship or business justification.
How this answer influences our approach. The 6-month success metrics directly shape our MVP definition. If success means processing 500 orders per day, we prioritize order flow reliability, error handling, and scalability. If success means reducing support tickets, we prioritize content architecture and search functionality. The answer to this question determines what we build first.
Question 3: "Who are your competitors, and what do they do well?"
Notice we ask what competitors do well, not what they do poorly.
Why we ask it. Studying competitors is not about copying. It is about understanding market expectations. If every competitor in a space offers real-time notifications, then real-time notifications are a baseline expectation, not a differentiator. Clients sometimes underestimate how sophisticated their competitive landscape is.
Asking what competitors do well, specifically, forces a more honest assessment. Most clients are eager to point out competitor weaknesses. Getting them to acknowledge strengths requires more thought and produces more useful information.
What good answers look like. "Competitor A has excellent onboarding. Their first-time user experience takes about 3 minutes to reach the first value moment. Competitor B has a better pricing model, but their UI is dated." This tells us the client has actually used competing products and has opinions grounded in experience.
Even better: "We interviewed 20 users who switched from Competitor A to us, and they consistently mentioned that Competitor A's reporting was more intuitive." That is gold.
What red flag answers look like. "We do not have any competitors." Every product has competitors, even if the competition is a spreadsheet, a paper process, or doing nothing. Claiming no competition suggests the client has not validated market demand.
"Our competitors are terrible." If every competitor is terrible, either the market is not viable enough to attract good players, or the client has not looked closely enough.
How this answer influences our approach. Competitive analysis feeds directly into our Design phase. We study the competitors the client mentions, identify UX patterns that users in this market expect, and find genuine opportunities for differentiation. It also influences our Strategy phase by helping us define the minimum viable feature set: you have to match competitor baselines before you can exceed them.
Question 4: "What is your budget range and timeline?"
We ask this directly. No games, no "we will get back to you with a proposal first." Budget and timeline are constraints that shape every technical and design decision, and we need to know them upfront.
Why we ask it. A $15,000 project and a $150,000 project for the same concept result in fundamentally different products. Neither is wrong. But we cannot give useful recommendations without knowing which one we are discussing. Similarly, a 6-week timeline demands different architectural choices than a 6-month timeline.
We have found that asking budget and timeline together is more productive than asking them separately. They are inherently linked. A tight timeline with a generous budget means we staff up. A tight budget with a flexible timeline means we phase the work.
What good answers look like. "Our budget is between $30,000 and $50,000, and we need to launch before our industry conference in September." A range is better than a single number because it gives us room to propose options. A timeline tied to a real event (conference, regulatory deadline, funding milestone) is more reliable than an arbitrary date.
What red flag answers look like. "We do not have a budget." Every project has a budget, even if it has not been formalized. This answer usually means the decision-maker is not in the room, or the client wants us to name a number first so they can negotiate down.
"We need it yesterday." Urgency is fine. Panic is not. If a client cannot explain why the timeline is what it is, the deadline often turns out to be soft, which means it will shift repeatedly during the project.
"Can you just give us a ballpark?" Before the discovery call is complete, no, we cannot. A ballpark without context is meaningless and sets the wrong expectations.
How this answer influences our approach. Budget and timeline determine our staffing plan, our technology choices (build vs. buy vs. integrate), our phasing strategy (single launch vs. phased releases), and our scope recommendations. If the budget is below what the full vision requires, we propose an MVP that fits the budget and a roadmap for future phases.
Question 5: "Do you have existing tech, data, or systems we need to integrate with?"
This is where the conversation shifts from strategic to technical. At this point in the call, if Prathviraj is not already on the line, we might loop him in for the remaining questions.
Why we ask it. Integration requirements are the number one source of unexpected complexity in agency projects. A "simple" e-commerce site becomes a complex systems integration project when the client mentions their ERP, their warehouse management system, their existing payment processor with custom fraud rules, and their loyalty program database.
We also need to know about existing data. Migrating 50,000 customer records from a legacy system is a project within the project. Better to know now than to discover it during development.
What good answers look like. "We use Salesforce for CRM, Stripe for payments, and we have a PostgreSQL database with 3 years of transaction history that needs to migrate." Specific systems, named platforms, and data volume estimates are what we need.
Even better if the client can provide API documentation or confirm that their existing systems have APIs at all. We have had projects where the "integration" turned out to require screen scraping a legacy application because it had no API.
What red flag answers look like. "We will figure out the integrations later." Integrations affect architecture. You cannot figure them out later without risking rework. "Our developer built a custom system and he left." That tells us we may be dealing with undocumented, potentially unmaintainable legacy code.
How this answer influences our approach. Integration requirements directly shape our technical architecture. They determine which frameworks we use, how we design our data models, what middleware or API layers we need, and how much of the timeline is allocated to integration work vs. new development. On a recent healthcare project, integration with an existing EHR system consumed 35% of the total development time. Knowing that upfront was essential for accurate scoping.
Question 6: "Who on your team will be our primary contact?"
This sounds like an administrative question. It is not. It is one of the most important questions we ask.
Why we ask it. The primary contact determines the speed and quality of decisions throughout the project. A primary contact who has authority to approve designs, prioritize features, and resolve internal disagreements keeps the project moving. A primary contact who has to "check with the boss" on every decision introduces delays that compound over weeks and months.
We also need to understand the decision-making structure. Is this a founder-led project where one person makes all decisions? Is there a committee? Are there stakeholders who are not on this call but will have opinions later? Hidden stakeholders who appear late in a project and demand changes are one of the most common causes of scope creep.
What good answers look like. "I am the primary contact. I have sign-off authority on design and features up to the approved scope. For anything beyond scope, I need approval from our VP of Product, and that takes about 48 hours." Clear authority, clear escalation path, clear timelines.
What red flag answers look like. "We will all be involved." When everyone is responsible, no one is responsible. Decisions get stuck in committee. "I will be the contact, but my boss will want to review everything." That is fine if "review everything" has a defined turnaround time. It is a problem if reviews take weeks.
The biggest red flag is when the person on the discovery call is not the person who controls the budget. We have learned to ask explicitly: "Are you the budget owner for this project?"
How this answer influences our approach. The communication structure we set up depends entirely on this answer. A single empowered contact means we can use WhatsApp for quick decisions and weekly video check-ins. A committee structure means we build in more formal review milestones, prepare more documentation for async review, and pad the timeline for decision-making cycles.
We also calibrate our project management approach. Some contacts want daily Slack updates. Others want a weekly summary email. We ask about communication preferences in the follow-up after the discovery call, but knowing who the contact is determines who we ask.
Question 7: "What is your long-term vision beyond this project?"
This is always the last question, and it is the one that separates a transactional vendor relationship from a strategic partnership.
Why we ask it. Technical decisions made today constrain or enable what you can build tomorrow. If a client plans to expand from India to Southeast Asia in 18 months, we need to think about internationalization now, even if the current project is India-only. If they plan to add AI-powered features in a future phase, we need to choose a data architecture that supports it.
This question also helps us understand the client's ambition and trajectory. Are we building a tool for a small team, or the foundation of a platform that will serve thousands of users? The answer changes our scalability recommendations, our infrastructure choices, and our code architecture.
What good answers look like. "This project is Phase 1. In Phase 2, we want to add a mobile app for our field team. In Phase 3, we want to open the platform to third-party vendors." A roadmap, even a rough one, tells us how to build for extensibility.
"We plan to raise a Series A after launch, and the product needs to demonstrate traction to investors." That context changes our priorities. We might emphasize analytics integration and dashboards that tell the growth story.
What red flag answers look like. "We have not thought that far ahead." For a simple brochure website, that is fine. For a $50,000 custom application, it suggests a lack of strategic planning that will cause problems down the line.
"We want to become the Uber of [industry]." Grandiose comparisons without substance are a warning sign. We want to hear specific plans, not analogies.
How this answer influences our approach. Long-term vision shapes our architectural decisions more than any other answer. We build with extensibility in mind when we know what "extensible" means for this specific client. We choose technologies that support the growth trajectory. We design data models that can accommodate future features without requiring a rewrite.
On one of our Web3 projects, knowing that the client planned to add cross-chain functionality in Phase 2 influenced our smart contract architecture from day one. Had we not known, we would have built a simpler architecture that would have required significant refactoring later.
After the Call: How Discovery Flows Into Strategy
The discovery call is not the end of our Discovery phase. It is the centerpiece. Here is what happens after the call ends:
Immediate Post-Call (Same Day)
Structured notes go into Airtable. Each of the seven questions has its own field in our CRM record. This is not a free-form notes dump. It is structured data that our Strategy phase pulls from directly.
Internal debrief. If both Prathviraj and I were on the call, we debrief immediately while the conversation is fresh. We discuss technical feasibility, potential risks, and initial approach ideas.
Red flag assessment. We explicitly discuss any red flags that came up. Not every red flag is a deal-breaker, but every red flag needs a mitigation plan. If the primary contact does not have decision authority, we need to establish a review process. If the budget is tight for the scope, we need to propose phasing.
Within 48 Hours
Follow-up message via WhatsApp. We send a summary of what we heard on the call and ask the client to confirm or correct our understanding. This is a critical step. Miscommunication caught at this stage costs nothing. Miscommunication caught during development costs weeks.
Preliminary scope assessment. Based on the discovery call answers, we draft a rough scope document that identifies the major workstreams, key risks, and open questions that need resolution before we can move to a formal proposal.
Within One Week
- Strategy phase kickoff. If the client confirms the summary and wants to proceed, we move into our Strategy phase. This is the second step of our six-step process (Discovery, Strategy, Design, Development, Launch, Support). The strategy phase produces a detailed project plan, technology recommendations, architecture overview, and a formal proposal with pricing.
The strategy phase document references the discovery call notes constantly. When we recommend a particular technology stack, we tie it back to the integration requirements from Question 5 and the long-term vision from Question 7. When we propose a phased approach, we reference the budget and timeline from Question 4.
What We Have Learned From Running This Process
After running this same seven-question framework across 11 delivered projects, here are the patterns we have observed:
The strongest projects come from clients who answer all seven questions confidently. This does not mean they have all the answers figured out perfectly. It means they have thought about their problem, their market, their constraints, and their goals before getting on the call.
Question 1 predicts project success more than any other. Clients who can articulate a clear, specific problem tend to make better decisions throughout the project. They evaluate features against the problem. They resolve design debates by asking "which option better solves the problem?" The problem statement becomes a decision-making tool.
Question 6 predicts project smoothness. A single empowered contact with clear authority is the single biggest predictor of an on-time, on-budget project. Committee decision-making is not inherently bad, but it requires explicit process design to prevent delays.
Budget and timeline conversations (Question 4) have become easier over time. In our early days, this was the most awkward part of the call. Now, because we explain why we ask (to provide accurate recommendations, not to maximize our price), clients are more forthcoming. Transparency about our process builds trust.
The pre-call questionnaire saves 10-15 minutes on the call. Before we introduced the WhatsApp pre-call questionnaire, we spent the first 15 minutes of every discovery call on basic context that the client could have provided asynchronously. Now we start the call already knowing the basics and can go deeper on each question.
A Note on Honesty
We have turned down projects after discovery calls. Not many, but some. When the red flags are too significant (no budget clarity, no decision-maker engagement, a problem that does not actually need custom software), we say so. We would rather lose a project than deliver something that does not solve the client's actual problem.
This is not altruism. It is self-interest. Our reputation is built on successful projects. A project that fails because the fundamentals were wrong from the start damages everyone involved.
The seven questions exist to ensure that when we say yes to a project, we have the information we need to do excellent work. That is what the discovery call is for. Not selling. Not impressing. Understanding.
If you are considering working with CODERCOPS, now you know exactly what to expect on your first call with us. You can book a discovery call through the contact form on codercops.com, and you will hear from us within 24 hours via WhatsApp with a Calendly link. Come prepared with answers to these seven questions, and we will make the most of our 45 minutes together.
Comments