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, for 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, because 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 and 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. 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.