Giving SME owners control of team spending
Designing and shipping Teams and Sub-Accounts for Raven Business: purpose-based accounts with roles, permissions and approval levels, so owners can let staff move money without losing control.
- Role
- Product Lead and Mobile Architect
- Company
- RavenPay
- Stage
- Launched
- Team
- 1 product designer, 3 mobile engineers, 2 backend engineers with Legal, Compliance and Operations partners
- Platform
- iOS, Android, web dashboard
- Pillars proven
- Product leadership · Mobile architecture · Quality
TL;DR
- Problem
- SME owners ran every payment through one account and shared their login with staff to get work done.
- What I did
- Defined the product, designed the role and approval model with Compliance, led the mobile build and set the test strategy.
- Result
- 38% of active business accounts created a sub-account within 90 days, and “unknown debit” support tickets fell 45%.
The problem
For business owners and their teams
- Owners shared PINs and logins so staff could pay suppliers. That was a security risk and against our terms.
- All spending landed in one pot, so month-end reconciliation took hours.
- Owners couldn’t let a manager pay for marketing without also exposing payroll money.
For Raven
- Larger SMEs were leaving for competitors with team features. 70% of churned business accounts had 3+ devices logging into one profile.
- SMEs drove about 40% of transaction revenue, so losing the larger ones hurt most.
Evidence14 customer interviews, and “unknown debit” was the #2 SME support ticket category over 6 months.
The insight that changed the direction: Owners didn’t want “more accounts”. They wanted to let staff spend without losing oversight, and they thought in budgets (marketing, payroll, operations), not in people.
My role
I owned Teams and Sub-Accounts end to end, from discovery to launch, and led the 2 mobile engineers who built it.
- 1
Defined the problem and success metrics.
Ran the interviews and ticket analysis, wrote the PRD and agreed adoption and support-ticket targets with leadership before design started.
- 2
Designed the permission model with Compliance.
Default roles (Admin, Finance, Operations, Support), custom roles, and three authorisation levels: Initiator, Approver, and Initiator and Approver.
- 3
Architected the mobile implementation.
Role-aware screens, permission caching with server-side checks on every money movement, and approval requests through push and an in-app inbox.
- 4
Wrote the acceptance criteria and test strategy.
Built a role-by-action permission matrix that became our automated test suite.
- 5
Planned the rollout.
Beta with 25 businesses behind a feature flag, then a staged release.
Key decisions and trade-offs
| Decision | Why | What we gave up |
|---|---|---|
| Purpose-based sub-accounts (Marketing, Payroll, Operations) instead of one wallet per employee | Owners think in budgets; it matched how they reconcile | Per-employee wallets moved to a later version |
| Separate roles from accounts, with 4 defaults plus custom roles | Defaults covered 85% of interview needs; custom roles covered the rest | A larger permission matrix to build and test |
| Payments above an owner-set limit need an Approver | Control without approving every small payment | Extra states in the transfer flow and longer QA |
| Sub-accounts share the parent business’s KYC profile | No new onboarding or regulatory delay | Sub-accounts can’t have separate legal owners |
| Setup on the web dashboard first; spending and approvals on mobile from day one | Owners configure on desktop; staff act on their phones | Mobile setup arrived 6 weeks later |
How it was built
- Mobile
- Flutter app with a permissions module loaded at session start and refreshed on role change. Screens and actions render from the user’s role, so staff never see buttons they can’t use.
- Security
- The client is never trusted. Every money-moving request is re-checked server-side against role, account and limit, with idempotency keys to prevent double payments.
- Approvals
- An approval request is a first-class object with its own states (pending, approved, rejected, expired), delivered by push and an in-app inbox.
- Quality
- The permission matrix (5 roles × 12 actions) was covered by automated API tests and end-to-end tests on critical paths, run on every pull request. The beta surfaced 3 friction points, including unclear approval notifications, which we fixed before launch.
Roles
- Admin
- Finance
- Operations
- Support
- Custom roles
Authorisation levels
- Initiator
- Approver
- Initiator and Approver
- DeviceSession startPermissions module loads the user’s role; refreshed on role change.
- DeviceRole-aware screenOnly actions the role allows are rendered.
- DeviceMoney requestSent with an idempotency key.
- ServerRe-checkRole, account and limit, every time. The client is never trusted.
Within limit
Payment executes.
Above the owner-set limit
An approval request is created: a first-class object, delivered by push and the in-app inbox.
- Pending
- Approved
- Rejected
- Expired
Sub-account list
Sub-accounts
- PayrollManaged by Finance₦1,240,000.00
- MarketingManaged by Operations₦386,500.00
- OperationsManaged by Operations₦512,750.00
Add sub-account: authorisation
Who can move money?
- InitiatorCan start payments
- ApproverApproves payments above the limit
- Initiator and ApproverBoth
Approval needed above₦200,000.00
Approval request on mobile
Approval request · Marketing
₦450,000.00
To Northgate Print Ltd
Initiated by Ada O. (Operations)
Above the ₦200,000 limit set by the owner. Expires in 23 h.
Results
-
0 → 38% (target 25%)
Active SMEs with at least one sub-account
-
−45%
“Unknown debit” support tickets
-
+17%
Monthly transaction volume from adopting businesses
-
0
Permission-related security incidents
Blue: my team’s work. Black: feature- or product-level, shared with others.
Reflection
What I’d do differently
I’d include accountants, not just owners, in research. Per-sub-account statement export became the top request after launch, and we could have shipped it in v1.
What it taught me
In business banking, control is the product. Permissions aren’t a backend detail; they are the main user experience.