Oluwatosin Kazeem

CollectAfrica was a fintech platform designed for Nigerian businesses of all sizes. It gave businesses a way to create payment links, manage customer contacts, handle transfers both locally and internationally, manage inventory, and control team permissions, all in one place.

The thesis was simple: in day-to-day life, using fragmented tools to get work done is stressful. Before CollectAfrica, businesses were using traditional fintech platforms to send money, spreadsheets to manage inventory, and handling things like user permissions verbally and manually. Nothing was connected. There was no single platform built for the way Nigerian businesses actually work.

The idea was to bring everything together the way Google brings its tools into one suite. We validated this through user interviews, and the pain was real. Business owners couldn't track things properly because their tools didn't talk to each other. It wasn't just inconvenient. It was costing them money and time.

I joined CollectAfrica after an initial version already existed. There was a need for a full redesign and to add new features. As the sole designer, I worked across every surface of the platform for close to two years, from research and wireframing through to prototyping and handoff. The team had thousands of businesses on the platform by the time we pivoted.

We had a dedicated researcher on the team who handled a lot of the foundational research. But I also did my own research, especially when it came to designing the user permissions and roles system.

For that feature specifically, I went to the mall to observe how permissions and power distribution actually work in physical businesses. I wanted to see the hierarchy in action: who approves what, who has access to what information, and how decisions flow. This kind of on-the-ground observation gave me insights I wouldn't have gotten from interviews alone.

The top three pain points we uncovered were: Transparency before transactions — there was a need for full transparency before any transaction gets approved. Business owners wanted to see exactly what was happening before money moved. Inconsistent approval processes — some transactions were only discussed when the amount was large. When it was small, it was just done and recorded with an explanation, no approval needed. This created gaps in accountability. Data discrepancies — without a unified system, data lived in different places and didn't always match up. This made reconciliation painful.

The biggest surprise from the research came when I was designing the approval system. Before the research, the assumption was that we'd build a simple model where someone in a high-power role approves transactions. But what I learned was that some transactions require multiple approvals, "and" not "or." Two people might both need to sign off before something goes through. This completely changed the direction of how approval permissions were set up during the setup flow.

The original onboarding was cumbersome. It asked for too much information upfront, and many users simply didn't have all the required details ready during signup. The result was a high drop-off rate.

I simplified it by reducing the initial registration to the information users would most likely have on hand: their name and email. That was enough to get them into the platform.

Once inside, users could see what the platform offered. A task list broke down the remaining onboarding steps for them to complete at their own pace. This reduced friction both during and after onboarding, which led to a significant decrease in the drop-off rate.

This was the same progressive onboarding pattern I later refined at Autospend (where I had specific metrics: 80%+ drop-off reduced to under 52%). The core insight carried across both products: don't ask people for everything at the front door. Let them in first, build trust, then collect what you need.

Before CollectAfrica, permissions in most of these businesses were handled verbally. There was no explicit system. Someone just told you what you could and couldn't do.

The platform changed that. I designed it so users only see the things they have access to and can only perform actions their role allows. For example, a regular worker can't see the business income. This built privacy directly into the interface rather than relying on trust.

The hardest UX challenge was making the permission rules and the role tree not look complicated. Business owners aren't technical users. They need to understand what they're setting up without feeling overwhelmed. At the same time, the system had to be flexible enough for admins to add new rules and new roles as their business grows.

This feature was most relevant for medium and large-scale businesses. Smaller operations with one or two people didn't need this level of control, but as businesses grew, it became essential.

The permissions system also tied into the automated workflows. Based on the rules set by the admin, certain transactions would automatically trigger approval flows depending on the amount. A small expense might go through without approval, but anything above a threshold would require sign-off, sometimes from multiple people.

Payment links were at the core of CollectAfrica. There wasn't much that made our payment link creation different from competitors like Paystack or Flutterwave in isolation. The value was in having it live inside the same platform as everything else. Business owners didn't need to jump between tools to create a link, track the payment, and manage the customer.

The store management feature was an inventory system that let businesses track their stock within the same platform where they were already handling payments and contacts. Having it all connected meant fewer data discrepancies, the exact pain point our research had surfaced.

I was the only designer for close to two years. Priority was mainly based on team decisions, with the roadmap driven by the CEO based on market signals. We worked in two-week sprints managed through Linear, with a project manager handling task allocation.

The hardest part of being a sole designer at a startup was the pressure and wearing multiple hats. When multiple features needed design work at the same time, the sprint structure helped keep things manageable.

For handoff, I used annotations on Figma for developers, and the whole dev team had access to Figma's dev tools. The design file was the source of truth. Without other designers to review my work, I had to be disciplined about documentation and clarity in the file itself.

One thing that made us fast: I built reusable components from scratch. Having a proper component library meant I wasn't redesigning buttons, inputs, and cards every time a new feature came up. This investment in the design system paid off enormously, especially during the pivot to Autospend where those same components carried over.

The pivot to Autospend was driven by market signals and a business decision by the CEO and stakeholders. CollectAfrica was trying to do a lot, and the market was telling us to focus.

The design system carried over to Autospend, including core components like buttons and text fields. But everything at the feature level was thrown away: the permissions system, paylinks, store, purchase orders, vendor management, tax compliance. What remained was the payment infrastructure, sharpened into a focused stablecoin spending tool.

Thousands of businesses used CollectAfrica before the pivot. The platform handled payments, inventory, permissions, and workflows for businesses that previously relied on fragmented tools.

The foundation built through CollectAfrica carried directly into Autospend, which went on to process over $1M in transactions within its first months.

Looking back, CollectAfrica was trying to do too much. We had a lot of features on the platform, and we cut some down over time even before the pivot. The eventual narrowing into Autospend proved that a focused product beats a broad one.

What I carried forward: an understanding of how the market dictates the business side of a product, how fast startups need to move to keep up with demand, and the value of building reusable components from scratch. That component library I built at CollectAfrica is the reason we could move so quickly when Autospend needed to ship.

The permissions research also shaped how I think about design in general. Going to the mall, watching how real businesses handle power and approvals, and discovering the "and" not "or" insight, that's the kind of work that doesn't show up in a Figma file but changes everything about what you build.