Hacklipse — Sales IQ

A sales rep on a call cannot take notes and listen at the same time. The pitch for Sales IQ was that the browser is already hearing the conversation, so it may as well summarise the customer while the rep keeps talking. This was the Hacklipse 4.0 build — and the direct ancestor of VendIQ, which took the same idea and put a real inference pipeline behind it.

The bet was narrow on purpose. There are a dozen hard problems in a live call assistant — telephony integration, diarisation, sentiment, a knowledge base, latency, a place to put all of it — and a weekend buys you one. The one worth buying was whether speech could round-trip through a model and back onto the screen fast enough to still be about the sentence the customer just said. Everything else got stubbed hard enough to demo and no harder.

What got built in the hackathon window

• Continuous browser transcription. The React app grabs window.SpeechRecognition || window.webkitSpeechRecognition, sets continuous: true and interimResults: true on en-US, and reassembles the transcript on every onresult by mapping over e.results and joining the alternatives. Partial text lands on screen as the customer speaks, not after they stop.
• Gemini summarisation. The transcript is appended with an explicit instruction to summarise it for the sales representative, then sent to gemini-pro. There is a 20-character floor so a stray cough does not burn a call. The version that actually ran in the demo skips the SDK entirely and POSTs to the generateContent REST endpoint with a {contents: [{parts: [{text}]}]} body, asking for the summary in points and one closing line on the customer's mood.
• A recommendation panel that renders whatever comes back, styled to sit next to the live transcript rather than in a separate tab, because a rep is not going to switch tabs mid-call. It appends rather than replaces, so the panel reads as a running commentary over the call.
• Auto-restart loop. Recognition is kicked off on load rather than requiring a button press, and the shell's onend handler sends the finished utterance for summarisation and then immediately re-arms the recogniser. That recursion is what makes it feel continuous: the mic is live from the moment the screen opens and stays live without anybody touching it.
• A call queue and sentiment strip down either side — recent callers with accept and decline actions, and an emoji sentiment readout.
• A marketing shell in static HTML: a jQuery slide-toggle nav bound to the hamburger, a resize handler that clears the inline style once the window is back above 320px, and Materialize pulled from a CDN, over a hand-written stylesheet shared with the app screen so the demo could open on a landing page and walk straight into the product.

Two builds of the same screen

The repository holds the idea twice, and the split is the most instructive thing in it. There is a vanilla shell — one HTML file, one stylesheet, one script — and a Create React App port of the same layout. They share no code. The stylesheet was copied across verbatim, and roughly half the shell's body is the standalone script pasted inline, with the two copies already drifting apart by the time the weekend ended.

The port is the prettier one and the less functional one. Its components are clean — a Call row, a CallsList that fakes an API call by setting a literal array inside a useEffect, an Emoji, an EmojisList — and its Gemini function is written, complete with the length floor, and then never called, because the one line that would have invoked it sits commented out in the onend handler. The shell is the ugly one that works: implicit globals, a recursive restart with no stop condition, and a catch block that paints the word "Analyzing" over the panel so an API failure is indistinguishable from progress. That is the correct order of priorities for a weekend and the wrong one for anything after it.

What is honest about it

The recent-calls list and the sentiment strip are hardcoded arrays in the source. The sentiment strip is not analysis at all — it is a static three-row legend of a happy, a sad and a neutral face, and the only sentiment anything produces is the sentence the prompt asks Gemini to append. There is no call backend, no telephony, no persistence, no auth, and the Gemini key is inline in both copies and ships to the browser. The Accept and Decline buttons in the React port have no handlers. The nav is six list items that are not links. The stylesheet contains no media queries, so the responsive behaviour the jQuery implies never fires.

Roughly 800 lines of hand-written code, closer to 550 once the duplication is removed, and every line of it uncommitted — the repository's only commit is the one Create React App makes for you.

That was the deliberate trade: with a weekend, the one thing worth proving is that speech-to-summary can round-trip fast enough to be useful mid-conversation, and everything around it can be a stub that sells the idea to a judge.

Where it went

The parts that were stubs here are exactly what VendIQ built for real. The hardcoded call list became a native Android receiver on PHONE_STATE that pushes a connect event the moment the handset rings. The static emoji legend became a Flask service scoring every finished sentence and raising a separate sarcasm flag. The single browser-to-model round trip became two Go WebSocket servers with a hub that fans state out to every subscriber. And the summarisation prompt, which here is one instruction appended to a transcript, became a recommendation path with a second provider behind it.

Sales IQ is the version where the concept was still cheap enough to throw away, and it earned the follow-through.