Mobile2026

Cooperant

Managed savings groups for Nigerian corporate workers, designed around payroll collection, explicit approvals and a ledger that money cannot bypass.

Role: Product Architect & sole engineer

SwiftUIKotlinJetpack ComposeJava 21Spring BootPostgreSQLFlywayDocker

The application

Screens, captured from the running app

Captured from the native iOS fictional-data walkthrough. Every person, employer, round and amount shown is sample data; no payment or verification was performed.

Cooperant welcome screen with the People Together mark, the Save together Grow together tagline, and an explicit sample-account disclosure. — The welcome screen makes the boundary visible before entry: this is a sample account and no real payments take place.

Cooperant member home showing the next payout, amount saved, contribution progress, next contribution and recent activity. — The member home reduces a savings round to the four questions that matter today: what is due, what has cleared, how far the round has progressed, and when the payout lands.

Cooperant employment verification timeline with completed, in-progress and upcoming stages. — Employment verification is a staged process, not a spinner. The member can see what Cooperant has, what it is checking, and what still depends on the employer.

Cooperant Groups screen showing an active January savings round, application setup and the option to find another round. — Groups keeps the active round, unfinished eligibility work and discovery entry together without confusing an application with membership.

Cooperant Find a round screen showing the January round payout, monthly saving, duration, confirmed members and available payout dates. — Round discovery states the full commitment before selection: payout, monthly contribution, duration, confirmed membership and remaining dates.

Cooperant Activity screen showing three received monthly contributions for the January round. — Contribution history is a receipt trail. Each entry names the amount, settlement state and date instead of reducing the round to one balance.

Cooperant Bank accounts screen showing verified ownership and the currently selected payout account. — Payout destinations separate verified ownership from selection. Changing the account is an explicit reviewed action, not a silent profile edit.

The member profile gathers payout, security, privacy and support controls around the same named account and employer relationship.

Status: Cooperant is pre-launch. The native apps and backend run, but provider accounts, production signing, the public domain and legal sign-offs are still outstanding. Every person, employer and amount in the screenshots is fictional.

The product boundary

Cooperant manages savings rounds for corporate workers. Members verify their identity, employment and payout account; choose a round and payout position; approve a payroll mandate; then track contributions and payout from the app. Employers confirm payroll details and deductions. Operations staff reconcile money, investigate exceptions and approve payouts independently.

The launch scope is deliberately narrower than a general cooperative platform. Loans, dividends, migrated balances and society administration remain future work. Keeping them out of launch navigation made the member app understandable and kept the financial controls focused on one lifecycle.

Native on both platforms

The member experience is implemented independently in SwiftUI for iOS and Jetpack Compose for Android. Both clients talk to the same server-owned state model rather than carrying financial truth locally. The interface can explain a status, request an action and display a ledger; it cannot decide that money cleared or that a payout is approved.

That separation matters most around recovery and repetition. Every command carries an idempotency key. Payment and payout actions require explicit state transitions. A retry cannot create a second financial event simply because the network response was lost.

The ledger underneath the screens

The Spring Boot service models contributions, allocations, fees and payouts over a balanced ledger. Payroll remittances arrive as batches that must reconcile to members before they become usable balances. Unknown transfers and mismatches enter operations queues instead of being silently forced onto an account.

Payout preparation, coverage and execution are separate actions. The person who assembles a payout cannot unilaterally complete it. That approval split is visible in the operations console and enforced in the service layer.

Honest progress states

The member app avoids hiding slow institutional work behind indefinite loading states. Employment verification is shown as a five-stage timeline. Identity-provider handoff clearly says when a provider is not connected. Demo submission never fabricates approval, contacts an employer or moves money.

That is the recurring design rule across the product: a preview should be complete enough to test the journey while remaining impossible to mistake for a live financial service.

What remains before launch

The remaining work is operational as much as technical: production provider agreements and keys, final fee and refund terms, payout-protection policy, legal review, independent security testing, domain registration and App Store / Play signing. None of those are represented here as complete.