Oyster AI

A reseller’s solutions architects turn a client’s requirements into a defended architecture, a set of vendor configurations, and the collateral that wins the deal. By hand that’s twenty minutes to six hours per configuration — and only someone deep in that one vendor can do it well. The expertise is siloed and the throughput is capped. We started Oyster open — anyone configuring their own procurement — and learned the market doesn’t want to self-serve; it wants to be a customer, with someone to turn to. So we built for the resellers themselves, and we hold the licenses to sell across the major enterprise vendors. The strategy is narrow then wide: take one vendor to near-perfect, then expand vendor by vendor and team by team.

You open a case and define it — the client, the vendor, the scale. Oyster generates a case overview to work against, then an architecture, then as many configurations as the deal needs, through a conversation with an agent that looks up and builds against real vendor catalogs and article specifications. From there you compare configurations, analyze them from any angle, ask which one fits a given use, and generate the sales material — presentations, one-pagers, PDFs. Case to client-ready in minutes. And it slots into the real workflow: build every configuration in one place and export straight into the vendor’s own platform, with direct API hand-off on the roadmap.

Across the three of us, the product experience is mine: every flow, the branding, the look and feel, and the value features themselves — the comparison views, the document and deck generation — built from design through to the shipped code. My thesis is an adoption thesis. Advanced capability only gets used if it feels frictionless and premium; get one small thing wrong and that friction is what the user remembers, not the value underneath. Making something genuinely advanced feel simple and balanced is the work — and I’ve taken cohesive responsibility for it since day one.

Document and artifact generation. Every output is editable — by AI or by hand — and the HTML artifacts (decks, one-pagers, dashboards) are surgically editable: select a piece, describe the change, the system makes it. Under it sits a system I built of themeable primitives — real components, styled per theme and filled with each case’s data — so generation is composed, not improvised. It saves a great deal of token cost every run and, more importantly, it doesn’t drift: you get what you expect, every time. The same discipline runs through the engine we built as a trio — cost-aware, with scheduled self-evaluation running nightly.

The lesson under all of it: order an LLM to build something and you get a confident, surface-level answer — models are people-pleasers. A real product means breaking each feature into six-to-eight smaller, self-evaluating deliveries, each held to a Grade-A bar — close to perfect, passing its tests — before it counts as done. And because AI-generated interfaces drift toward generic, I built a design language the team and the AI build against, so nothing ships looking AI-sloppy. That’s the judgment this kind of role is really about — getting AI from “this could work” to something you’d put in front of a client — and I now carry the method into every project.

CPO & co-founder, one of three — the team behind Heywire. I co-originated the concept and the business plan with our CEO, and strategy is the trio’s. I own the entire client-facing product, design through code; we built the engine together, with my co-founders leading the vendor-article validation loops. Honest stage: live, pilot underway — judged on the build and the pilot, not traction.