

Tribe Money Payment Workflows
Led 0-1 design for financing tools to help founders and freelancers collect, send, and manage payments
ROLE
Lead Product Designer
DURATION
Jan 2026—present
TEAM
1 PM, 2 Engineers
Overview
In late 2025, Tribe Money pivoted concepts into the fintech SaaS and AI space, providing early-stage founders, freelancers, and SMBs with frictionless access to unified financing tools without the need to incorporate.
Role and Responsibilities
I led the 0-1 design of the payment links and invoicing workflows, translating ambiguous business needs into a unified payment system for collecting and distributing money. Through meetings with founders and partners, I defined key use cases, built end-to-end flows, and collaborated cross-functionally to shape product direction.
As a startup designer, I also…
Led UX research exploration alongside another PM with real users
Shaped product direction and planned roadmaps alongside product partners
Envisioned onboarding, dashboard, transfers, and virtual cards flows for the future
Built the marketing website and additional ad-hoc assets
Challenge
A few questions emerged from initial market research, user interviews, and usability testing:
How do we differentiate between two similar products (payment links and invoices)?
How do we reduce manual entry and repetitive billing work for our users?

Founder
An early-stage builder managing a product or venture; may handle incoming and outgoing payments

Freelancer
Independent contractor delivering services; paid by per project or client
Furthermore, with a growing waitlist of alpha users and pressure to launch quickly, the founders initially wanted to build the full suite of capabilities before going live. Instead, I advocated for a progressive release focused on the highest-value workflows, allowing us to validate product direction and gather feedback earlier.
Designing the Product
Identifying user tasks revealed three key opportunities:
Create and send new payment requests with minimal setup
Manage and track active payment requests across their lifecycle
Reuse existing information to reduce repetitive billing work
Distinct Workflows
I differentiated the two flows by their primary purpose.
Payment Link Creation User Flow


Payment links emphasize quick and low-friction payment collection. Upon clicking a specific payment link, a drawer is revealed to show link-specific metadata and contextual actions without taking users away from the main payment links table.
Invoice Creation User Flow


Invoices support structured billing and in-depth payment tracking. Because invoices involve more detailed billing context, selecting an invoice opens a dedicated full-page view for reviewing customer details, payment status, line items, and related actions.
Smart Defaults
Feedback showed that users often use invoices to bill recurring clients. I explored pre-populating client information to improve ease of use and reduce manual entry.


However, this increased engineering complexity for the current scope and timeline, so this exists as an intended future-state.
Final Designs
Payment Links
Designed for quick and lightweight payment collection, whether for one-time or repeat purchases, payment links includes:
Slide-out menu for metadata management and quick actions
Link analytics and performance insights
Automated link categorization
Transaction history toggle for detailed records
Invoices
Designed for structured billing and payment tracking, invoices features:
Real-time payment and invoice status tracking
Customer and billing information management
Customizable invoice creation and dynamic line-items with editable fields
Automated reminders and overdue payment workflows


Outcome
This is currently live in alpha testing and we're thrilled to have received a 92% user satisfaction rating!
We delivered over 10+ screens for these flows.
We are excited to continue testing and validating the design direction, while seeing the results of this work enable and encourage new roadmap projects.
Learnings
Scope as a design tool
I initially approached the problem as a broad payments platform, but learned that reducing scope was just as important as designing new capabilities. This way, I could focus on the highest-value flows before investing in a larger blue-sky ecosystem.
Systems matter earlier than expected
Even with a limited initial release, establishing shared patterns and reusable components made it easier to maintain consistency across workflows and create a foundation for future user flows.