How to turn client meeting notes into a working prototype

Can you build a prototype from a client call?

Yes, if the AI has usable meeting context and a clear description of what to build. A transcript is an input, not an approved specification. You still need to decide which requests belong in the prototype and how to check them.

Granola’s role is the meeting context. Lovable’s role is the prototype. Your role is confirming the requirements. Keeping those jobs explicit prevents the AI from treating an incomplete summary as a complete product decision.

How should you capture a client call for an AI prototype?

Capture the conversation with an approved tool, then mark the moments that define product behavior. Granola transcribes meetings when you choose to use it; its web notes interface does not capture a new meeting. Arrange the capture before the call and tell participants how you will use the notes.

Official reference: Granola: how meeting transcription works.

During the call, keep short notes on six things: who will use the product, what they must be able to do, the information they need, decisions explicitly made, constraints named by the client, and questions still open. The purpose is to guide the later prototype, not to document every sentence equally.

• Actor: “Our client reviewer needs to see the current deliverable.”
• Behavior: “They should be able to comment and request a change.”
• Uncertainty: “Would email notifications be useful?” is a question, not a confirmed requirement.
• Boundary: “Show the review flow first; billing can wait.”

If Granola is not already approved on the workstation, use our Granola work-laptop requirements guide for installation, audio and network conditions. This article assumes capture is available and concentrates on the build.

Which Granola connector should you use in Lovable?

Use the personal chat connector when you want your own meetings to inform what Lovable builds. Use an app + chat connection only when the application itself needs to read Granola meeting data. These are different access models.

Official reference: Lovable: personal chat connectors and Granola.

Official reference: Lovable: Granola app + chat connector.

Connect your own Granola account for the prototype

1. Open Connectors in Lovable and select Granola.
2. Choose Add connection. If multiple connection types appear, choose Chat connector.
3. Complete the Granola account authorization in your browser.
4. In the project chat, name the meeting by title, date or participant and ask Lovable to identify it before using its content.

If a workspace administrator has disabled the connector, resolve that permission before continuing. Do not substitute a shared API key simply because a personal connection is blocked.

Official reference: Lovable: personal chat connectors and Granola.

Check the Granola access you actually have

Granola Basic provides access to personal notes from the last 30 days through MCP. Some search, folder and transcript tools require a paid plan. Business adds broader note access; Enterprise access depends on workspace controls. Access to a summary does not prove that the full transcript is available.

Official reference: Granola: MCP access, tools and authentication.

For an application that genuinely needs to read meeting data, Granola documents API keys and their scopes separately. Verify those permissions before adopting that architecture. This guide does not require an API key, a custom backend or a public meeting archive.

Official reference: Granola: API keys and note access scopes.

How do you turn meeting notes into a scope the AI can build?

Ask for a requirement table before asking for code. Each row should contain a requested behavior, its supporting source and its validation status. An implementation suggestion can be useful, but it must remain distinguishable from the client’s words.

Use the first prompt after connecting Granola. Replace the bracketed identifiers rather than asking for “the latest call,” which could select another client or another project.

Prompt 1: identify the call and extract the requested behavior

Use my Granola meeting notes as context for a client prototype.

Find the meeting titled [meeting title], held on [date], with [client or participant]. Before using its content, report the meeting title, date and note ID if available. If more than one meeting matches, ask me to select one.

Extract only the requested product behavior. Return a table with:
- requirement ID;
- actor and requested action;
- supporting note or transcript passage;
- source reference;
- status: explicit request, proposed interpretation, or unresolved question.

Keep explicit decisions separate from suggestions. Do not invent deadlines, technical integrations, budgets or performance targets. If you cannot access the transcript, label the evidence as notes or summary rather than quoting it as verbatim speech.

Do not build or change code yet.

If only enhanced notes are accessible, the output should cite those notes as notes. It should not invent a quotation, speaker attribution or timestamp. When a transcript is available, check the original context around any passage used to justify an important requirement.

The documented MCP tools can list and retrieve accessible meetings, and paid plans can retrieve transcripts. They supply context to the assistant; the code generation takes place in Lovable.

Official reference: Granola: MCP access, tools and authentication.

Worked example: turn an agency call into an approval-portal prototype

Illustrative example, not a client test: a small agency wants to show a client a deliverable, collect a comment and receive a revision request. We use invented names and demonstration data. The following short statements are fictional meeting inputs created for this guide.

Notice the gap in REQ-03: the client asks to request a change but does not say who receives it or through which channel. For a visual prototype, you can propose a visible confirmation with simulated data. You cannot truthfully claim that the agency receives an email until email delivery exists and has been checked.

Our recommended first build is narrow: a deliverable detail view, a comment field and a revision-request interaction. That is our proposed prototype scope, not a feature set automatically dictated by Granola.

Should Lovable plan the prototype before writing code?

Yes, when you need to confirm the scope or resolve ambiguous behavior. Lovable’s Plan mode investigates the project and produces a plan for review before modifying code. Use it to separate the confirmed request from the AI’s implementation choices.

Official reference: Lovable: reviewing a plan before code changes.

Prompt 2: propose the smallest useful prototype

From the requirements table we just reviewed, prepare a plan for a small client-review prototype.

Prototype: a deliverable approval portal for an agency.
Approved behavior: show a deliverable, accept a comment, and submit a revision request.
Use synthetic demonstration data. List the screens, the behavior of each control, and which requirement ID each part implements.

Separate:
1. Confirmed scope.
2. Your proposed implementation choices.
3. Questions that need the client's decision.
4. Anything omitted from this first prototype.

For each confirmed behavior, propose an observable acceptance check. Mark those checks as proposed until I approve them. Do not add billing, a CRM, email delivery, authentication or external integrations unless the approved scope requires them.

Ask me to confirm the plan before implementation.

Review the proposed checks as well as the screens. “The client can request a revision” is too vague to verify. A more useful proposed check is: when the explanation field is empty, the request is not submitted and the interface asks for an explanation. The client must confirm that this rule is appropriate; it was not stated in the fictional call.

After confirmation, keep a concise description of the approved purpose and constraints in the project’s knowledge. Lovable documents project knowledge as persistent context. Use a small approved scope rather than depositing the entire client transcript as permanent instructions.

Official reference: Lovable: persistent project knowledge.

How do you build and verify the prototype from the agreed scope?

Build one interaction, inspect it, then continue. Lovable recommends small, specific changes and verification in the preview. A single prompt that creates the portal, authentication, notifications, billing and analytics makes it harder to see whether the original requirement was satisfied.

Official reference: Lovable: building in small steps and testing outcomes.

Prompt 3: implement the approved scope and report what works

Implement only the approved prototype scope from our plan.

Start with the deliverable detail screen and the comment interaction. After that step, summarize what changed, which requirement IDs it covers, and what remains unimplemented. Then add the revision-request interaction as a separate step.

Use only synthetic project names, deliverables and comments. Make clear which interactions are simulated and which persist data. Do not claim that a request was emailed or saved to a server unless that behavior exists and has been verified.

Check the approved acceptance criteria and report each as passed, failed or not tested. Include empty states and missing required input. Do not mark the prototype as production-ready or publish it automatically.

For a later version with a real backend, verify saved data after refresh and test access with different users. Lovable documents these checks for live applications. Do not confuse a convincing demonstration with proof of persistence, isolation or production readiness.

Official reference: Lovable: building in small steps and testing outcomes.

How should you use the next client review to improve the prototype?

Review the prototype against the approved requirements, then record changes explicitly. Ask the client to perform the intended task. When feedback arrives, separate a correction to agreed behavior from a new request.

• Correction: the revision request does not show the explanation in the confirmation, although the approved plan requires it.
• New request: the client now wants email notifications.
• Open question: reviewers need different permissions, but the access roles are not defined.

If the review is captured in Granola, reference that new meeting by its date and title. Ask the AI to propose changes to the existing requirement IDs, list new requests separately and identify contradictions. A newer remark should not silently replace a previously approved decision.

Keep a short decision record outside the raw meeting context: what was approved, by whom, on which date, and which requirements changed. This is our recommended review practice, not a built-in guarantee that either tool tracks client approval automatically.

What if Lovable cannot use the right Granola meeting?

Official reference: Granola: MCP access, tools and authentication.

Official reference: Lovable: personal chat connectors and Granola.

Official reference: Lovable: Granola app + chat connector.

This section covers retrieving context for the prototype. For capture permissions and corporate network restrictions, use the work-laptop guide. For the product’s broader strengths, offers and limitations, use our Granola review.

Questions about building from client meeting notes

Do I need Granola to build from an existing transcript?

No. If you already have usable notes or a transcript, provide that context directly or through an appropriate existing connection. Granola is an option for capturing future calls and retrieving meeting context.

Do I need a Granola API key for the Lovable chat connector?

The personal Granola chat connection uses the MCP authorization flow. The API-backed app + chat connector is a different connection type and requires a Granola API key.

Can I use Granola Basic for this workflow?

Basic can provide personal notes from the last 30 days through MCP. Some search, folder and transcript tools require a paid plan. A notes-based prototype and a transcript-verified workflow have different input requirements.

Will my published prototype expose my Granola chat connection?

The personal chat connector is not included in the published application. Review the generated project separately: that distinction does not guarantee that the AI has not copied meeting details into code, text or demonstration data.

Can a teammate reuse my personal Granola connection?

No. Lovable personal chat connections belong to the user who established them. Teammates connect their own accounts and need appropriate permissions to the notes.

Can Granola MCP build the application itself?

Granola MCP supplies accessible meeting context to the AI client. In this workflow, Lovable plans and implements the prototype from that context.

What should I do when a requirement has no supporting meeting passage?

Label it as an interpretation or an open question and ask the client to confirm it. Do not present it as an explicit request or fabricate a source reference.

Is a prototype generated from a client call ready for production?

Not automatically. Check the approved behavior, data persistence, access controls and relevant deployment requirements before treating it as a live client application.

Sources, scope and verification

This guide was prepared from official Granola and Lovable documentation checked on October 10, 2026. The agency example is fictional. The prompts, requirement statuses and acceptance checks are our proposed method; we have not performed an authenticated end-to-end build or measured time saved. Connector availability and access can change.

• Lovable: personal chat connectors and Granola
• Granola: MCP access, tools and authentication
• Lovable: Granola app + chat connector
• Granola: API keys and note access scopes
• Lovable: building from Granola meeting context
• Lovable: reviewing a plan before code changes
• Lovable: persistent project knowledge
• Lovable: building in small steps and testing outcomes
• Granola: how meeting transcription works

Where marketing pages describe a quick route from a call to an app, this guide adds a scope review. A connector makes meeting context accessible; it does not certify the correctness of a requirement or the readiness of a generated application.