# Discovery calls for solo developers: what to ask, what to write down, what to send after > For freelance developers and small consultancies who sell their own work on Google Meet, Microsoft Teams or the phone: six question areas for a discovery call, what to write down in the client's words, how to capture decisions and next steps with owners, the same-day follow-up email, and turning the notes into a proposal. Then how TrackHeros summarises the call and answers questions about it. Canonical: https://trackheros.com/blog/discovery-call-notes-solo-developer/ Updated: 2026-09-02 A discovery call is where a solo developer finds out whether a project is real, what it actually needs, and whether the two of you should work together. Ask six kinds of question, write down the client's own words on the problem, the budget and the timeline, and send a short summary the same day, before the proposal. This guide is for freelance developers and small consultancies who sell their own work, on Google Meet, Microsoft Teams or the phone. ## What should you ask? You do not need a script. You need six areas covered, in roughly this order, with one good question each and the patience to let the answer run. | Area | A question that works | What you are listening for | | --------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | The problem | "What happens today that made you look for help?" | A concrete event, not a wish list. "The report takes three days" beats "we want to modernise" | | Current state | "What is in place now, and who built it?" | Systems, versions, and the person who will be defensive about it | | Constraints | "What can't change?" | Stack, hosting, compliance, a launch date tied to something external | | Budget and timeline signals | "Is there a number this has to fit inside, or a date it has to be done by?" | A range, a quarter, a comparison with something they paid for before | | Decision process | "Who else needs to be comfortable with this before it goes ahead?" | Whether you are talking to the decider, and how many proposals they are collecting | | Success criteria | "Three months after launch, how will you know it worked?" | Something measurable, or the admission that nobody has decided yet | The budget question makes new freelancers nervous, so ask it plainly and early enough that there is time to recover if the answer is a surprise. A client who has no number yet is not a bad sign. A client who will not tell you whether one exists is. Leave time at the end for "what haven't I asked?" It is the question that most often produces the real constraint. ## What do you write down verbatim, and what do you summarise? Write down verbatim anything that will end up in the proposal or the contract: - Numbers: budget signals, dates, how many people use the system, volumes, how long the current report run takes. - Names: systems, vendors, the people who own things, the person who will sign. - The sentence in which they describe the problem. Their words, not yours. - Anything that sounds like a commitment, from either side. Summarise the rest: the history of how they got here, the tangent about the previous developer, and your own explanation of how you would approach it. You will remember what you said. You will not remember exactly how they said it, and exactly how they said it is what makes a proposal land. A proposal that opens with the client's own description of their problem gets read to the end. If you are on a call, type only the verbatim lines and let the rest go. If a notetaker is recording, tell the client and type nothing at all. ## Capture decisions and next steps with owners There are decisions on a discovery call, even though nobody calls them that. "Start with the API, the dashboard later." "The existing database stays." "We'll skip the mobile app for the first release." Write each one as a sentence, past tense, so that the proposal and the call agree. Then the next steps, each with an owner and a date: | Next step | Owner | By | | -------------------------------------------------------------- | -------------- | ------------------- | | Send read access to the repository and the staging environment | Client (Nadia) | Friday | | Send a written proposal with two options | You | Tuesday | | Confirm whether the October date is fixed | Client (Nadia) | Before the proposal | Say them aloud at the end of the call. "So, you'll send the repo access by Friday and I'll have a proposal to you by Tuesday" takes ten seconds and turns a pleasant chat into a process. ## What do you send the same day? The follow-up email is not the proposal. Its job is to prove you listened, and it should go out within a few hours, while the call is still fresh on their side as well as yours. Under two hundred words, in this order: 1. One line of thanks. 2. "What I heard": three to five bullets, in their words, on the problem, the constraints and the success criteria. 3. What was decided together. 4. Next steps, with owners and dates, copied from your notes. 5. The one question you forgot to ask. Then stop. No pricing, no architecture, no links to your portfolio. If they reply correcting a bullet, that correction is worth more than the whole call, because it is the thing you would have got wrong in the proposal. ## How do you turn the notes into a proposal? Almost every section of a proposal maps to one line of the discovery notes, which is why the notes are worth taking properly. | Proposal section | Comes from | | -------------------------------------------------------- | --------------------------------------------------------------- | | Problem statement | Their verbatim description of the problem | | Scope, and what is out of scope | Current state plus constraints, and the decisions from the call | | Approach | Your summary of what you said, tightened | | Timeline | Their timeline signal, and the external date if there was one | | Options and pricing | Their budget signal tells you which option to lead with | | Acceptance criteria | Their success criteria, made measurable | | Who it is addressed to, and how many revisions to expect | The decision process | Keep the discovery notes next to the proposal in the client's folder. At the kick-off, when scope starts to drift, "on the first call you said the dashboard could wait" is the sentence that keeps the project on its feet, and you can only say it if you wrote it down. If the prospect becomes a client, the notes are the first entry in a history that will run for months; keep them where the rest of that client's meetings will live, and nowhere else. ## How TrackHeros does it TrackHeros summarises a discovery call with its Project meeting profile: a summary, the decisions, discussion by topic, milestones with dates, and action items with an owner and a due date. The owner is the speaker's name as heard, and due dates are kept verbatim ("by Friday") and resolved to a date. The agenda comes from the invitation, or is reconstructed from the conversation and marked as such. After the call, you can ask the meeting a question in plain language: "what did they say about budget?" The answer comes back with a citation to who said it and when, linked to the moment in the recording, so the figure that goes into your proposal is the one they said rather than the one you remember. There are no credits and no limits on asking. The summary exports as PDF or copies into an email as formatted text. Each prospect can be its own client workspace from the first call, and a meeting that arrives without a client goes to an "Unassigned" workspace with the same rules. Syncing to a CRM, sending follow-up emails automatically and a dedicated sales profile are not yet available; the Project meeting profile is what a discovery call uses today. The sales use case is at [/for/sales/](/for/sales/), asking questions of a meeting at [/features/ask-your-meetings/](/features/ask-your-meetings/), and the minutes document at [/features/meeting-minutes/](/features/meeting-minutes/). ## Not yet available - Sync discovery notes to a CRM — not yet available - Send follow-up emails automatically — not yet available - A dedicated sales summary profile — not yet available ## Frequently asked **Should I ask about budget on the first call?** Yes, plainly and early enough to recover if the answer is a surprise. Ask whether there is a number the project has to fit inside or a date it has to be done by. A client without a number yet is normal; a client who will not say whether one exists is the warning sign. **What is the most important thing to write down on a discovery call?** The client's own description of the problem, verbatim, followed by every number, date and name. Those lines become the proposal's problem statement, scope and timeline. Everything else, including your own explanation of your approach, can be summarised. **When should I send the follow-up email after a discovery call?** The same day, within a few hours. Keep it under two hundred words: what you heard in their words, what was decided together, next steps with owners and dates, and the one question you forgot. It is not the proposal; its job is to prove you listened. **Can I turn discovery call notes straight into a proposal?** Nearly. Each proposal section maps to a line of good notes: the problem statement from their words, scope from current state and constraints, timeline from their signal, acceptance criteria from their success criteria. Write the notes with that mapping in mind and the proposal is mostly assembled. --- TrackHeros is in private beta. Early access: https://trackheros.com/#early-access