Brex's vendor surface was an address book: names and payment methods, nothing more
For small companies it worked. For mid-market and enterprise organizations managing hundreds of vendors, it was a complete blocker.
The gaps were clear: no tax information, no approval workflows, no compliance support. But the deeper challenge was foundational. Brex had no vision for what AP and procurement should look like, so every feature decision risked being purely tactical. Before we could fix individual features, we needed a point of view on what AP should become. I set out to build that while delivering incremental value along the way.
From embarrassed teams to a north star
Over five weeks, I ran co-design sessions with controllers, senior accountants, and CFOs — four customers per week, all at companies building or evolving their finance operations. I found most users were embarrassed by their systems. Their documents scattered across storage apps, approvals cobbled together across platforms, no single source of truth.
From those sessions, I designed a 5-year vision for the Vendors surface that included a full-page vendor profile demonstrating what it would take for finance teams to run a complete procure-to-pay workflow entirely within Brex.
The vision became a working document. I used it to run activities like prioritization exercises where customers ranked potential features by impact. This shaped our release schedule — what we built, in what order, and why. It gave every short-term decision something to ladder up to, and ensured nothing we shipped came as a surprise to stakeholders.
7 releases, 1 coherent story
I was the sole designer across all seven releases, collaborating closely with my product manager, engineering team, and executive stakeholders.
Direct import from ERP
One typo in Brex = two vendors in your ERP. Connecting these systems solved a big pain point with a surprisingly small footprint — on vendor create, users match against existing QuickBooks or NetSuite records and their details fill in automatically.
Vendor self-serve and manual tax entry
We shipped manual tax entry first — text fields, basic, functional. But storing the actual W-9 turned out to be ten times more valuable, and having vendors submit their own information was more secure than putting that burden on the customer.
That insight reframed everything that followed: request and collect from vendors, don't burden the customer. I updated the vendor create flow to default to requesting information, so all a customer needed to provide upfront was basic contact details.
W-9 OCR
In co-creation, when I showed W-9 upload with automatic field extraction, customers lit up — suddenly this was a review workflow, not a data entry task. Executives shared that excitement, particularly when my PM confirmed we'd be first to market. Engineering was a harder sell. They pushed back on the timeline, however passion for the best user experience helped make the case for an additional engineer on the front end and gave us the capacity to build it properly.
TIN validation
Designed to give users confidence in who they're paying. We integrated with the IRS to verify vendor tax IDs in real time — but completing our own vendor onboarding to access that tool added months to the timeline. The upside: that time gave the engineering team and me space to work through every edge case, so the feature performed well from day one.
"Yes!! We need this!!" an early access customer
1099 management
Given everything the platform now knew about vendors, I wanted to automate 1099 eligibility entirely. In co-creation, customers pushed back — for their own confidence, they wanted to make that selection themselves. Any AI-assisted approach would require a review workflow they could trust, and we weren't there yet. I shipped the manual, controlled version first and kept the automatic eligibility design ready for later.
Vendor owners
Finance teams approving bills often have no context on whether a vendor is legitimate or whether billed services were actually delivered. This is a real fraud vector, and one that came up repeatedly in research. Due to the engineering teams capacity, I zeroed in on the minimum that addressed the core risk: a vendor owner as point of contact and bill approver.
Executives were skeptical — the feature felt too simple. I used research quotes to validate that starting minimal rather than waiting for a more complex system was the best path forward. After shipping, the signal we were on the right track came through customer support: requests for expanded permissions arrived quickly, and we moved straight into researching the next layer — bill creation, purchase order creation, and more.
"If this is for internal reference, as far as who should be approving bills before we make payment, or who manages communication to the vendor, then that would definitely be helpful." a controller at an enterprise
Updated patterns and components
Throughout every release I pushed to raise the quality bar on the surface itself. I tracked what the platform team was building and advocated to adopt new patterns early, using Vendors to stress-test designs from a complex, data-dense context. I wanted Vendors to lead, not follow.
Incremental releases and incremental learning
Starting with zero AP expertise taught me to embrace ambiguity differently. Co-design sessions weren't just validation; they were education. I built domain knowledge while designing.
The iterative milestone approach (ship manual entry → prove value → build OCR) kept momentum high even as scope changed. The long-term vision gave us permission to make short-term compromises without losing direction.
The biggest unlock: filling feature gaps wasn't enough. We needed our edge (OCR, self-service) while solving foundational problems first. That's what made it a platform, not just a feature set.