VendorPass came out of a weekend. At Techstars Startup Weekend, part of Boston Startup Week, a small group of us formed around one problem and built a working product against the clock. I led design and product, shaping the flows and the interface, while teammates ran user research and business planning. What we shipped by Sunday is the app embedded above.
The idea: help property managers find local vendors, plumbers, electricians, landscapers and the rest, and see whether each one is actually insured and licensed before they ever pick up the phone. The hard part in that world is not finding a contractor. It is trusting that the paperwork behind them is real and still current.
The problem
Managers never lack contractors. They lack a fast way to trust them.
A property manager juggles vendors across many buildings, and compliance is a liability minefield. An expired certificate of insurance or a lapsed business license can turn a routine repair into a lawsuit. Today that verification lives in email threads, loose PDFs, and spreadsheets that go stale the moment they are saved. Our research over the weekend kept surfacing the same thing: managers do not lack contractors, they lack a fast way to trust them. VendorPass turns that scatter into a single source of truth, where a vendor's standing is a status you can read at a glance instead of a folder you have to audit.
How it works
Anyone can browse the supply, but a vendor's contact stays private until they're invited.
Search comes first. A property manager can browse the marketplace by trade and zip code before creating an account, so they can size up the local supply before committing to anything. Discovery is the product; the account waits until they actually want to invite a vendor to a project. Public search only ever reads a vendor's public-safe fields, so nobody's contact details leak into a browse.
Inviting a vendor is what unlocks their private contact info and creates the working relationship. An existing vendor receives a project invite; a new one gets a signup link, completes onboarding, and accepts or declines from their own dashboard. Contact details stay locked behind that accepted invite, never exposed to every property manager who happens to search.
Verification tiers
Every vendor document sits at one of three trust levels, shown right in the interface.
This is the core idea, and the part I designed the whole interface around. Every vendor document, a business license, a W-9, a certificate of insurance, moves through three tiers of trust, and the whole interface is colored by that status.
- Tier 1, Unverified: nothing on file yet. A quiet dashed outline, neutral text.
- Tier 2, Self-Verified: the vendor uploaded the document and confirmed the fields pulled from it. A solid gray fill, no border.
- Tier 3, Verified: a human admin reviewed and promoted it, rendered in the platform's one saturated blue.
The design language behind it, which I called Architectural Utility, makes the visual weight of an element track its compliance status directly. A roster reads like a blueprint where the trustworthy things are literally bolder, so a manager scanning a list feels the risk before they read a single field.
You feel it most in a vendor's detail view. A fully verified vendor shows every document in the platform's saturated blue, the strongest signal the system can give. An unverified one is the same layout drained of that color, each document reading Not uploaded, so the absence of trust is as legible as its presence.
The build
Document AI reads the fields, server functions gate every promotion, and vendor data stays split public and private.
Uploads flow into Google Document AI, one processor per document type, which extracts the fields that matter, policy numbers, expiration dates, license IDs, so the vendor confirms what was read rather than retyping it. Every verification-changing write is a server-owned Cloud Function, so a vendor can never mark themselves Tier 3; promotion is admin-gated on purpose, because a trust signal is only worth anything if it cannot be self-issued.
Vendor data is split public and private at the database level: search reads only name, zip, and categories, while contact details sit in a locked subdocument opened only on invite acceptance. The front end is React, Vite, and Tailwind; the back end is Firebase across Auth, Firestore, Storage, and Functions, with a Trigger Email extension queuing the invite mail. Ambitious for 54 hours, which is exactly the point of the format.
How it landed
A weekend proved the model; getting real vendors to upload is the next problem.
By Sunday we had a live marketplace, a real document-to-tier pipeline, and a design system that made the trust model legible at a glance, which is more than most weekends produce. The piece I am proudest of is that verification model, the way three tiers turn a compliance chore into something you can read instantly. The honest open question is everything downstream of a real vendor base: the tiers only mean something once enough vendors have uploaded real documents and enough admins have done the promoting, and that chicken-and-egg problem is not something a weekend, or design alone, can solve. What the weekend did prove is the shape of the answer.