Soul AI — Case Study

AI therapy and self-care companion. 24/7 conversational support that helps users work through anxiety, relationships, and self-talk patterns. Live at getsoul.ai.

Summary

Soul AI is a mobile-first AI companion in the mental-health and self-care category — users talk to it about anything, the assistant identifies patterns and strengths in the conversation, and surfaces those insights back. topsweteam built and ran the product with a two-person team: a fullstack engineer on the backend and a mobile engineer on the Flutter app. The product is shipped and currently in maintenance.

• Client: Soul AI (getsoul.ai)
• Industry: Mental health / Consumer AI
• Engagement: Dedicated team — 1 fullstack + 1 mobile
• Timeline: Started 18 May 2023, ongoing maintenance
• Team: 1 fullstack engineer, 1 mobile engineer
• Status: Shipped, in ongoing maintenance

Challenge

A consumer mental-health AI product has to be three things at once. The conversational quality has to be high enough to feel useful (not a chatbot novelty); the product has to be careful about the duty of care that comes with the category (no medical claims, sensible defaults around crisis); and on the engineering side, it has to ship at consumer-app cadence on a small team — meaning the cost of every architectural decision matters more than the elegance of it.

Approach

We staffed it as a deliberately small, deeply specialized two-person team. One mobile engineer owned the entire client surface; one fullstack engineer owned the backend and the integration with the model layer. That split — by surface, not by stack — works at this size when the surfaces are deeply different (a Flutter app and an LLM-backed Python service have almost no shared mental model anyway).

• Flutter for mobile. One codebase across iOS and Android with native-feeling animations and conversational UX. Avoids React Native's subtle perf issues on rapidly-updating chat surfaces.
• Python + FastAPI on the backend. Standard fit for an LLM-integrated service; fast HTTP surface, easy to wire to model providers and the orchestration tooling that surrounds them.
• Two specialists, not two fullstacks. Most engagements at this size benefit from fullstack engineers, but for a chat-shaped product the surface complexity on each side is high enough that specialization pays off.

Solution

The product is a conversational AI app: users talk to "Soul" about anything they want; the model surfaces patterns and offers next-step suggestions. The Flutter client handles the chat experience, conversational pacing, and the insights-surfacing screens. The FastAPI backend handles auth, conversation persistence, the model-call orchestration, and the safety conventions appropriate to the category.

Key features shipped

• 24/7 chat with the AI companion
• Pattern recognition and insights based on conversation history
• Modes / topics: anxiety, relationships, self-talk, growth areas
• iOS + Android clients from one Flutter codebase

Outcome

The app shipped and is in maintenance — meaning the build phase is complete and the team is now in steady-state mode keeping it healthy.

• Live consumer AI app on iOS and Android
• Two-engineer build through to production
• Product now in maintenance mode

Tech stack

Backend: Python, FastAPI Mobile: Flutter

What we learned

• For chat-shaped consumer AI products, surface specialists beat fullstacks. The conversational client and the LLM-backend each have enough depth that the context-switching cost of one person doing both isn't worth the coordination saving.
• Flutter is the right call when the chat surface needs to feel like a native app. Subtle perf issues on the chat list view are a real problem in the category, and Flutter has fewer of them than the alternatives.
• Maintenance is a stage, not a downgrade. Treating it as a deliberate phase — with smaller cadence, focused stability work, and clear scope discipline — keeps the product healthy without over-staffing.