Building Nuvo’s Vendor Network

Who am I?

I'm Hari, a product engineer at Nuvo who has led multiple new launches across our portfolio over the past two years, most recently our applied AI initiatives and our first in-product agents. I love driving product work from discovery all the way to iteration.

Context

Nuvo’s flagship product is the credit application. Companies like AutoZone, Nestlé, and Fender use it to onboard, manage, and assess risk for their buyers, replacing costly manual processes with an easy-to-use online experience. The first step in the credit application has buyers sign up for the Nuvo Network. This flywheel has not only brought >100,000 businesses onto the Network, but also helped businesses issue more than $1B in trade credit to date.

But our ambition is much larger than just onboarding new customers. Nuvo’s mission is to build a world that doesn’t run out, and we’re doing that by creating the first digital trade network for the physical economy.

Last November, we doubled down on network growth by launching the Vendor Network. Along the way, we rearchitected our core platform data models, shipped multiple new product surfaces, and set the stage for future expansion.

The Problem

Today, Nuvo mainly supports suppliers and distributors selling to last-mile buyers (e.g., your local convenience store, restaurant, or retailer). But as we move up the supply chain, there are hundreds of thousands of upstream vendors that provide critical raw and intermediate inputs:

The supplier needs to onboard and manage the various vendors that they use. This process is essentially the reverse of a credit application. Instead of a buyer providing information to a supplier with the intention of buying goods, it’s the supplier (vendor) sending information to the buyer with the intention of selling goods.

Discovery

We had early evidence that vendor management was a problem worth solving. Back in 2022, we talked to an early Nuvo customer who manufactures truck trailers, a complex product that relies on over 2,000 individual vendors. A single entity delaying shipments, let alone going bankrupt, has large ripple effects, making vendor selection and continuous management an existential problem.

In early 2025, we saw that the time was right to address the vendor side of this problem. Tariffs and geopolitical uncertainty were top-of-mind for businesses around the world. We also noticed that many companies on Nuvo were intermediaries in the supply chain, both buying and selling goods. That meant we already had a strong base of businesses benefiting from Nuvo as suppliers, and we could create immediate value by helping them onboard their own vendors.

Despite the clear potential, we were still a small engineering team at the time, so we needed to scope carefully and move fast. I partnered with Mallory, our Head of Product, to run an accelerated discovery process and design an MVP. We had a few immediate goals in mind:

• Understand the existing process and who makes decisions: For our existing credit application product, this is relatively homogenous: it’s usually a single Credit, Collections or Finance department, working with Sales. We suspected the state of affairs was trickier on the vendor side based on our visibility into Nuvo buyers and their roles.
• Understand what data is collected: Our credit application wins in the market because we not only collect information, but crawl trusted data sources like credit bureaus, banking data, and government filings to verify it. Many of these are useful for vendors as well, but we needed to understand what we were missing.
• Understand user terminology and mental models: A “credit application” is a well-understood concept, but the analogue on the vendor side can take on many names - “vendor packet”, “vendor form”, “vendor account setup”, etc.

Most companies use paper forms to onboard vendors, not software. They can spend days chasing people down to provide complete information and checking its validity.

We talked to 10 customers and uncovered key learnings:

• Heterogenous user personas: The teams involved may be the Accounts Payable department or a dedicated procurement/supply chain team, or both teams coordinating handoffs.
• Data requirements: Some of the data we were already collecting, including company information, key owners and officers, compliance documentation, and signatures, matched what vendors required. But there was additional unique data that was necessary: Accounts Receivable contacts, ACH details (where and how the buyer should pay), and a long tail of documents like financial statements, certificates of insurance, and W9 forms.
• External data sources mostly centered around compliance: It’s critical that you know who you are doing business with, and that includes checking against databases like OFAC sanctions lists. Verifying ACH bank account ownership was also important and a large source of inefficiency.
• Vendor fraud mitigation was a key concern: On the supplier side, malicious buyers have to take inventory of the goods and flip them. But malicious vendors directly receive cash, making it an attractive vector for fraud.

Design

At this point, we had enough information to design our MVP. We made a few product decisions to cut scope and move fast while still building a valuable product:

• We re-skinned the credit application as a “vendor application”, a new first-class primitive on our platform. The credit application product surface was already highly customizable (branding, custom questions, and validations), covering 80% of vendors' data collection requirements. By piggybacking off of this, we would gain a lot of flexibility.
• We determined that no net new integrations were needed: another engineer was already working on pulling Secretary of State filings and sanctions watchlist checks via Middesk for the credit application product. We verified that we would be able to pull and display this data with minimal lift.

Making the right engineering tradeoffs on what to repurpose vs. build from scratch was also important:

DB schema was relatively simple, but assumed a “relationship” was always a credit application.

The story behind this 2-level invite/connection state machine is out of scope of this post, but safe to say that it was becoming unwieldy.

This platform design had already been causing a few issues:

• Various workflows and state transitions had been added piecemeal over time. It wasn’t always clear how a relationship could reach a particular state, and state transitions had many conditions and side effects. This complicated debugging, batch operations, and business analytics like funnel tracking and network growth projections.
• The design worked internally for all use cases, but didn’t map cleanly to the typical Nuvo user’s mental model. The core user persona is a credit manager working through an accounts receivable workflow—checking new applications and conducting recurring reviews across existing approved accounts. As a result, we had to map various internal states to friendlier display states on the frontend (masking the concepts of “invites” and “connections” entirely). With new accounts payable users entering the platform to onboard as vendors, we foresaw this problem getting worse.

We knew we had to redesign this to support vendor applications, so we took the opportunity to simplify the model:

New DB schema: Relationships act as the top level wrapper, while data is stored on separate application tables

Customer and Vendor applications share the same set of “review statuses” and state transitions

The new architecture gave us many benefits:

• Customer applications and vendor applications could both align to the same, simpler state machine, but also could have independent review statuses tracking the state of information flow in both directions. Again, depending on the nature of the business relationship, these steps can happen in either order, or even simultaneously, so this gave us a lot of flexibility.
• This aligned much better with user mental models, and it was much clearer what the next step on an application is.
• Eligible state transitions became purely dependent on review status, allowing us to clean up and simplify a ton of business logic.

Shared Data Collection

We needed to repurpose existing pieces of the credit application in the vendor application. We shipped several new data collection sections we wanted to use in both surfaces—W9 document collection, ACH account capture, and verification.

This required frontend refactoring to separate data querying (from customer_application and vendor_application tables) from shared presentational components. The result is that new sections we added are by default usable in both product surfaces.

A paper vendor form can capture banking information, but requires much more extra work to verify (often, reviewing companies just check that a bank account number is being provided and take the risk). Nuvo integrates with Plaid directly, leveraging their microdeposit verification flow.

Coding Agents for Boilerplate

The Nuvo engineers were early users of Claude Code. Around the time we started working on this project, Sonnet 4 was released and was a large usability unlock. This change required us to refactor thousands of lines of boilerplate business logic. By a rough estimate, Claude allowed us to ship this ~50% faster.

The Future

Today, we have a small but growing cohort of customers who use Nuvo to manage both their customers and vendors in one place. We’re actively working on improvements to further scale usage and make the product more powerful - improving our fraud detection, crawling more data sources, and building new workflows.

The incremental revenue growth is great, but what really excites us about this is the new growth channel this brings to the Nuvo Network. Every large buyer on Nuvo can now bring all of their vendors and customers onto the platform. And as the Network grows, our capture and visibility into bidirectional transaction and risk data allows us to build increasingly powerful and differentiated workflows on top, like native payments and AI agents.

We’re on track to grow to more than 1 million businesses on Nuvo this year, and are excited about the compounding value we can drive to them.

This is just one example of how product engineers work at Nuvo: end-to-end, from early ideation, to discovery and design, to implementation, rollout, and post-sales support. There’s a ton more to build, and if you’re interested, we’re hiring.