Build Log - From Presentation to Distribution

For five years, we've built great relationships with colleges and identified branded merchandise that makes an impact on their campus. Which products hold up. Which vendors deliver. What a welcome kit for a new cohort should have in it that nobody thinks to ask for.

That knowledge lives in our team. It shows up in past orders, in the vendor calls a rep takes on a Tuesday, in the public Slack channels where somebody says this supplier missed a date again, use the other one.

And until this month, a client got that knowledge exactly one way. A rep sat down and built them a presentation.

I want to be precise about what that means, because I missed it for a long time. A presentation is a rationing system. Our best thinking went to whoever was already in the pipeline. Whoever asked. Whoever a rep had hours for that week. Departments we'd worked with for years got it. A new department at the same school, a smaller school, a college outside California, those groups never heard of us and had to rely on a generic catalog from a competitor that any company in our industry could have handed them.

We weren't holding back. We were structurally limited to one client at a time.

What we built

Eight days, from the first schema migration on July 16 to a live end-to-end test on July 23. A public shop for education clients: browse, filter, cart, submit. The submission creates an estimate in our CRM, our system of record, and drops a notification in a Slack channel where the project owner and order rep pick it up.

The stack is the one I always use. Next.js for the front end, Supabase behind it, product data pulled from vendor APIs on a delta sync so the catalog stays current without a full re-ingest.

The part that took the real work was not the storefront. It was the ranking.

I could have shipped an industry best-seller list in an afternoon. Every distributor has one. It would have been worthless, because it would have contained zero of what we know. So the catalog reads our own signals instead. Past order history from our CRM sales reports seeds a demand ranking. Vendor decisions the team makes in public Slack channels influence which suppliers surface. When a rep learns something new about a vendor next month, that flows in too.

The team's expertise is not a snapshot I extracted. It's a live input. They keep building it the way they always have, on every individual order. The catalog just gives it somewhere to go.

What I got wrong first

Almost every correction I made in those eight days was the same correction: taking my own vocabulary out of the client's way.

Vendor style numbers were showing up in product titles. They mean something internally and nothing to a person buying sweatshirts for an orientation. Gone. Vendor names were visible on client-facing pages. That's our sourcing, not their concern. Gone. Vendor tags came through as raw supplier taxonomy, so I had to fold them into filter groups a human would recognize, apparel and hard goods and color and order quantity, modeled on what the big supplier sites already teach people to expect.

I also had to hide a long list of college names. Schools needed to find themselves in our system if we already work with them, or enter a new one if we don't, without ever seeing a long list that meant nothing to them. I went in treating it as a constraint. The constraint made the design better: nobody browsing a list of institutions, just a field that quietly matches or quietly creates.

Then there was the unglamorous half. The scheduled sync hit its three-hour timeout three days running before I found the duplicate ids behind it. Heavy vendor payloads blew past database statement timeouts until I chunked the upserts. One supplier ships raw HTML in product descriptions, and repeats the same part inside a single listing. There's an open question sitting with our CRM's team right now about how color comes through on estimates, logged as a gap rather than papered over.

None of that is in the pitch. All of it is the actual work.

Where it stands

The catalog is in final internal testing. It is not live to clients yet. We're targeting early August.

I'm saying that plainly because I've gotten it wrong in this newsletter before, describing something planned in the tense of something shipped. The end-to-end test ran on July 23 with a test client, and the submission landed in the CRM the way it was supposed to. That's a working pipeline, not a launched product.

The plan is to do this segment by segment. Education first, because it's where our expertise is deepest. We've had early conversations about which comes next, corporate or social impact or healthcare, and nothing is being built yet.

Why this is the same thing I keep writing about

I've spent this newsletter arguing that the distance between wanting to contribute and being able to contribute is the problem worth solving. Usually I've written about that distance sitting in someone else's system.

This time it was ours. The gap between what our team knows and what a client can reach was a rep's calendar. That's a structure. We built it, and it capped our best work at one relationship at a time.

Here's the part I didn't expect until I said it out loud this week. Branded merchandise, when it's any good, is a way in for somebody. A new employee kit is how a company says you're one of us on day one. A welcome kit for an incoming cohort is how a school does the same thing. An award is a way of saying your contribution counted.

Our clients are building ways in for their own people. We were rationing the thing that helps them do it.

That's what the eight days bought. The team keeps building the knowledge on every order. The catalog does the distribution.

More things are going live over the next few months. I'd like to write these as they ship, including the parts that break.

P.S. If you're sitting on expertise your organization is good at and your process only lets one person reach at a time, that's the thing to look at. Reply and tell me what it is. I read all of them.