From messaging prototype to iOS MVP: the backend behind Tomo AI

Staying on top of daily work meant bouncing between an inbox, a calendar, and a task list all day, and Tomo AI is JIA NOMADS’ answer to that: a contextual AI assistant that turns inbox and schedule activity into clear, actionable priorities, so the user works from one place instead of three.

An assistant like that is a backend problem before it is an interface problem. The judgment it sells, what to surface now, what to snooze, what an email means for the calendar, has to live somewhere that outlasts whichever surface the user happens to be talking to. Get that wrong and every new screen means rebuilding the product’s brain.

We built the intelligence as one agentic backend, with a skill per workflow domain, rather than as features wired into an app. The orchestrator composes task, email, and calendar skills, which is what lets one system read what is piling up and hand back priorities instead of another list to manage.

The division of labor followed the same line. Jesús built the agentic-orchestration backend; the client’s product team built the user-facing apps. And the product took shape in two passes: first as a messaging assistant users could talk to from apps they already had, later as a native iOS app.

A messaging-first Tomo. Users onboarded through a React app: connect Google Calendar and Contacts, share a phone number, and start chatting with Tomo over Telegram or Slack. Account data and OAuth tokens lived in Supabase, and calendar re-auth plus event creation supported the messaging workflow, so an expiring token was a handled state rather than a dead end, and a conversation could finish as a real event on a real calendar.

An agentic-orchestration backend. Skills drive the task, email, and calendar workflows. That is the layer that turns inbox and schedule activity into the clear, actionable priorities the product promises, and it is the part of Tomo that Jesús built.

A Flutter/FlutterFlow iOS MVP. The product team shipped Tomo as a native app: auth and onboarding, a task-focused homepage with guided walkthroughs for the core choices (prioritize versus snooze), Focus, Digest, and Task views, and email preview with Google integrations.

Tomo went from prototype to shipped iOS MVP with its intelligence living behind the interface rather than in it: two built iterations, three workflow domains, one backend driving them.

No product-side figure came with this engagement, so none appears here. The metrics strip counts what was built because counting is the honest version of measurement when nobody handed you a dashboard, and inventing an accuracy or adoption number would be the easiest lie on this page to tell.

What the engagement evidences is the build’s shape. The walkthroughs, the views, and the email preview all changed between iterations; the workflows the product runs on did not have to be reinvented to survive the move from a chat window to a native app.

A contextual assistant lives inside its user’s accounts, and account access decays. Tokens expire, calendar scopes need re-granting, and a product whose whole promise is “stop switching apps” cannot answer an expired token by kicking the user out to fix it. That is why calendar re-auth was built as part of the messaging workflow itself: the failure mode of integration is a designed-for state in this product, not an error page.

Turning email and schedule activity into priorities also means making calls on the user’s behalf, and users do not extend that trust by default. The MVP’s guided walkthroughs for prioritize versus snooze exist because the interaction is genuinely new; an assistant that decides things needs to teach the deciding, not just perform it.

One honest limitation, for anyone reading this to judge the fit. This page describes what shipped and what it does; no usage, accuracy, or retention figures were recorded for the product side, and the MVP’s life after this engagement is not something this study claims to know.