The Demo That Raised the Round.
An AI CCTV startup had working detection and no way to show it. We designed the command surface that carried the product into investor meetings — and the round closed on it.
Argu started from a founder question: AI is everywhere, so what if it could watch the cameras? By the time FrixB came in, detection already worked — but the interface didn't make that legible to anyone who hadn't built it. We ran ground-level UX research with security operators, designed the full product surface, and built the Phase 1 front-end. The result became the artefact the founders raised on.
$1M+ seed
Raised on the product demo we designed
4 threat types
Fire, accidents, gun-firing and motion in one feed
Research → build
UX research, design and Phase 1 front-end
A human can't watch every camera. The interface has to.
A single site generates around 143 events in a day — overwhelmingly routine motion, occasionally a fire or a weapon. On a wall of live feeds, the one event that matters is statistically invisible, and the operator who misses it is blamed for a failure the interface caused. Detection was solved. Attention wasn't.
- Ranked the feed by severity, not by camera: Operators scan for what is wrong, not for where. We inverted the default grid into a prioritized event stream ordered by threat class, so the worst thing on site is always the first thing on screen.
- Made the AI show its reasoning: Every detection surfaces what triggered it and where. Operators reject automation they can't audit, visible reasoning converts a black box into a colleague.
- Gave operators control of their own false positives: A zone editor lets sites exclude the areas that generate noise. Tuning belongs to the person who lives with the consequences, not to a support ticket.
- Designed the demo and the product as one thing: If an operator grasps it in seconds under pressure, an investor grasps it across a table. The same clarity served both audiences without a separate pitch build.
Research with working security operators came first, then the product surface, then the Phase 1 front-end, carried by one team so the reasoning behind each decision survived into shipped code. AI assists the mechanical early passes; the judgement calls and the final craft stay human.
A severity feed, not a camera grid.
The camera grid is the category default and the thing every buyer expects to see, which is exactly why we rejected it. A grid asks the operator to do the detection the AI already did.
Trade-off: we gave up spatial familiarity, so we layered the site map underneath for operators who think in geography.
A command surface that reads itself.
A prioritized event feed across four threat classes, with detection reasoning exposed inline, an operator-controlled zone editor, and a site view underneath.
Built responsive, with Phase 1 front-end delivered by our engineering team so the designed behavior survived into the shipped product.
A product that closed a round.
Seed raised: The founders closed $1M+ with the demo we designed as the primary artefact.
Detection made legible: Four threat classes readable in one prioritized surface.
Design survived to production: Phase 1 front-end built by the same team that designed it.
Learnings & Next Steps
Designing for an operator under pressure and designing for an investor across a table turned out to be the same brief: make the intelligence visible in the first second. The open question is how the severity model holds as threat classes expand beyond four — the ranking logic will need to become configurable per site before it scales.
“Add a line from Ido / Argu AI here, even a short note works.”
★★★★★
Have a product that works but doesn't show it yet?
Work with Us
Book a Strategy Call