How to Vibe Code an Internal Sales Enablement Dashboard

Building an internal sales enablement dashboard used to mean either a proper engineering project or settling for whatever view a conversation intelligence platform gave you. Vibe coding tools have changed the frontend half of that equation. What they haven’t changed is the data problem: generating the typed, consistent call fields a dashboard actually needs requires a structured extraction layer, and that is where Semarize fits in. The two parts of the build are genuinely separate, and understanding which tools handle which part is what makes the whole thing achievable in an afternoon.

The division of labour is straightforward. Semarize handles call analysis: you define what to extract using Kits and Bricks, the API runs against every transcript and returns typed JSON, and that JSON lands in a data store your dashboard can query. A vibe coding tool builds the frontend: you describe the table and filters you want, the AI generates the interface, and you iterate until the manager can answer their questions from it directly. Neither half is especially hard once you understand what it is responsible for.

What Semarize does: structured call analysis at the field level

The reason a vibe-coded frontend is achievable at all is that Semarize returns typed, versioned fields rather than prose summaries. Prose summaries are readable but not queryable: you can’t filter 200 calls by whether the buyer confirmed a timeline if that information is buried in a paragraph. Typed boolean fields can be filtered, counted, charted, and used to trigger automations. That is the output Semarize produces, and it’s what makes the dashboard layer possible.

The extraction schema is configured in Semarize using Kits and Bricks. Kits are versioned collections of Bricks, each of which defines one field: what to extract, what type to return it as, and the evaluation criteria that determine the output. A boolean Brick for “buyer confirmed timeline” returns true or false for every call that goes through the pipeline, grounded in the specific transcript quote that justified the result. A score Brick for “discovery completeness” returns an integer on a defined scale, produced by the same rubric whether the call was 20 minutes or 90. Because the Kit is versioned, the JSON from Monday's call has the same field names and types as Thursday's, and the same as next month's.

That consistency is what separates a dashboard that works from one that requires constant maintenance. When the schema is defined in Semarize, the outputs don’t change unless you change the Kit. The vibe-coded frontend doesn’t need to handle variable field shapes, missing keys, or model outputs that drifted between runs. It queries a store where every row has the same columns, and that is a problem a vibe coding tool can handle easily.

Designing the Kit: what to extract and why

A Kit built for a sales enablement dashboard needs fields that are useful to aggregate, not just to read in isolation. The fields that work well are booleans, integers on defined scales, and short extracted strings such as the specific objection the buyer raised, verbatim from the transcript. Prose summaries are useful for reviewing a single call, but not for comparing 200, and they can’t be filtered or charted.

For most sales enablement dashboards, a starting Kit covers five dimensions. Discovery completeness as a score out of 10, with the criteria tied to the team's actual discovery framework rather than a generic checklist. Buyer pain articulation as a boolean, true only if the buyer named a specific, quantifiable problem during the call. Next step confirmation as a boolean, true only if a next step was agreed with a named owner and a date. Objection raised as a boolean, with the objection text extracted as a companion field. And an overall call quality score that reflects the above. That is enough to show coaching priorities by rep, flag deals missing key signals, and let a manager understand a week of calls without listening to any of them.

The evaluation criteria for each Brick are what determine whether the output is reliable. “Did the rep ask good discovery questions” isn’t a testable criterion and produces inconsistent outputs. “Did the rep ask at least three open questions that connected the prospect's situation to a specific business outcome” is. One hour spent writing tight criteria before running the Kit at scale prevents a day of debugging after the fact. As the Bricks and Kits evaluation guide covers in detail, the schema is the variable that determines whether the pipeline produces useful signals or noise.

The automation bridge: webhook to Semarize to data store

The pipeline that connects call recordings to the dashboard has three steps. A call ends and Zoom or Teams delivers the transcript via webhook to an automation platform, typically n8n or Make. The automation passes the transcript to the Semarize API with the Kit code, and the scored JSON comes back: typed fields, confidence levels, and the transcript quote that grounded each output. The automation writes those fields to a data store the dashboard can query: a Postgres table, an Airtable base, or a simple structured endpoint.

No rep involvement is required at any point in this sequence. The pipeline runs automatically between the call ending and the fields appearing in the store, and the whole thing completes within minutes. The Make integration and the n8n connector cover the webhook setup in detail: a Zoom or Teams trigger, a single POST to the Semarize API, and a write step to the data store of your choice. The same pipeline that feeds the dashboard can simultaneously write enriched fields to Salesforce or HubSpot, so the extraction runs once and serves multiple systems.

Choosing a vibe coding tool for the frontend

With the scored fields in a queryable store, the frontend is genuinely a vibe coding problem: describe what you want, let the tool generate it, iterate until it works. The four tools most commonly used for this kind of internal build are Lovable, Bolt, Replit, and Base44, and they suit slightly different setups.

Lovable generates full-stack React applications from a prompt and connects directly to Supabase for the backend, which makes it a natural fit if you are storing the Semarize outputs in a Supabase Postgres table. The generated code is readable and editable, and the Supabase integration means the data layer is handled without any manual wiring. Bolt, built by StackBlitz, runs a full development environment in the browser and is strong for teams who want to stay close to the code: you describe the interface, the tool generates a working React or Next.js app, and you can inspect and modify every file it produces. Replit provides a hosted coding environment with an AI agent that builds and deploys apps from a description, and the built-in hosting means you don’t need to configure deployment separately. Base44 is specifically positioned for internal tools and dashboards, with a generation model that produces table views, filter controls, and detail panels without needing to describe each component individually.

For most teams building a call scoring dashboard, Lovable with Supabase or Base44 require the least configuration. Bolt and Replit give more control and are better suited to teams who want to extend the dashboard into something more custom over time. The choice matters less than the prompt: all four tools produce better output when the data structure is described precisely.

Building the frontend: what to prompt and what to expect

The frontend description needs to match the data structure that Semarize produces. A prompt that says “build a sales dashboard” produces a generic template. A prompt that says “build a table with one row per call, columns for rep name, call date, discovery score out of 10, buyer pain confirmed shown as a green tick or red cross, next step confirmed shown the same way, and an objection field showing the extracted text or blank if none; with filter controls for rep and date range; and a row click that opens a panel showing the evidence quote for each field” produces something buildable and specific. The more precisely you describe the Semarize output schema in the prompt, the less iteration the frontend requires.

The iteration pattern that works is to build in layers rather than in one prompt. Get the table rendering the right rows and columns first, confirm the data is reading correctly from the store, then add the filter controls, then add the evidence panel. Each layer is a contained prompt, and the earlier layers are easy to validate before adding complexity. Trying to describe the complete interface in a single prompt produces code that is harder to debug than building it incrementally.

The end result is a dashboard that answers the questions that previously required listening to calls: which reps are consistently missing next step confirmation, which deals in the pipeline have no buyer pain articulation on record after three calls, and whether last month's training programme produced a measurable change in discovery scores. Those are questions a manager can answer in seconds from the table view, and the transcript evidence behind each field is one click away.

Where to start

Start with one Kit in Semarize, one rep, and one week of calls. The goal of the first pass is to confirm the pipeline runs end to end and the fields in the data store match what the Kit defines. One week of calls from one rep is enough to validate that the booleans are resolving correctly and the scores are calibrated to the team's standards. Extending to the full team after that is a configuration change: the same webhook trigger, the same Semarize API call, the same data store write. The dashboard doesn’t change; the data grows.

The most common issue on the first pass isn’t the pipeline or the frontend but the Brick criteria in the Kit. If a boolean resolves to true on calls where the condition clearly wasn’t met, the criterion is too loose. If it resolves to false where the condition was clearly met, it is too strict. A calibration pass, reviewing the first week's outputs against the actual transcripts and adjusting the Brick definitions in Semarize until they match what a human reviewer would produce, is the step that turns a working pipeline into a reliable one. After that, the dashboard surfaces real signal, and the build is worth the afternoon it took.

Semarize turns call transcripts into the typed, versioned fields your dashboard depends on, with no manual step between the call ending and the data appearing.

Start building →

Common questions