TiAiMe went from research deck to a voice agent investors could talk to

The situation

The hard parts of building an agent that learns about you

• Turning open conversation into structured actions

  TiAiMe had to hold a natural conversation and come out the other side with something concrete: an event created, a routine captured, a participant added, a schedule coordinated. Understanding the sentence is the easy half. Mapping it onto the right action, with the right people and the right time, against a calendar that already has things in it, is the half that breaks.

  The agent was given access to the user's context and tools during the conversation, not after it. When someone asks to plan something, TiAiMe can check the calendar, spot conflicts, and see what else is already planned while it's still talking, rather than accepting the request and failing later.

• Memory that survives the end of the conversation

  Most assistants start from zero every time you open them. TiAiMe couldn't, because the whole premise is an assistant that knows you well enough to save you time.

  After each conversation, a pipeline takes the transcript, analyses it, categorises what matters, and converts the useful parts into memory. That memory becomes context for the next conversation. On top of it, the team builds a personality profile for each user: what they like, how their day usually goes, their habits and preferences, learned from conversations, events, and plans inside the app. This is the part RaftLabs hadn't built on any previous project, and it's what separates TiAiMe from a voice interface bolted onto a calendar.

• Conflict detection across two calendar providers

  TiAiMe syncs Google and Outlook calendars, pulling in recent and upcoming events so it can spot clashes and learn what someone is already committed to. Conflict detection is the part users notice, and it's also the part that fails quietly: a missed clash looks identical to no clash until someone double-books.

  The payoff showed up in beta. Users caught duplicate calendar entries they hadn't spotted themselves, which is the agent doing work the person didn't think to ask for. That only happens if the sync is ingesting enough history to reason about the week rather than checking the next free slot.

• Family permissions, privacy, and who gets to see what

  A family coordination product runs straight into questions a solo productivity app never asks. Who can view a family event? Who can change it? Does someone's availability leak when the system suggests a time? What can the AI do on its own, and when does it need consent?

  The documented direction was privacy first: events stay private by default, and TiAiMe can identify possible availability without exposing anyone's real schedule. The original vision also reached across generations, with different considerations for children, adults, and older family members, which adds access rules on top of the privacy model rather than beside it.

• A voice product that still works when you don't want to talk

  Voice-only was on the table and the team argued against it. People use a product like this on a bus, in an open-plan office, next to a sleeping child.

  TiAiMe was built hybrid: you can create an event by speaking, or you can review, edit, and complete the same action manually in text. The voice scope for the MVP was also deliberately narrowed to realistic family scenarios rather than every capability in the concept, so the thing being tested was a coherent experience instead of a demo that collapses outside the happy path.

1. The vision was split into an MVP and everything after it

   Broader social coordination, community features, goal management, proactive automation, and agent-to-agent coordination were all documented and deferred. What stayed was the set of features that demonstrate the core idea to beta testers and investors. The founder brought many ideas; the team pushed back on building all of them first, and worked with him to decide which ones prove the concept.

2. Login and invitations were narrowed on purpose

   The MVP shipped with selected Google and Apple authentication rather than every login method, and email invitations for people not yet on TiAiMe. SMS and WhatsApp invitations were pushed to a later phase. Neither decision changes what the product proves, and both took weeks off the build.

3. Onboarding was rebuilt after the design phase

   The originally planned onboarding flow didn't hold up once the team reviewed it in detail, so it was substantially revised rather than shipped as designed. Catching that in design rather than after launch is the reason a discovery and design phase existed at all.

4. Why the founder picked RaftLabs

   James found RaftLabs through a combination of online search and a referral, and gave four reasons for choosing the team: the pricing fit his budget, the culture was a fit, the value for cost was right, and the company values aligned. For a founder spending a first real budget on a concept that only exists on paper, those are the reasons that matter more than a technology list.

Why we chose this approach

Flutter

One codebase for iOS and Android. On a founder-funded MVP that has to reach beta testers on both platforms, two native codebases would have bought polish nobody was testing for at twice the build cost.

React

The admin panel is an internal tool carrying role-based permissions, audit logs, analytics, and family management. React kept it quick to build and quick to change as the permission model settled.

Google and Outlook calendar sync

Conflict detection is only as good as what the agent can see. Ingesting recent and upcoming events from both providers let TiAiMe reason about someone's week, which is how beta users caught duplicates they had missed.