SafeCircle Capital — Samuel Omoraiyewa

[IMAGE — A wide cover image showing 2-3 surfaces together (e.g. Mobile App + Web Dashboard), giving an at-a-glance sense of scope before anyone reads a word.]

The Problem

SafeCircle Capital digitizes rotating savings groups — the ajo/susu model where a group of people contribute on a schedule and take turns receiving payouts. Traditionally, this is run manually: spreadsheets, chat threads, and trust between members. SafeCircle centralizes contributions, payout schedules, wallets, notifications, identity verification, and payments into one platform, for two core audiences — Members, who join groups and contribute, and Group Admins, who create and manage them.

[IMAGE — Optional. A simple visual contrasting the manual/informal way savings groups are typically run vs. the structured SafeCircle flow. Skip if nothing suitable exists.]

The System

Four surfaces, three audiences:

Members — receive invitations, accept or decline, contribute, receive payouts, complete KYC
Group Admins — create and manage groups, invite members, assign payout slots, track contributions, earn admin fees
Super Admin — platform operators managing users, admins, templates, and platform-wide settings
Marketing Website — public-facing site: pricing, how-it-works, FAQs

[IMAGE — A simple diagram showing how Members, Group Admins, and Super Admin relate across the Mobile App, Web Dashboard, and Super Admin Dashboard. Orients the reader before the decisions section.]

Design Decisions

1. Invitation-only membership, with view-before-accept

Rather than letting people browse and join groups freely, membership is invitation-only — admins retain control over who's in their group. Invitees aren't asked to accept blindly, either: before accepting or declining, they can view the group and its existing members first, so the decision to join is an informed one rather than a leap of trust.

[IMAGE — A short sequence showing an invitation landing, the group preview screen, then the accept/decline action.]

2. Slot-based member architecture

Group admins can assign multiple contribution slots, and a member can hold more than one. Rather than collapsing this into a single member entry, each slot is tracked independently — if a member is added twice through separate slots, they appear twice in the member list, each instance tied to its own contribution and payout position. This keeps every slot auditable on its own, which matters once real money and payout order are involved.

[IMAGE — The member/slot list showing a member appearing more than once, tied to separate slots.]

3. Wallet logic scaled to admin usage

Initially, all group admins had access to a wallet for managing earnings and withdrawals. The rule was refined so that single-group admins receive automatic payouts with no wallet involved, while admins running multiple groups get a full wallet with withdrawal capability. The reasoning was explicitly cost-driven — as put during the project: "we pay for the wallet and don't want to cover fees for someone running just a single group's admin costs." Wallet infrastructure is reserved for admins whose usage actually justifies it.

[IMAGE — Side-by-side of the multi-group admin's wallet/withdrawal screen and the single-group admin's simpler automatic payout view, to show the two paths visually.]

Navigating Evolving Requirements

Not every change on this project came from original design reasoning — a meaningful part of the work was keeping four surfaces coherent while the underlying spec shifted under client and provider requirements. A few examples:

KYC provider change — the original plan used Persona for identity verification; this was replaced with manual, provider-managed verification (24-48 business hours) once payment provider requirements were finalized. This meant reworking KYC status states (Pending / Approved / Failed) across mobile and web to match the new flow.
Withdrawal restrictions — withdrawal destinations were narrowed from a selectable list of banks to only the user's linked account, per client instruction, requiring updates to the wallet and settings flows.
Currency standardization — earnings displays were changed from generic amounts to USD across all surfaces.
Social login migration — social login buttons were kept in place but repurposed: first use prompts password creation, later use directs users to email/password, allowing a phased migration without breaking existing accounts.

To move quickly through these shifts without sacrificing consistency, first-draft flows and UX copy were produced using Figma Make and Claude — letting more time go into resolving the underlying product logic (like the wallet and slot decisions above) rather than redoing repetitive layout and copy work by hand each time a requirement changed.

[IMAGE — e.g. the KYC flow before and after the Persona-to-provider switch, if both versions still exist. Shows adaptability under a moving spec, which is the point of this section.]

Constraints

Members can only join via invitation — no open browsing
KYC ownership sits with the payment provider, not SafeCircle
Manual KYC takes 24-48 business hours; withdrawals take 2-3 business days
Withdrawals restricted to a linked bank account only
Wallet costs are a real business constraint, directly shaping the admin-tier wallet rule above

Reflection

No adoption or usability metrics exist yet for SafeCircle — the project is still in progress, with mobile group management being brought up to parity with the web dashboard (reports and subscription features intentionally deferred for initial release). The core value of this project wasn't a single breakthrough insight, but sustained architectural consistency: keeping invitation flows, slot logic, wallet rules, and KYC status states aligned across mobile, web, and admin surfaces as the spec evolved underneath them.

If revisiting this today, the open item worth testing is wallet eligibility at the edges — specifically what happens when a single-group admin takes on a second group and needs to transition from automatic payout into wallet-based earnings mid-stream.