‘91N4D4’ - ’The Cocos’ - ‘PodMates’

Podmates turns habits into a team sport, and makes missing a day safe.

Comment

==================================================

INSPIRATION

Habits are hard to keep alone. Most habit trackers are solo checklists where nobody notices when you stop, and one missed day can wipe out a streak, which is often when people give up. We wanted accountability that feels like support, not surveillance.

==================================================

WHAT IT DOES

Podmates is a habit app that works like a group chat.

  • Join a pod: a small group of friends sharing one habit, such as reading, running, swimming or meditating.
  • Snap your proof: every day at the pod's snap time, a 15-45 minute window opens and everyone posts a photo of their habit.
  • Grow a tree together: the pod shares one tree. It grows when everyone shows up, holds steady when most do, and wilts when too few do.
  • Miss safely: rest days (2 per pod per week) keep your streak, and the pod isn't counted against that day.

Around that daily loop are pod chat, one-to-one messages between podmates, stories, and public communities for each habit on Explore.

Safety and trust are built in. You can leave a pod, remove a member if you created the pod, block someone, report content, and delete your account and photos from inside the app.

==================================================

HOW WE BUILT IT

  • Mobile app: Expo and React Native with TypeScript, expo-router and TanStack Query.
  • Backend: Supabase (Postgres, Auth, Storage and Realtime), run locally in Docker for this prototype.
  • API and worker: a small Express server with a background worker that tallies each pod's finished day.
  • The server decides what counts: a database trigger stamps each snap's time and on-time status, so changing your phone's clock can't fake it.
  • One rules engine: tree health and streaks are computed in a single unit-tested TypeScript package.
  • Security in the database: row-level security decides who can read and write each row.
  • Testing: unit tests, database permission tests and an end-to-end smoke test.

==================================================

CHALLENGES WE RAN INTO

  • Pods can be in any timezone, so "end of the day" happens at different times. The worker checks every minute and settles each pod's finished days safely, so running it twice changes nothing.
  • Because the app talks directly to the database, the permission rules had to be the real security layer, including protection against faked timestamps and counts.
  • Making accountability kind: a shared tree can create guilt, so we added rest days and avoided showing a list of who missed.
  • Keeping many screens consistent while working fast as a team, which led us to shared page templates and design tokens.

==================================================

ACCOMPLISHMENTS WE'RE PROUD OF

  • A working end-to-end prototype: sign in, snap, on-time check, nightly tally, and a tree that reacts.
  • Well-being and safety features built in, not bolted on.
  • Tested server rules: database permission tests and an end-to-end smoke test.

==================================================

WHAT WE LEARNED

Accountability is a design problem. Our first version was simple: if too few people showed up, the tree lost health. It worked as a mechanic, but one sick day could feel like letting everyone down. Small choices changed how the app feels: rest days that hold your streak, leaving resting members out of the day's count, and wording that says "show your pod you turned up" instead of "your tree is counting on you." We learned that a feature can be correct and still make people feel worse.

Never trust the client. Because the app talks directly to the database, the permission rules are the real security layer. Reviewing our own code showed that a modified app could fake timestamps or post scores, and that someone removed from a pod could rejoin with the same code. We moved those rules into the database and wrote tests that try to break them.

Time is harder than it looks. Every pod has its own timezone, so "the end of the day" happens at different moments. We learned to let the server decide what counts, and to make the nightly tally safe to run twice. We also learned to isolate failures, after finding that one bad pod could have stopped scoring for every other pod.

Test what happens when things go wrong, not just when they go right. Our tests passed on the normal paths, but the bugs we found were in the edge cases: someone leaving a pod, a message failing to send, or a person being blocked partway through a flow.

Working fast as a team needs shared foundations. With several people building screens at once, each page drifted into its own colours, spacing and layouts. Agreeing on one set of design tokens and page templates made the app feel like one product and made it easier to merge each other's work.

Using AI tools didn't remove the need to understand the code. They helped us move quickly, but we still had to make the product decisions, check the output and be able to explain how it works.

==================================================

WHAT'S NEXT

  • Host it: a Supabase project, a container for the API, and an App Store build.
  • Private photo storage with expiring links, and server push reminders.
  • Friend requests and easier ways to find a pod.
  • Local Calgary pods with community partners such as campus clubs, rec centres or libraries.
  • Personal snap windows and moderation tools for reports.

Built With

Share this project:

Updates

Submission history