Built from a problem. Scaled to an industry.

Problem: cold-start vendor onboarding on a two-sided platform. Result: 70% self-serve, NPS +20, time to value cut from 3 months to 3 weeks.

Getting enterprise customers to first value required their vendors to be on the platform first. Vendors had no incentive to integrate. Early attempts to have customers convince their own vendors failed. The problem was structural: a classic two-sided marketplace cold start, compounded by a vendor base with very low digital literacy.

I led the design and build of a self-serve vendor portal built around three principles: extreme simplicity for low-tech users, flexibility for advanced ones, and a built-in network incentive. A vendor with minimal digital skills could upload catalogs via file import. A technically capable vendor could connect via API or FTP. And once on the platform, vendors could make their catalog available to other Avisio customers with a few clicks, turning the most popular vendors into pre-onboarded assets for every new customer.

To focus customers on their most important vendor relationships and protect our operational capacity, I restructured pricing packages to cap vendors per tier. Within the cycle following launch, 70% of new vendor onboardings were self-serve. Time to first value dropped from approximately three months to three to four weeks. Customer NPS moved from the low 60s into the 70 to 80 range.

Problem: no off-the-shelf tool fit our low-literacy vendor base. Result: built in-house in 3–4 weeks, adopted Next.js as the standard frontend framework.

As we scoped the vendor portal, we faced a classic build vs. buy decision for the core data layer: the functionality that let vendors upload, view, and edit their catalogs visually. Existing solutions were either too complex for our low-literacy user base or overkill for what we needed at that stage.

I wrote a PRD with a deliberately minimal feature set, only what we needed to go live with the first vendors. I shared it with my engineering lead for an estimate. His read: we could build it ourselves in a matter of developer days, provided designs, mockups, and specs were tight. That condition put the responsibility back on product, which is exactly where it belonged.

There was a second factor. Next.js had just emerged as a relevant framework for our frontend architecture and the team was excited about it. Rather than treating that as a distraction, I used the vendor portal as a contained, low-risk project to build Next.js competency across the team and evaluate it as a long-term direction. The portal went live in three to four weeks, on schedule. We adopted Next.js as our standard frontend framework, which also strengthened our engineering hiring pipeline. Developer engagement and retention improved noticeably. The decision to build in-house gave us full control over the UX, and that simplicity was directly responsible for the self-serve adoption rates in the first case study.