Let Anyone Try It Without Breaking Anything: Demo Mode for Vibe Projects

The example product and people in this article are fictional, used only to explain the approach. Suppose you built an app called "Orange Workshop" that helps a pottery studio manage class bookings, sell material kits, and collect students' finished-work photos. Three months after launch, its founder, A-Ju, hits an embarrassment: every demo for a potential customer or investor starts with half an hour of fabricating data — registering a fake account, inventing a few classes, uploading a few work photos — and afterwards she has to be careful not to leave the fake data in the real database. Once she forgot to clean up, and a demo "test student Zhang San" showed up on the real graduation list; customer service even sent "Zhang San" a graduation text. This guide solves that problem: build a proper demo mode for your vibe project, so anyone can enter a sandbox with one click — data that looks real, flows that run end to end, and zero chance of polluting real data.

First, get the concept straight. Demo mode is not test data, and it is not a demo script. Test data is the seed content you use while developing, serving yourself. A demo script is the patter and click sequence you prepare for one particular walkthrough, serving one presentation. Demo mode is a formal feature inside the product, serving every first-time visitor — potential customers, investors, app-store reviewers, even your own new hires. It has three hard standards: it must look real, with data that resembles genuine business output; it must work completely, with core flows running start to finish rather than popping up "not supported in demo" after two clicks; and it must be absolutely isolated — nothing done in demo may write to the real database, send a real notification, or spend real money.

Demo mode comes in five common shapes, and you do not need all of them — pick the one that matches your product's stage. The first is a public demo site: a separately deployed, read-only or resettable instance whose URL you can proudly post on your website and social media so anyone can look without registering. Its advantage is the lowest distribution cost; its cost is maintaining an extra deployment and making sure demo data cannot be flooded with junk by malicious users. The second is one-click trial accounts: a "try without registering" button on the login page that drops you straight in as a demo identity with preloaded data, wiped on exit or on a timer. The third is sandbox tenants: inside the real product, each demo user gets an isolated tenant space with exactly the same data structure as a real tenant, just flagged as demo and reclaimed periodically. The fourth is a recorded walkthrough: a carefully prepared interaction recorded as a guided flow where the user clicks "next" and the page moves along, but no real business logic runs behind it — suitable for early products that only want to show the interface. The fifth is a read-only mirror: a sanitized snapshot of the real product synced to the demo environment on a schedule, where users can look and click but not change anything — suitable for products whose data itself is the selling point, such as dashboard apps.

For most solo projects, I recommend starting with the second shape: one-click trial accounts. It costs the least to build — one demo identity, one set of preloaded data, one exit-and-cleanup routine — yet covers the most common demo scenarios: sending it to a friend, posting it to Product Hunt, sending a link to an investor. It also has an advantage a public demo site lacks: demo users walk the exact same code paths as the real product, so when you change a feature, the demo changes with it immediately, with no second interface to maintain. When bulk demo demand arrives, or demo traffic grows large enough to affect the real service, upgrade to sandbox tenants or a standalone demo site.

Demo data must look real, but must not be real

The first gate demo mode must pass is data. Data that is too fake gives itself away instantly: three students, two classes, every name starting with "Test," and the audience knows at a glance this is an empty shell. Data that is too real causes trouble: using real customers' names and photos for demos exhibits other people's information. Good demo data meets four tests. In quantity, it must resemble reality: a pottery studio should have dozens of students, a dozen-plus classes, and booking records spanning months. In relationships, it must resemble reality: students must have taken classes, classes must have teachers, times, prices, and minimum and maximum headcounts. In time, it must resemble reality: completed classes in the past, classes in progress today, bookable classes ahead — the timeline must not break off on some arbitrary day. In detail, it must resemble reality: work photos should look like genuine pottery photography, and comments should read like human speech, not the AI-flavored "very good" and "nice" repeated everywhere.

How, concretely? Start by giving your demo data a "seed version." Write the demo data as a versioned seed file — say, demo-seed-v1 — containing complete business objects and the relationships between them. The version number exists so that when the product's data model changes, you bump a version instead of quietly editing a few rows and letting the demo drift. Names, places, and work titles in the seed should all be fictional but plausible: students named like real people rather than "Test User 1," classes named "Saturday Morning Wheel-Throwing Basics" rather than "Test Class A." Photos should be your own product photography or images explicitly licensed for commercial use — never grab a real customer's work photos off the internet.

One category of data is most often forgotten: dirty data. Real business is never spotless: there are cancelled bookings, students who took leave, sold-out kits, prices that were entered wrong and corrected. Deliberately leaving one or two such "rough edges" in demo data makes it more believable — an audience that sees a "cancelled" booking record feels the system genuinely handles real business. But rough edges need moderation: one or two read as realism, a screen full of them reads as a buggy product. My rule of thumb: 90% of demo data is smooth happy path, 10% is exception states that have already been handled properly, and every exception should show its resolution next to it rather than hanging as an unexplained error.

Time feel is another key. If all demo data is dated today, the audience feels the product launched yesterday; if it is all last year's, they feel it is unmaintained. The right approach is to anchor demo data to today dynamically: the seed file stores relative times ("3 days before class starts," "2 days after graduation"), and each time someone enters demo mode, absolute dates are computed from the current day. That way, whenever anyone opens it, they see "a class just finished yesterday, three more bookable tomorrow." Implementation is simple: compute dates in the seed-generation function as today minus or plus a few days — never hardcode a specific date in 2026 into the data.

Write isolation is demo mode's life-or-death line

The most dangerous part of demo mode is never "looking fake" — it is "writing into a real place." The root cause of A-Ju's accident was demo and production sharing one database, with "remember to clean up" as the only safeguard. The right approach builds isolation into the architecture, not into verbal promises. The cleanest option is tenant-level isolation: every demo user's rows carry a demo tenant identifier, all queries default to the current tenant, and a demo tenant's data can be deleted wholesale. A step down is database-level isolation: demo traffic goes to a separate database or schema, split at the entry point by connection string. The least recommended option — though the one many solo projects actually use — is flag-based isolation: adding an is_demo column to every business table and conditioning every query on it. That road works, but you must guarantee no query ever drops the condition; a single miss is an incident.

Beyond the database, four outbound channels must be blocked. First, notifications: texts, emails, and social-account messages triggered in demo must all be intercepted and turned into demo logs or on-page displays — they must never actually go out. In practice, add a check at the notification service entry: demo-tenant requests are logged and returned as success without ever reaching the real SMS gateway. Second, payments: when demo flow reaches checkout, use either the payment platform's sandbox environment or a simulated success page — never the real money-collection channel. Third, third-party sync: demo data must not sync to your CRM, analytics platform, or ad attribution system, or fake data will pollute real business reports. Fourth, file storage: images uploaded by demo users go into a separate demo directory and get cleaned up periodically, so nobody uses your demo mode as free image hosting.

The page itself must also make the demo identity unmistakable. In demo mode, a persistent banner at the top of the page should state clearly, "You are viewing demo data; nothing you do here affects real business," with a prominent "Exit demo" button. The banner is not decoration: it protects all three sides — visitors will not mistake themselves for operating real business, presenters will not be mistaken for real users, and you will not later be asked why demo mode could see someone's data. Demo account avatars and names should also be recognizable at a glance, for instance a uniform "Demo Visitor" label with a visible demo badge — never disguised as a real user.

One-click reset: demo mode's self-healing ability

Soon after demo mode goes live, a new problem appears: visitors click around wildly. Someone changes a class price to zero, someone deletes all students, someone uploads a strange image — and the next visitor walks into a product that has been trashed. Demo mode therefore needs self-healing, centered on one-click reset. The reset button belongs next to the demo banner: one click restores the current demo tenant's data to the seed version. Reset granularity can have two levels: a soft reset restores only business data (classes, bookings, orders) while keeping browsing traces; a hard reset rebuilds the demo account itself back to the original seed state.

On top of manual reset, add automatic reclamation. Two strategies stack well: idle reclamation — a demo tenant with no activity for 24 hours resets automatically; and scheduled reclamation — every night, all demo tenants reset to the seed version together. The benefit of scheduled reclamation is that every morning you know the demo environment is clean, without a last-minute check before an important demo. Implementation note: reset itself must be idempotent — running the same reset request twice must produce the same result as running it once, so concurrent resets cannot leave data half-restored. Also, do not pop a "Are you sure you want to reset?" confirmation before resetting — demo data is disposable by nature, and a confirmation dialog only breaks demo rhythm. But the reset button must never appear in production mode; demo and production entry points must stay separate.

Seed versioning earns its keep again here. When you add a feature to the product, demo data must grow with it: a new feature with no corresponding demo data means visitors click into an empty page. My practice is to put "demo data upgrade" on the release checklist: before every release, ask, "Is the new feature visible in demo mode?" If the answer is no, either add seed data for it or temporarily hide the new feature's entry in demo mode — an empty page hurts a demo more than a missing feature, because it looks like a bug.

Exit path: a demo should end in signup, not in closing the tab

An easy mistake in demo mode is designing the entrance and forgetting the exit. Visitors finish trying, close the page, and leave — and you never learn who they were. Good demo mode designs the exit as part of the conversion funnel. Step one is a visible conversion entry: on the demo banner and at the end of key flows (for example, after completing a simulated booking), place a "Do it again with a real account" button that leads into registration. Step two is bringing work along: if visitors built something in demo (say, a class schedule), registration should let them import that configuration into their real account with one click — note that it is the configuration, not the demo data itself; fake students and fake orders must not follow them over. Step three is collecting feedback, but lightly. At the end of a demo, a feedback box of at most three questions works: which feature attracted you most, where did you get confused, and would you leave contact details? Beyond three questions, completion rates fall off a cliff; contact details must be optional, because forcing an email scares away people who were actually interested. Feedback data must be stored separately, never mixed with real users' feedback, or demo visitors' opinions will skew your analysis.

Abuse is one more problem that only surfaces after launch. Once a public demo link is discovered by crawlers or bargain hunters, someone will bulk-register demo accounts to flood junk data, someone will use the demo upload endpoint as free image hosting, and someone will hammer demo forms with test requests. Abuse prevention does not need to be heavy, but three baselines should exist: rate-limit demo account creation so one IP can only create a few demo tenants in a short window; cap total demo data volume so a single tenant's classes, orders, and images beyond a threshold are rejected with a prompt to reset; and rate-limit demo write endpoints separately from production so a demo traffic spike gets throttled on the demo side first, protecting production. Those three baselines plus scheduled reclamation keep a demo mode publicly linkable for the long term without being trashed.

Finally, a pre-launch checklist to tick off item by item before publishing demo mode. Data: seed data has a version number, its timeline anchors to today, it contains a few already-handled exception states, and it holds no real customer information. Isolation: demo and production tenants are separated at the database level or by tenant identifier; the four outbound channels — notifications, payments, sync, storage — are all intercepted; the page carries a persistent demo banner with an exit button. Reset: manual one-click reset works, idle and scheduled auto-reclamation are configured, reset is idempotent. Conversion: the registration entry is visible, demo configurations can import into real accounts, the feedback box asks no more than three questions. Monitoring: demo visits, reset counts, and conversion rates are tracked under separate metrics, never blended into production numbers. If any of the ten items is missing, do not rush to publish the demo link — a demo-mode incident costs far more than having no demo mode at all.

Anti-patterns, for those in a hurry. Do not use real customer data for demos, even if it is "just for one investor look." Do not publish a demo link with the demo account password set to 123456 — demo mode gets found by scanners too, and it will be flooded with junk data. Do not leave any hole through which demo mode can send real notifications; "it usually won't trigger in demo" is the most common pre-incident sentence. Do not build demo and production as the same dataset plus a "currently demoing" flag unless you can guarantee every query carries the condition. Demo mode is essentially one promise: visitors can click around recklessly, because nothing here will come true. Keep that promise, and demo mode is your cheapest acquisition channel; break it, and it becomes your most expensive source of incidents.