Before bespoke SaaS: what building consumer agents taught us

Editor's note

Updated July 13, 2026. This post first ran on January 1, 2026, as the launch announcement for Hiro, our consumer agent app. Hiro has since been retired, and the launch pitch retired with it. What follows is a rewrite in hindsight: the same product and the same details, reframed as what the work actually was — the B2C investigation we ran before AI Hero became a product team for bespoke, AI-native software — with the lessons stated plainly. Nothing here is a live offer, and the sign-up links are gone; hiro.aihero.studio no longer exists.

What we built

The scenario the whole product was designed around was small: you're walking the dog, you remember you're out of dog food, and you say "add dog food to the grocery list" without breaking stride. No app opened, no menus. By Saturday's market trip the list is complete because you built it in passing, one spoken item at a time.

Hiro was our attempt to ship that as a consumer product. It lived at hiro.aihero.studio (the domain is retired now), and the beta shipped four agents, each with a bounded scope and a small set of operational tools. The grocery agent added items, marked them bought, and organized the list by store section. The todos agent captured tasks with due dates, priorities, and completion. The weather agent answered the practical morning question of long trail or short loop. The intentions agent tracked goals and the daily habits behind them, with a weekly view of what was done and what remained.

Two structural decisions sat under the agents. Realms were isolation boundaries: a personal realm, a shared family realm, a professional realm, each with its own agents and its own data, and no way for one to read another. A family member could work the same grocery list; your journal stayed yours. Sign-in was passwordless from day one, an email OTP with a six-digit code, so there was no password to reuse or breach.

The design stance was the part visitors noticed first. The interface was monochrome, with no animations, no streaks, no badges, and no notifications asking you to come back. We were explicit that the product should not compete for its user's attention. That stance turned out to be the most transferable thing we built, for reasons the persona section below explains.

Voice was the primary interface

Input was voice first, built on OpenAI's Realtime API, with a text field as a first-class fallback. We chose push-to-talk over always-on listening, and the deciding argument was social: a webapp gets used in offices, trains, and cafes, and an explicit trigger is what keeps you from announcing your shopping list to the room. We documented the full decision, down to the pointer-event handling, in the voice-agent series we published in December 2025.

Living with it taught us where voice earns its keep. Capture in motion was the strongest case: hands busy, phone in pocket, one sentence spoken and the item lands on the list. Schedules were the second. Saying "remind me to check the grocery list every Sunday at 9am" beat any form with dropdowns for day, time, and recurrence, which is why routines shipped voice-first in the March 2026 revision. And latency was unforgiving: a voice exchange makes every second of silence feel longer than it is, so tool calls had to be engineered around it — speak early, stream results, cache what you can.

The subtler lesson was that input modality never dictated output format. A spoken question about the weather returned a visual card plus a short spoken summary, because a five-day forecast is scannable and a paragraph read aloud is not.

Cards that changed with the conversation

The screen was not a chat log. When an agent executed a tool, the result rendered as a card (a grocery list, a task list, a forecast), and the card in front of you changed as the conversation moved. Ask about the weather and the weather card appears. Add eggs and the grocery card returns with eggs on it.

The rule that made this coherent: every mutation went through the agent. Tapping a card never called an API directly. The tap sent a message back into the conversation, wrapped in a <ui> tag so the agent knew the command came from a card rather than from speech; the agent executed the tool, and the card re-rendered from the result. Voice, typed text, and card taps were three entrances to the same conversation, and the conversation owned the state. Card buttons carried a deliberately short verb list — Complete, Mark bought, Log dose, Remove. Adding and editing happened in conversation.

Three entrances, one conversation. Every mutation went through the agent, so the card and the transcript could never disagree.

Daily use kept pushing the design toward that model. The original layout treated the transcript as a collapsible drawer, and we found ourselves toggling it constantly; in the January 2026 revision we replaced it with an always-visible conversation panel, because the transcript was how you tracked what the agent was doing, not a history feature. The same revision swapped raw tool names in the transcript ("get_grocery_list") for plain descriptions ("Checking the weather…") and hid tool results entirely, since the card already showed the outcome. By then the mental model had settled: the product was a conversation with a visual surface attached, and voice was one of its inputs.

One persona, written down

The design system had exactly one persona for Hiro, and she was written into the repo: Elise Lindqvist, 34, a UX researcher and part-time ceramicist who wanted, in the doc's words, "the result of a spreadsheet with the effort of a text message." Her line in the persona file was blunt: "If it requires a tutorial, it's too much." The doc listed the five toolkits she would actually touch (journal for 2 AM brain dumps, groceries in real time, weather every morning for the bike-commute call, todos as needed, sleep occasionally) and was honest that the other ten existed because the product adapted, not because Elise wanted them all.

What made the persona operational was the Elise Test, three checks every feature had to pass before merging. Low friction: hands-free or one tap, no deep menus. Anti-hustle: it helps her finish faster, without engineering a new obligation. Vibe-compatible: quiet UI, no red dots, no streaks. If any answer was no, the instruction in the doc was to simplify before merging. The monochrome palette and the refusal of gamification came out of that test; they were persona requirements, and having them written down turned design arguments into checks anyone on the team could run.

My honest read on why the product still didn't survive: Elise is real as a design target and rare as a paying customer, and consumer distribution is a different business from the one we're good at. What survived is the method. Write the persona down and attach a shipping test that can veto features.

What carried into bespoke SaaS

We retired Hiro as a product and kept its findings as practice. The persona file that held Elise now also holds Sara and Marcus, the personas we design Studio software against in the medical and professional realms. The passwordless OTP flow is how sign-in works in Auth, the common service we ship with the software we operate. Realm isolation, built so a shared grocery list could never see a private journal, is the same instinct we now apply to tenant isolation for customers. And the anti-engagement stance transferred whole: software we build for operators competes on how little attention it demands.

The two interface lessons carried furthest. Agents with operational tools and bounded scope are the spine of the software we now design: agents-in-the-loop working alongside a customer's operators, while the customer runs their own workflow. And the conversation-owns-the-state pattern shows up whenever one of our designs mixes talk with a working surface — the operator speaks, types, or clicks, and the record of what happened stays one thread.

If you want the business argument for why we went from a consumer app to building bespoke software for companies, the bespoke SaaS post makes it in full, and the solution page shows what we design, build, host, and operate today. This post is the record of where those instincts came from. If you're building an agent product of your own, the parts worth taking are the written persona with a veto and the conversation that owns the state.