Building a Live Shopping App with One-Shot AI

The humble programming tutorial has recently been thoroughly transformed from copy-paste toil to one-click wonder. Cinderella's fairy grandmother waved her magic wand and turned a pumpkin and mice into a fabulous carriage pulled by white horses; today's AI coding agents have an almost as magical-seeming ability to turn the barest of specs into a full-fledged application.

Stream's CLI tool is the magic wand for building realtime apps on web and mobile. It offers a powerful AI skill that knows how to generate and update complete applications that use Stream's API. It works so well that almost any classic Getting Started tutorial has effectively become a single line, like this:

/stream make me a video call web app with chat

The agent will go ahead and plan for the project, ask you to log in on Stream, create the app in your account, set it up with sensible defaults, and build a whole React single-page app for the example given above.

It's impressive to watch it work. But when you move past tutorials and experiments into real apps, you eventually run into problems. A one-sentence prompt simply can't describe your real world problem well enough to be a fully solid base for an app. Where the specification is lacking, the magic wand of AI will just go ahead and guess on the fly. Some of these guesses inevitably become bugs, or at least undesirable behavior that's already been baked into code and then you have to make an extra effort to get rid of it.

So when it comes to one-shot app generation, it needs to be well-grounded. By spending a bit more time upfront planning your design, you'll be saving a lot more time down the road by avoiding the slow iterations needed to fix AI's initial misassumptions.

Building a complete live shopping app

In this post I'll show you the design process used to create a one-shot application called VinylStream, a live shopping app that lets people buy and sell vinyl records online. Sellers can schedule live shows where they show their record finds on camera, and viewers can bid on live auctions and ask questions on Stream chat.

• Try it live: vinylstream-live-shopping-react-demo.vercel.app
• View the full source code: GetStream/vinylstream-live-shopping-react-demo
• Read the design document: vinylstream-concept.md

The exact steps are described in the companion tutorial, but it's so simple that you barely need to read it. I just created a new folder for the project, copied the design doc under docs, added the Stream skill using the getstream CLI, opened Claude Code, and entered this prompt:

/stream Build me the app described in docs/vinylstream-concept.md

Although this is a video-centric app, the lessons of this process are general. You can apply them to any realtime-oriented app you'd build with an AI agent. Stream's agent skill has a lot of built-in intelligence that routes based on target platform and use case, but it's always worth getting the basics right in your design phase. It will save you tokens and frustration.

In effect, the design document is the real source code. You still need to tell the computer what to do - that part of programming isn't going away. With AI and agent skills you can do it on a much higher level than thinking in terms of if sentences and API calls. So take a moment to get it right.

Something important to note about the VinylStream design document is that it was made for a demo and intentionally leaves some questions open so it can better function as an app skeleton. When you're bootstrapping a finished application, decisions can be settled already at the design stage. I'll highlight these differences when appropriate, so you'll know what transfers from VinylStream and what you can fix already.

1. Name the core pattern

Don't jump to discussing your specific vertical too early. If you tell the agent to build a "vinyl app" or "telehealth app", it will jump to optimizing surface features like buttons and screens rather than the mechanism that makes the app work. You get a demo that looks convincing, but feels wrong as soon as you try to do something in it.

For VinylStream, the core pattern is "binding canonical product data to a live video stream". That's the heart of any live shopping app, whatever is being sold.

Superficial mechanics can be misleading. If you think of live shopping as "QVC-style TV home shopping channel in a browser", you might assume the core pattern is "a video stream with a chat and a buy button". That would work for a single person experience, but the internet is not television - a live shopping app is both multiplayer (there are other people bidding) and uses multiple data sources (potentially thousands of sellers each making their own TV show). Your app needs to be aware of which item is live right now, where the price comes from, and who's winning. Stream's infrastructure and APIs will make sure the video and chat work, but to close the sale, you need to own the product experience.

Consider telehealth. It looks like "a video call with a doctor", but the call is the easy part. The core pattern is conducting a properly documented and consented clinical encounter tied to a verified patient and their record. Video is just one channel for what the doctor needs to know. If that's your business, Stream will let you handle the boring but complicated video part reliably, and you can focus on delivering results to patients and doctors. But you need to focus your AI coding agent's attention on that.

2. Map your realtime planes and the source of truth

Most realtime apps - well, the ones that do something useful or fun, anyway! - are not just one stream, but several planes running at once. For live shopping, there's video, chat, and shared application state like bids, auction status, etc.

When preparing your design document, list these planes. Then, for each piece of shared state, write one sentence: where does the source of truth live?

Traditional database-backed "CRUD apps" are fairly uniform in how data is treated. (Whether your entity is big or small, a CRUD app will expose the same essential API patterns.) For realtime, it's easy to apply that same thinking and assume that everything that moves in realtime is the same kind of thing. Video frames, chat messages, and an auction's current price all "update live," but they have completely different correctness requirements. If you let the coding agent blur these lines, it will often do whatever it finds most convenient in the moment when developing the solution because it's eager to move ahead. That could mean trusting a bid price which happened to arrive over the chat channel, or something worse. (Reading a product price from a video overlay? Why not? The data is right there...)

For VinylStream, the auction's current price, high bidder, and countdown are authoritative on the server. Bid events can ride the same realtime channels as chat - it's a fine transport for this purpose - but the ultimate truth lives server-side, never in a transient source like the seller's client or the chat stream. Video and chat are views of the auction, not the source of truth.

3. Find your integration seams

List the major parts of your app one at a time: video, chat, the product catalog, payments, shipping, notifications... Then mark each one with one of these labels: is it real, mocked, or shaped?

Real is what you build now. Mocked is a throwaway stand-in. Shaped is the interesting one, an in-between state where you expect things to evolve. You don't build it yet, but you design the data model to make it easy to drop in the real thing later.

AI agents will happily do "vibe mocking" where they fill in the gaps with whatever shape is easiest in the moment. Replacing those can be a complex rewrite. Providing the right shape early avoids those detours.

For VinylStream, shipping is an example of a feature that's the last one real sellers and buyers would encounter, so it would be easy to brush it aside as irrelevant. But a moment spent thinking and researching about the shape will help the agent focus. A state like "label printed, in transit" stands in for any real fulfillment. The data model underneath can already be shaped for the real thing, so each order carries a shipment with a destination address, a tracking reference, and a status that moves from pending to shipped to delivered.

For a demo, you wouldn't care if everything outside of the core pattern is mocked. But for a real app, the shape becomes important. Instead of "what can I fake?", you should be asking: "What are my seams to the outside world, and do I know their shape already?"

4. Decide your external dependencies

In the previous section you drew the boundaries. Now look at that other side which is out of your control: things like third-party APIs, keys, rate limits, licensing, network quality... And make decisions about each.

If decisions are not laid out explicitly in your design, an agent may guess in ways that become expensive (or at least annoying) to undo: it wires up whatever API call looks "obvious" with no key management, has no fallback for when the service is down, and so on.

For VinylStream, there was a big external dependency: the catalog that provides the vinyl records. Thanks to the tireless efforts of vinyl fans, there exists a free site called Discogs which provides exactly the canonical database we need. We don't want to abuse their API or their terms, so the catalog for this demo was built from the Discogs monthly data dump - a full XML export under a CC0 public domain license - rather than by hitting the Discogs API for each request. It makes the demo run smoothly because the data is always available.

This is the section where a real app would diverge most sharply from the VinylStream demo, so be careful when copying from it. For a demo, you want to eliminate external dependencies to make sure it works everywhere. A real app on the other hand wants the opposite: it needs to solve problems like getting the fresh record inventory and dealing with practical issues like Discogs' API terms (if you build a product on someone else's data, it's highly advisable to get legal advice early on). The exercise is the same - enumerate your dependencies - but the answers tend to run in the opposite direction. So be careful about copying a demo's decisions into a real product.

5. Trace your critical user paths

Language models know an awful lot of things that they've read on the internet, but so far nothing beats human intuition about how things should actually work. You should tell the model explicitly what happens inside the app, rather than trust that it can play human long enough to figure it out.

So write the shortest end-to-end user paths that exercise the core pattern. One sentence per role is enough. Then write down what's explicitly left out.

For VinylStream, the seller side is: create a show -> add about five items via Discogs search -> go live with the item queue.

The buyer side is: join the stream -> see the current item card -> bid -> win -> cart. Explicitly out: real payments, shipping, notifications.

For a demo or throwaway prototype, those "out" features never get built, they're just design placeholders that feed the audience's imagination. In a real app, "out" instead means "deferred to phase 2". So the critical path doesn't change, but how you track the missing features is different. You can ask your AI agent to maintain another design document for what you need to build beyond the one-shot.

The design document is the real source code

AI hasn't taken away the essence of programming, and probably won't: deciding what the thing should actually do. A language model is great at typing API boilerplate, and it can also role-play all kinds of scenarios, but ultimately only you know why you're building something and why someone might want it. Everything discussed in this blog post is about getting you faster to the point where that motivation can be expressed and validated in working application code.

The one-shot magic wand really does work. But if you point it at a vague wish, you get a vague result. (Or, to continue with my Disney analogies, worst case is that you end up like Mickey Mouse in "Sorcerer's Apprentice" and your agents are running amok doing things on their own, completely oblivious to your wishes because you didn't express them clearly enough...)

And notice how little of the thinking involved here was about video or chat specifically, even though we built a live shopping app whose hardest technical bits are those realtime components? That's the whole point. Stream's APIs and skills makes the realtime plumbing reliable and auto-scalable and boring, so you can focus on doing the product work that only you can do. So why not start building today? You could have something real up and running in less than an hour, armed with any old LLM and the Stream agent skill.