CuteHelper
Founder & Product EngineerAI Desktop Companion
CuteHelper is a transparent, always-on-top desktop AI companion built to cut context switching for students and knowledge workers. I own it end to end: the discovery that justified it, the RICE scoring that cut it down, the PRD and architecture that specified it, the Electron application that implements it, and the instrumentation that will tell me whether the core idea holds.
The design principle is “teach, don’t do.” That distinction is the entire product, and it’s also the hardest thing to verify — which is why the metrics matter more here than anywhere else I’ve worked.
- Build available on request
Voice input
ask by speaking
Groq Whisper
speech-to-text on the input path
On-screen context
what’s actually on screen
LLaMA 4 Scout
vision and reasoning
Response surface
teach, don’t do
01 / 09
Problem
Every AI assistant asks you to leave what you’re doing. You switch to a browser tab, describe the thing on your screen in words, wait, read the answer, and switch back — and by then you’ve lost the thread you were holding.
For students and knowledge workers, that switch is the cost, not the answer. The assistant is fast; getting to the assistant is slow.
There’s a second, quieter problem. An assistant that’s good at giving answers is very good at removing the need to understand them. For a student, that’s not a feature — it’s the failure mode.
02 / 09
Goal
Product goal
Reduce the cost of asking to near zero — no window switch, no typing, no describing what’s already on screen — without turning the tool into something that does the work for you.
Success criteria
Because “does it teach?” isn’t directly observable, I defined three proxies and instrumented for them:
- Follow-up rate — a user who asks a second, better question was taught something. A user who takes the first answer and leaves probably wasn’t.
- Average query length — questions getting longer over time suggests the user is engaging with the reasoning, not just requesting output.
- Response gap — how long between the answer and the next action. Too short suggests copy-paste; some pause suggests reading.
None of these is conclusive alone. Together they say something about whether the loop works.
Scope goal
Ship two workflows properly rather than the whole candidate set partially.
03 / 09
Architecture
Interaction layer — always-on-top transparent window
An Electron renderer that floats above whatever the user is working in. Transparency and always-on-top aren’t styling choices; they’re the mechanism that eliminates the context switch. If the companion sits in the workspace rather than beside it, there’s nothing to switch to.
Voice input — Groq Whisper
Speech-to-text on the input path, so asking costs a sentence instead of a window change and a paragraph of typing.
Vision and reasoning — LLaMA 4 Scout
A vision-capable model, so the companion can work from what’s actually on screen rather than from the user’s description of it. This is what makes the voice path viable: “what’s wrong with this?” is only a usable query if the model can see the “this.”
Application shell — Electron, React, TypeScript
Electron for the OS-level window behaviour that a web app cannot do. React and TypeScript for the interface, with types carrying the contract between the audio pipeline, the vision context and the response surface.
Instrumentation layer
Event capture for the three KPIs above, feeding the question of where the “teach, don’t do” loop breaks down.
The system architecture behind this sits in the project’s own PRD, which I authored alongside the user stories and acceptance criteria. This is the layer view.
Screens pending — walkthrough available on request
04 / 09
Key features
Voice-first query
Ask by speaking; Groq Whisper transcribes
Why it survived RICERemoves the largest cost in the loop — typing a description of something visible
Screen-aware context
LLaMA 4 Scout reasons over what’s on screen
Why it survived RICEMakes short spoken queries sufficient; without vision, voice input is useless
Transparent always-on-top window
Companion floats over the active workspace
Why it survived RICEThe context switch is the problem; this is the mechanism that removes it
“Teach, don’t do” response shaping
Responses guide rather than complete
Why it survived RICEThe differentiating principle of the product
Behavioural instrumentation
Follow-up rate, query length, response gap
Why it survived RICEWithout it, there’s no way to know if the principle is working
05 / 09
Technical decisions
Voice-first over a chat window.
The obvious build is a chat box. I chose voice, and it was the decision the whole product hinged on. A chat window reintroduces exactly what CuteHelper exists to remove: you stop, you focus somewhere else, you type. Voice keeps the user’s hands and eyes where the work is. The cost is real — transcription latency, accuracy on technical vocabulary, and the fact that voice is socially awkward in shared spaces. I took those costs because the alternative solved nothing.
Vision model over user-supplied context.
Voice input only works if the query can be short. “Why is this failing?” is a two-second question and a two-paragraph typing job — the difference is whether the model can see the screen. Choosing a vision-capable model made the voice decision viable instead of merely novel.
Electron over a web app.
Transparent, always-on-top, present across every application is not something a browser tab can be. Electron’s overhead is well documented and I accepted it, because the window behaviour is the product.
RICE before writing any code.
I scored the candidate feature set and cut to two workflows. The value wasn’t the ranking — it was having a defensible reason to say no to features I wanted to build. Scoring first meant the scope argument happened before implementation instead of halfway through it.
Instrumenting a principle, not just usage.
Most analytics tell you whether people used the thing. I needed to know whether the thing taught them anything, which isn’t directly measurable. Defining three imperfect proxies and being explicit that they’re proxies was a deliberate choice over picking one metric and pretending it was the truth.
06 / 09
Challenges
Specifying a principle precisely enough to build against.
“Teach, don’t do” is a good sentence and a terrible requirement. Turning it into acceptance criteria — what a response may and may not contain — was the hardest writing on the project, and it’s still the part most likely to need revision.
Measuring something that resists measurement.
There is no event that fires when a user learns something. Every metric available is a proxy, and each one has an obvious alternative explanation. Holding three of them together and reasoning about the pattern is a weaker method than I’d like, and I don’t have a better one yet.
Voice as an input surface.
Speech-to-text on technical vocabulary is unreliable in exactly the situations where a student most needs help. It also assumes an environment where speaking aloud is acceptable — which a library is not.
Being the only reviewer.
Owning product and engineering means nobody catches a bad spec before it becomes a bad build. On UrbanIQ there were ten other people on the project and three roles’ requirements to reconcile against. Here the only external check is the instrumentation, and that arrives after the fact.
07 / 09
Lessons learned
Prioritization is only real when it deletes something.
RICE didn’t tell me what to build; it gave me a defensible reason not to build things. That’s the actual output of a prioritization framework, and I’d been treating it as a ranking exercise before this.
Interaction model is a product decision, not a design detail.
Voice over chat wasn’t a UI preference — it determined the model choice, the platform choice and the entire value proposition. I now treat interaction model as something that belongs in the PRD, not the design review.
A metric you can’t defend is worse than admitting you can’t measure it.
Picking a single number as a stand-in for “does this teach?” would have looked more rigorous and been less honest. Naming the proxies as proxies keeps the reasoning inspectable.
Building what I spec makes me a worse optimist and a better spec writer.
Every requirement I wrote, I paid for in implementation. That feedback loop is the most useful thing about doing both jobs.
08 / 09
Future improvements
Get enough usage data on follow-up rate to say something defensible about whether the “teach, don’t do” loop holds. The instrumentation exists; the reading is what’s outstanding.
Improve transcription reliability on technical vocabulary, which is where voice input fails most often and matters most.
Add a text input path for environments where speaking isn’t viable, without letting it become the default and undo the core decision.
Expand beyond the two RICE-selected workflows only once those two show retention, not before.
Reduce Electron’s memory footprint — an always-on companion that costs the user resources all day is a companion they close.
09 / 09
Technologies used
Named in the résumé for this project
- Electron
- React
- TypeScript
- Groq Whisper
- LLaMA 4 Scout (vision)
- RICE
- PRD Authoring
- User Stories & Acceptance Criteria
- System Architecture
Strongly implied by the work described
- LLM Integration
- Prompt Engineering
- Voice Interfaces
- Context-Aware Systems
- KPI Definition