OpenAI's GPT Store may create developer lock-in through hosted files, code execution, function calling, and distribution, although Gregory Kamradt is cautious about whether users will adopt it.
2
AI applications become defensible through customer problems, distribution, partnerships, brand, network effects, and platform effects because prompts alone are easy to copy.
3
Small, specialised models could support niche workflows, while an AI gateway could route requests to the model or system best suited to each use case.
Summary
Gregory Kamradt and Demetrios Brinkmann discuss OpenAI DevDay, the GPT Store, GPT-4 Vision, retrieval, model lock-in, and product defensibility. Kamradt sees GPT-4 Vision through an API as one of the most useful announcements because it enables repeated image-based workflows rather than one-off analysis. He is less certain about the GPT Store, since its success depends on user adoption and the value of its revenue-sharing model. He argues that OpenAI is building developer lock-in around hosted files, code interpreter, and function calling, while the underlying models remain easier to replace. The conversation then turns to building AI products. Kamradt says founders should start with a customer problem and payment before worrying about technical defensibility. He describes a prototype that records startup pitches, transcribes them with Deepgram, and retrieves industry news and follow-up questions. They also discuss niche applications, smaller local models, context-window testing, fine-tuning, and the possible role of an AI gateway.
GPT-4 Vision becomes more useful when applications can use it repeatedly
Gregory Kamradt says GPT-4 Vision through an API was the OpenAI announcement he found most exciting. His earlier analysis used one-shot examples through the user interface, where a person supplied an image and received one response. API access makes iterative workflows possible. He gives the example of a webcam that sends an image every few seconds and asks GPT-4 Vision to identify what it sees. Demetrios Brinkmann adds a business example involving faxed orders. A team currently receives PDF versions of faxes and manually transfers fields into an order form. A vision model could turn those PDFs into CSV data, making the process much easier to automate.
The GPT Store is promising, but its adoption is still unproven
Kamradt describes a GPT as a prepackaged chatbot that can receive documents, use them for retrieval, and connect to tools such as code interpreter. Users could share these bots through a marketplace, which invites comparisons with Apple's App Store. OpenAI's planned revenue share gives developers a reason to create and market useful bots. Kamradt remains cautiously optimistic because the model is new and it is unclear whether users will naturally seek specialised bots. He also expects paid acquisition to appear once bot creators can measure customer acquisition cost and lifetime value. Demetrios questions whether OpenAI will own this marketplace, since complex assistants may need more than one model or a single provider.
OpenAI is creating developer lock-in above the model layer
Kamradt argues that models themselves have limited defensibility because developers can switch between providers with tools such as LangChain, or run models locally. OpenAI's more interesting move is to build lock-in through surrounding functionality. It hosts user files, runs code through code interpreter, and provides function calling and structured JSON output. Developers who build around those features may find it harder to move to Google or Anthropic. Demetrios Brinkmann agrees that reliable JSON output quickly becomes an expected baseline. Kamradt says OpenAI needs competitors to respond because it wants attention without becoming the only company with almost all of the market.
Orchestration tools remain useful when developers need control over retrieval
Demetrios asks whether OpenAI's built-in retrieval makes tools such as LlamaIndex and LangChain unnecessary. Kamradt rejects that conclusion. OpenAI may offer good general retrieval, but developers still need to know how retrieval works and whether it fits their particular domain. A no-code user can attach PDFs to a GPT and accept the default behaviour. A specialised application may need control over chunking, search, ranking, and other retrieval choices. Kamradt expects orchestration tools to remain useful for those cases. Demetrios also mentions DSPy, which Kamradt has not tried. Their discussion connects its compiler idea to testing multiple prompt or function strategies and selecting the one that performs best under evaluation.
Customer demand comes before technical defensibility
Kamradt says successful products start with a customer problem and people willing to pay for solving it. He cites the idea of making a small group love a product rather than making a large group merely like it. For defensibility, he points to the same sources that protect traditional businesses, including network effects, platform effects, sales, distribution, partnerships, and brand. Prompts are a form of technical intellectual property, but competitors may reproduce them quickly, so they provide only a short head start. The falling barrier to building AI software makes those other forms of defensibility more important. Kamradt is willing to choose an easy-to-copy product with a million users over a defensible product with no users, because user demand creates something to improve.
Niche AI applications can remain attractive to small builders
Kamradt agrees that narrow applications can provide room for independent developers and small companies. A niche may be too small to attract Google or another large company, while still being large enough to support a focused product. Demetrios connects this idea to image-generation applications, where obvious selfie and profile-picture products quickly attracted competition. A specialised workflow, such as a model adapted to a particular professional field, may face less direct competition. Kamradt does not claim that niche selection alone guarantees success. His broader point is that the opportunity can be large enough for a small business while remaining below the priority threshold of a major technology company.
A live companion can turn multimodal models into a product workflow
Kamradt describes an application he is building for startup pitches. It records a pitch on a phone, transcribes the audio with Deepgram, and passes the text to a language model. The first output is a summary. Further steps retrieve relevant industry news, identify the founders and their backgrounds, and generate follow-up questions that may expose weaknesses in the pitch. He sees the same pattern applying to university lectures, interviews, sales meetings, conference booths, and other live situations. The initial version is deliberately narrow, while the underlying pattern can be generalised. He says the largest practical blocker is finding suitable startup-pitch events to test it on.
Context-window size should be tested by both length and position
Kamradt explains a retrieval experiment for GPT-4's 128,000-token context window. He places one sentence containing a fact about eating a sandwich in Dolores Park inside a much larger body of text, then asks the model to retrieve that fact. He varies the total context from 1,000 tokens up to 128,000 and also changes where the fact appears, from the beginning through different depths in the document. This creates a two-dimensional test of context length and position. He says the experiment cost about $200 in GPT-4 API usage. The background text consists of Paul Graham's essays. Kamradt argues that the results could help developers understand where retrieval works best, although he also says passing 120,000 tokens can indicate weak retrieval.
Smaller models and fine-tuned models may support specialised routing
The conversation turns to an AI gateway that could route requests to different models or services. Kamradt expects small, fine-tuned models for niche use cases to become more common, although he has not yet seen that pattern widely deployed. He also expects OpenAI to allow GPTs to run on fine-tuned models, since the current GPT configuration mainly changes files, prompts, and tools on top of a shared base model. Demetrios suggests that a gateway could recognise a legal request and send it to a legal model, while routing an unclear request to GPT-4. Kamradt treats this as a plausible direction rather than a settled product pattern.
"If you told me do I want a defensible business with no users or do I want an undefensible business with a million users that I can go iterate on I'm picking the latter all day long."Gregory Kamradt42:18
Who should watch
You are deciding whether to build an AI feature around one model provider's APIs and want to understand where lock-in may appear.
You are building an AI application and need a practical way to think about customer demand, niche selection, and defensibility.
You are testing long-context retrieval, multimodal workflows, or live assistants and want concrete product examples rather than general predictions.
