Usora

Inspiration

Usora started with a small, ordinary problem. My girlfriend and I kept running out of things to do together. Not in a dramatic way (we're fine), but in the way most couples know, where you cycle through the same three restaurants and end up scrolling on the couch. I kept thinking there should be a space that's ours. Not another social feed, not a shared calendar bolted onto a to-do app, but something that actually feels like it belongs to the two of us and grows the more we put into it.

That last part became the whole idea. What if a relationship had a living form, something you could see that reflected the care you put in? That's where Usora's creature came from.

What it does

Usora is a couples app built around a single shared world for two people. At its heart is an AI creature that grows alongside your relationship. The more you show up for each other inside the app, the more it thrives. Around that, Usora helps with the everyday stuff that actually keeps a relationship moving: planning date nights, discovering movies and restaurants together, saving the moments that matter, and having a private space that's just yours.

One subscriber unlocks premium for both partners, because it's one relationship, not two accounts.

How I built it

I built Usora solo, as a full-time IT student, on Flutter for the app, Supabase for auth and data, Google's Gemini models for the AI, and RevenueCat for subscriptions. The AI layer runs through a Supabase Edge Function that orchestrates the creature's responses along with live movie data (TMDB) and restaurant search (Google Places).

The creature itself went through real iteration. It started as a procedurally generated blob and became a proper illustrated character with mood, animation, and a glow that responds to the couple's bond. Getting from placeholder to something that feels alive was the part I cared about most.

Challenges I ran into

The AI feature was the saga. Two problems nearly sank it.

First, the Gemini API kept returning 503 overload errors under load, which meant the creature would sometimes just not respond. I solved it with a model fallback chain: if the primary model is overloaded, the request automatically cascades to the next available one, so the experience degrades gracefully instead of breaking.

Second, I originally used Foursquare for restaurant search, and mid-build it ran out of API credits. Rather than patch around it, I migrated the whole restaurant layer over to Google Places, which turned out to be the more reliable long-term choice anyway.

On top of that, doing this as a one-person team meant every layer (design, backend, payments, App Store compliance) was mine to figure out. Getting a subscription paywall fully compliant with Apple's rules as a first-time submitter was its own mountain.

What I learned

More than any single tool, I learned how much of shipping is the unglamorous last 20%: the compliance, the edge cases, the "works on my machine but not in review" problems. I also learned that the feature I was proudest of (the creature) was worth the extra fight, and that graceful failure (that fallback chain) is often the difference between a demo and a product.

What's next

An animated creature v2 with real state-driven behavior, an Android release, and getting Usora into the hands of actual couples, starting with the two people it was built for.

Built With

• dart
• firebase
• flutter
• gemini
• google-places
• google-sign-in
• ios
• postgresql
• revenuecat
• sign-in-with-apple
• supabase
• tmdb