Coffee With iChef Co-founder Spencer: Design Context and Telling a Story a16z Can Hear

I met Spencer, co-founder of iChef, for coffee. It was meant to be a catch-up, but we spoke for almost ninety minutes—from what software products are made of to my upcoming trip to the US and an interview for a16z's Speedrun accelerator. These are edited notes, roughly in the order we talked.

The three kinds of context in a software product

Spencer recapped a framework he has repeated many times because it remains useful: a software product is built from three layers of context.

The first is product context: the product-management questions of what to build, where the commercial opportunity is, how it makes money, and how to design metrics. People often include schedule and communication management in a PM's work, but that is project management, not product context.

The second is design context: the forms people expect when interacting with a machine or interface in a particular setting. A consumer login might be a pop-up in the upper-right corner; an enterprise product may require its own page, with a column explaining the solution, because that ritual signals that this is a serious system. A game's back button belongs in the lower-right because it suits the right hand. Restaurant sites use bright colors because dark palettes can suppress appetite. These preferences are social and cultural knowledge—even a coffee shop's interior is a kind of UI.

Agents currently do not know or care about these things. Ask one to choose colors and it will not know that a color can be offensive in a particular culture.

I asked Spencer whether design context should be designed by people or learned by agents. His answer was that people still need to supply it, though tools are exploring the direction. Coda can begin with an imagined screen, where implicit information such as button placement and color brightness is contained in an image, then reverse-engineer it into code. Co-design and Google Stitch use a variation strategy: you give a request, they produce several options, rather than interviewing you to understand product context. Active interviewing is much harder: first you have to recognize whether the conversation is about a restaurant context or something else. People are good at recognizing who they are speaking to and what situation they are in; agents currently are not.

My conclusion was that a truly general design product probably has to follow the variation path. A design product for a specific market has a chance to pursue interviewing: harder, but potentially more valuable.

Before the a16z Speedrun interview, the story was not clear yet

The conversation shifted. The next month I was flying to the US, initially for a month and possibly to stay longer. I was also working on an open-source project, OpenSlide: nearly 3,700 GitHub stars, slides generated with agents such as Claude, and a four-person team. The other three are engineers; I handle Growth and GTM. Andrew Chen, who leads a16z Speedrun in Los Angeles, had reached out and invited us to interview.

Spencer asked, “Who came up with the GTM model?” I said we did not have a mature one yet—mostly posting intensely on X and growing GitHub stars—and that defining GTM was my responsibility. He immediately named the problem many Taiwanese teams hit: they build solid products but cannot package them into a story investors understand and get excited about.

Investors are not looking at your technology. They are looking for whether you understand your market, how you build a GTM platform, why it works, and where the moat is.

He described a team from a venture community that used edge-device AI to analyze current frequency and predict when water-infrastructure motors would fail. It had begun working with Taiwan Power and the Taipei city government and had correctly predicted a failure six months earlier—hard traction. But its pitch focused on motor systems and ECB, and reviewers could not follow. Spencer said the story should have been: simple plug-and-play, it starts collecting data immediately, and six months ago we accurately predicted a failure. Keep it simple; reviewers do not need to understand the technology.

He gave another example: an alumnus building NFC hardware security was asked how large the business could scale and answered with technical details, never addressing business scale. That engineering mindset is common and understandable among Taiwanese engineers, but fatal at a pitch table. The founder wanted to stress that it was something nobody had done before; Spencer noted this cuts both ways. It is hard to make someone believe in something nobody has done. “Like Airbnb, but for X” is often easier to understand because the market has already been validated.

Tool-based or workflow-based? The OpenSlide moat question

Back to OpenSlide. Our original direction was a Better Gamma: an AI slide tool with stronger output. Spencer pushed further: where is the moat? If Gamma builds the same thing, or Claude's native slide capability keeps improving, how do we defend it? This is a direct fight with Gamma and Canva, and Google could crush the market if it chose to spend. The vision was not exciting enough for investors and the market was too competitive.

That split the direction into two layers:

Tool-based: make OpenSlide the most complete tool, with the best one-shot output and Claude-assisted research. This is the current path.
Workflow-based: distill the presentation workflows of different roles—founders making pitch decks, salespeople making lead magnets, consultants making decks—and embed OpenSlide in their existing work rather than forcing a new tool. Win one role at a time, similar to HeyGen's role-specific solutions.

Spencer also named a more practical risk: open-source commercialization is not inherently safe. A newly graduated lawyer recently open-sourced a legal-AI tool for free personal use. For a law firm, hiring two engineers to customize the open-source version can be cheaper than paying a large platform thousands of dollars a month, directly destroying the high-priced platform.

Every software company has moved into AI, and every new model makes everyone afraid of disruption. Startup lifetimes are shorter too: a company can reach millions of users in one or two years, then be absorbed by a platform or find a way to defend itself.

Trust, decision-makers, and the fact that B2B founders sell insight

On actually selling into an enterprise, Spencer shared a Silicon Valley example. A chain-brand customer used different POS systems in the US and Australia: two terminals, two training programs, and high employee turnover, so the same work was repeated by two departments. The real pain was not that the system lacked power; it was training cost. A web-based solution could run on an iPad, move the whole training program online, and create a direct cost saving.

You need this kind of insight or you do not know which feature to build. Insight is expensive. What a B2B software founder ultimately sells is insight, not the tool itself.

I raised a common pain point: can you really ask customers to replace their entire ERP to use our system? Spencer said no—it is too painful. Mentioning “integrating all information” immediately alarms ERP vendors. He noted a difference between Taiwan and the US: the US responds more to cost comparisons, so an AI agent that is slightly worse but much cheaper can work; Taiwan responds more to the FTE frame, where you first need to show how existing people become more effective rather than ask them to replace a system.

He also noted that the decision-maker is not always the CEO. A CEO can be captured by IT—“I do not understand technology, so if they say it is right, it is right.” The actual pivot may be someone in IT, and you need a relationship with them first. After landing a first lighthouse customer, the next question is: what characteristics do these customers share? That is the key to scaling and to defining the next ICP.

Find the small market with the deepest pain

We ended on a basic but often overlooked idea: win a small market with the deepest pain, then spread outward. Spencer used consultants as an example. Consulting firms make decks constantly, with demands for formatting and data accuracy that are very different from a typical startup.

I said OpenSlide's original niche was developers. Its users came from GitHub; they often need to present, but do not enjoy or want to spend time on layout. We also had a Discord community of seven or eight hundred people interacting every day.

Spencer's response was: that is the story you can tell. Real users and an active daily community are traction and evidence. Survey that group, turn their feedback into “these are the problems we are solving,” and that is a story a16z can hear—not a list of features we built.

Before leaving, we wished each other luck. I wished him well at his pitch competition the next day; he wished me well with the Speedrun interview. In my first day or two in the US, I planned to sit down with the team, clarify the story of what we were selling, and then go meet a16z.