← Back to projects
ContributorTeam project · In active development
Visit site ↗

An AI platform that matches people on who they actually are, not what they post. I'm one of the engineers on it: I built the Expo mobile app end to end, plus thread and chat management on the web client and fixes in the Python agent layer. The product is developed under Cracked Lemonade Stand and does not belong to me.

React NativeExpoTypeScriptNext.jsPythonLangGraphFastAPIRustPostgreSQL

Trybe

The problem

Most social platforms optimise for attention. Trybe optimises for depth: an AI "Gatekeeper" runs a therapeutic intake interview, builds a living Soul Document from it, scores how genuinely self-aware someone is, and matches on that instead of on a profile picture. That thesis needs a lot of machinery behind it, and none of it is worth anything if people can't get through the front door on their phone.

My role

Contributor, not owner. Trybe is developed under Cracked Lemonade Stand, where I have worked as a remote engineer since 2023. The architecture, the Rust services, and the matching engine were in place before I joined the project; I came in as an engineer on the client side and the agent layer.

What I actually built:

  • The entire Expo mobile app, from expo init onward. Routing, the auth stack (login, forgot password, reset), an eleven-screen onboarding flow, the chat interface, thread management, blind rooms, and the shared component and theming layer underneath all of it.
  • Thread and chat management on the Next.js web client: the thread drawer and history view, async message sending, and pinning, renaming, and deleting threads.
  • Auth and error handling across both clients: session handling and redirect logic on token refresh, and an error humanizer that turns raw API failures into something a person can read.
  • Fixes in the Python agent layer: restored memory recall in Aria, the matchmaker agent, by removing a prompt-driven matching path that was overriding it, and fixed dependency resolution in the agents Dockerfile.

Everything below describes the system I was working inside. The parts I wrote are the ones listed above.

Key decisions

Mobile-first onboarding, built as a flow rather than a form. Trybe's whole premise is that the intake interview is the product. Eleven screens (identity, purpose, values, causes, intent, archetype, interests, social preferences, horizon, invite code, account creation) each get their own screen with a shared step-shell, so the sequence can be reordered or extended without touching the individual steps. Onboarding options live in one constants file, not scattered through components.

Deferred invite code consumption. Codes were being consumed at the point of entry rather than at account creation, so any failure later in the flow burned the code and hit a constraint violation on retry. Moving consumption to the end of the transaction fixed a class of bugs rather than one symptom.

Errors that read like sentences. humanizeApiError sits between the API and both clients. Auth and onboarding are where users are least invested and most likely to bail, so a raw 422 there costs you the user.

Stack

  • Mobile: React Native 0.86 + Expo 57, expo-router, TypeScript, NativeWind. expo-secure-store for tokens.
  • Web: Next.js 15 (App Router, Turbopack) + TypeScript.
  • Backend: Rust (Axum, Tokio, SQLx), split into gateway, auth, matching, and messaging services behind Caddy.
  • AI layer: Python (FastAPI, LangGraph, Deep Agents). DeepSeek for the LLM, Gemini for 3072-dimension embeddings, Mem0 for cross-session memory.
  • Data: PostgreSQL 16 with row-level security via PgBouncer, Qdrant for vector search, Neo4j for the concept graph, Redis for cache and pub-sub.

Challenges & solutions

Building a client against a system still being built. The Rust services and the agent layer were moving while the mobile app was going up. Keeping the app's data layer in hooks (use-chat, use-conversations, use-referral-code, use-blind-room) meant that when an endpoint changed shape, the change landed in one file instead of across every screen that touched it.

Debugging an agent that had quietly stopped remembering. Aria's memory recall looked fine in isolation but wasn't surfacing in conversation. The cause wasn't the memory layer at all: a prompt-driven matching path added later was taking precedence over it. Removing that path restored recall. Agent systems fail like this a lot: the broken component is usually not the one behaving oddly.

Status

In active development. The platform is not launched. Auth, the Gatekeeper interview, Soul Documents, personality analysis, and the suggestions feed are complete on the backend; Tribes and encrypted messaging are scaffolded; KYC and the Tender blockchain integration are still ahead. The mobile app I built covers onboarding through chat and is being iterated on alongside the rest of the team's work.