Skip to content
RichlyMe ikonuIn development2026

RichlyMe

An invitation-only members’ club app where experiences are shared with proof.

iOS
Let’s build something like this
RichlyMe interface 1
RichlyMe interface 2
AppAMG / 26
Project
Our own product
Our role
Product · Brand and interface design · Mobile development · Backend
Duration
In development

01 / Behind the product

How we built RichlyMe

01

Challenge

A young, affluent audience wants to share experiences, but not in a public feed. The product had to be a closed stage: everything shown inside had to be real and provable, and nothing could leak out. There were two traps. If points can be bought, status loses its value. Real-time, exact location sharing is a safety risk for this audience.

02

Approach

Proof comes only from the in-app camera. When the camera opens, the server issues a single-use code valid for 120 seconds; the code appears in the frame and is bound to the proof on submission. The scoring formula lives in a SQL function (score_proof), is callable only by the service role and does not grow linearly with money spent.

Publishing is delayed: a proof appears at least 24 hours later, and only at city level. The backend is 49 migrations and 17 Edge Functions on Supabase, with row-level security checked by 401 tests across 38 SQL test files. Membership is sold only through Apple in-app purchase, managed with RevenueCat. The interface is built with Expo and React Native; the door opening, medallions and member card are drawn with Skia.

03

Result

The app is being prepared in 12 languages, including right-to-left Arabic. The visual language is bespoke: no stock icon set; the badges, the seal and the “door ajar” light motif were designed for it. Privacy controls (delay length, app lock, screen-capture guard) stay with the member. The app is in development and not yet on the App Store.

03 / Scope & details

RichlyMe key features

  • 01

    Proof captured in the in-app camera with a single-use 120-second code

  • 02

    Scores computed only on the server, in a SQL function; no paid points

  • 03

    Proofs are delayed 24 hours and shown at city level; exact location never appears

  • 04

    12 languages including right-to-left Arabic

  • 05

    No stock icon set: badges, seal and door motif drawn for the product

Invitation-only membershipNightly and weekly challengesProof cardsCity rankingsBadge collectionMember representative

Technology

React NativeExpoTypeScriptSupabasePostgreSQLRevenueCat

INSIDE THE PRODUCT

The engineering behind RichlyMe

Systems we built and concrete problems we addressed in this project.

01

The camera itself vouches for the proof

issue-nonce gives an active member a rate-limited, single-use code valid for 120 seconds when the camera opens. The code appears in the frame and submit-proof binds it to the proof on submission. There is no gallery upload path.

02

Scoring in SQL, not on the client

public.score_proof is revoked from everyone and granted only to the service role. The verification method (booking API, location-bound code, AI with a witness, AI alone) sets the score, and money spent does not raise it linearly. The same formula is mirrored in packages/core for display.

03

Retention written into code

publish-delayed releases proofs once their delay has passed. purge-originals runs daily and deletes the original files of proofs whose season closed more than 90 days ago, keeping anything under a fraud or report hold. Account deletion and retention live in their own Edge Functions.

Your idea could be next.

What could we build for you?

From a first release to a growing platform. Let’s plan the design, development and launch together.

Tell us about your project

From Türkiye to the US, UK, Australia and everywhere in between.

ENGINEERING NOTES FROM THIS PROJECT

How do you test Supabase RLS policies? Lessons from 401 tests ↗