Showcase
Built with code-anything
Apps people built here and chose to publish — every one a real deployment at a real URL, and every one open to remix. Start a project from the same brief, template and palette, then take it somewhere else entirely.
// opt-in · reversible · no code, data or secrets ever travel with a remix
Live apps
Apps people built and published
Listed newest first. Each one is opt-in, live at the moment it was published, and open to remix by anyone with an account.
Loading apps…
A screenshot of the live page
Not a mockup and not artwork. A browser visits the app’s public URL after it is published and captures what it renders. While an app stays listed, later deploys re-capture it, so the picture keeps up with the app. If a capture fails, the previous image simply stays.
A title and blurb the owner wrote
Both are optional and written by the person publishing — a showcase title of up to 80 characters and a blurb of up to 160. Leave them blank and the card falls back to the project’s own name with no description.
A remix tally
How many projects have been started from this one. It counts every child project, listed or not, and names none of them — it is an attribution total, not a list of who forked what. Cards with no remixes yet show no badge at all.
A Visit link to the running app
Opens the app’s real hosted URL in a new tab. Nothing on this page is a sandbox demo or a video — if a card is here, the deployment behind it was live at the moment it was published.
Start here
What this page is, and what gets onto it
Not a curated design gallery and not a set of demos. A list of working applications whose owners flipped a switch.
Most galleries on the internet show pictures of things. This one shows applications that are running right now. A project cannot be listed here until it has an actual deployment behind it — the publish action checks for a live deployment and refuses without one — so every card links to software you can open, click through and judge for yourself. If the app breaks, the card leads somewhere broken; there is no polished screenshot standing in for a build that never shipped.
Getting here is entirely the owner’s decision. Every project starts unlisted, and stays that way unless someone deliberately publishes it from the project’s own deploy page. There is no automatic promotion of new builds, no crawler picking up apps that happen to be live, and no way for anyone else to add your work to this page. The same switch turns it off again.
The apps themselves come from the whole range of what the platform builds — storefronts, booking flows, dashboards, marketplaces, portfolios and internal tools. If you want to see the design systems those builds start from, the template library is the place to browse; the platform overview walks through what happens between a prompt and a live URL, and capabilities covers what a build can actually do — database, authentication, email, payments and the rest.
Before you publish
What publishing makes public — and what it never touches
The gallery is served through a fixed list of safe fields. Here is exactly what is on that list, and what is deliberately kept off it.
Public on this page
- The project’s name, or the showcase title you write instead
- The short blurb you write, if you write one
- The live URL, linked straight from the card
- A screenshot of that live page, re-captured on later deploys
- The template the project started from, and the date you published
- A count of how many projects have been remixed from it
Not on the list
- Your source code and files — the gallery never serves them
- Your build sandbox and anything running inside it
- Your database and every row in it
- Connected accounts and environment secrets
- Internal identifiers — the project, its hosting and any connected repository
- You: no author, account or email is attached to a card
The distinction worth understanding
Publishing does not make a private app public. It lists an app that is already public. The requirement to be live first is exactly what makes this true: by the time a project is eligible for the showcase, it is already deployed at a URL that anyone with the link can open. Adding it here changes its discoverability, not its reachability.
Which means the real disclosure surface is the application itself, not this page. Anything your deployed app serves — a page, an API route, records it renders without asking who is asking — is reachable by anyone who visits it, whether or not it ever appears in a gallery. That is worth a pass before you publish, and it is worth a pass even if you never do. The documentation covers how a project handles environment variables and connected services, and capabilities covers the authentication that decides who can see what inside your app.
One thing that is easy to miss: your brief — the description the project was built from — is not shown anywhere on this page, but it does travel into a remix. If the brief contains something you would rather not hand to a stranger, edit it before you publish. The next section explains why.
Remixing
What remixing an app actually copies
A remix is not a fork of someone’s codebase. It is a new project seeded from the ideas the original was built on.
This is the part people usually get wrong, so it is worth being blunt about. Pressing Remix does not clone a repository, copy files, or give you access to anyone else’s sandbox. It reads four durable inputs from the published project — the template it started from, its design template, its colour palette and its brief — and starts a brand new project of your own from those. Nothing crosses between the two accounts except those four things.
The new project arrives as a draft named after the original with “(remix)” on the end, and it opens in the scoping conversation rather than building immediately. That is deliberate: you get to reframe the idea in your own words before a single file is written, which is what makes a remix a starting point rather than a copy. Because it is generated again from those inputs rather than duplicated, the result will not be identical to the app you remixed — the same brief and the same palette can produce quite different software.
Carries over into your remix
- The template the original was built on
- Its design template and colour palette
- The brief — the description behind the original
- A recorded link back to the app you remixed
Never crosses over
- Source code, files and commit history
- The original’s sandbox or any access to it
- Its database and every row of data in it
- Connected accounts, keys and environment secrets
- The deployment, the URL and any custom domain
What happens on both sides
On your side, the remix is an ordinary project from that point on — yours to build, to change beyond recognition and to publish here yourself once it is live. Its lineage is recorded, so your project can show which published app it began from. You need an account, since the project has to belong to someone: pressing Remix while signed out sends you to log in and brings you back here afterwards. If you already own a project with that name — a previous remix of the same app, or anything else you happened to name the same — you will be asked to rename or delete it first.
On the original owner’s side, the only thing that changes is the tally on their card ticking up by one. It counts remixes; it does not name them, link to them or reveal anything about them. Someone remixing your published app learns nothing about you that the card did not already show.
Publishing
How to publish your own app to the showcase
Four steps, no application form and no review queue. The only hard requirement is that the app is genuinely live.
1 — Build the project
Describe what you want in chat, or start from a design in the template library and change it from there. Nothing about publishing changes how you build; a showcase entry is just a switch on a project you already have.
2 — Go Live
Publishing requires a live deployment. Until the project has one, the panel reads “Go Live to publish to the showcase”, and the API refuses the request outright with “publish requires a live deployment — Go Live first”.
3 — Publish to showcase
On the project’s deploy page there is a Public showcase row with a Publish to showcase button. It offers the optional title and blurb before confirming, so the card carries real words instead of a bare project name.
4 — It appears immediately
There is no queue and no waiting list. The app is listed as soon as you confirm, and because this page is ordered newest-first, it appears at the top. The screenshot is captured in the background straight afterwards.
Writing a card that earns a click
The title and blurb are the only words you control, and both are optional — but a card with neither shows a raw project name and no description, which is a poor advertisement for good work. The title replaces the project name on the card, so use the name you would actually give the thing in public. The blurb is short by design: say what the app does and who it is for, and leave the adjectives out. The screenshot handles the look.
It is also worth deploying the version you want photographed. The screenshot is taken from the live page shortly after you publish, and re-taken on later deploys while the app stays listed, so the card tracks the app rather than freezing at launch day. A capture that fails, or a page that errors, leaves the previous image in place rather than replacing it with a broken one.
If you have not shipped anything yet, start from a design in the template library or describe what you want from scratch — pricing covers what is included at each tier, and the docs walk through the build-to-live path end to end.
Delisting
How to take your app off the showcase
One button, immediate, and completely separate from whether your app stays online.
Unpublish
Go back to the Public showcase row on the project’s deploy page. A project that is currently listed shows an Unpublish button in place of the publish flow, and pressing it is all it takes. The gallery only ever asks for published projects, so an unpublished one is simply not part of the answer any more.
Your app is untouched
- The deployment keeps running
- The live URL keeps working
- The project itself is unchanged
- You can publish it again later
Delisting is not deletion, and it is not a takedown. Unpublishing removes the card from this page; it does nothing to the app behind it, which stays deployed at the same URL for anyone who already has the link. If your goal is to make the application itself unreachable, that is a deployment decision on the project, not a showcase one.
Remixes that were already made from your app are their own projects and are not affected either — they were never copies of it, and they were never dependent on it staying listed. The recorded lineage on those projects remains as it was.
Ownership
Who owns an app that has been published here
Listing your work in a gallery is not a transfer of anything. Here is the short version, and where to read the long one.
You own what you build. The terms of service state that you own the code and content you create with the service, that no ownership is claimed over your projects, and that the licence you grant is a limited one — to host, process, transmit and display your content so the service can actually run. Displaying a card on this page is squarely inside that; it is not a separate grant, and it does not add one.
There is no showcase licence layered on top. Publishing does not place your app under an open-source licence, does not make your repository public, and does not give other users rights to your code — the mechanism makes that concrete, because a remix never receives code in the first place. What another person can take from your listing is what the card shows plus the four seed inputs a remix carries: the template, the design, the palette and the brief.
So the honest question before publishing is not “who gets my code” — nobody does — but “am I comfortable with the idea travelling”. A brief is a description of what you set out to build. If that framing is the valuable part, weigh that. If you want specific terms to apply to your application, state them in the app or in its repository, where they belong; nothing on this page speaks for you. And read the terms yourself rather than taking a marketing page’s summary of them — that document governs, this one does not.
How the list works
How this page is ordered, and why it is sometimes empty
No editors, no votes, no leaderboard. Just the most recently published apps, and an honest empty state when there are none.
Newest published first
The only ordering rule. An app moves to the top when it is published and drifts down as others follow. Nothing re-ranks it for popularity, remix count or quality.
A capped page, not an archive
The gallery loads a fixed number of recent apps rather than everything ever published. This is a window onto what is current, not a complete historical index of the platform.
Nothing is “featured”
There is no editorial pick, no staff selection and no promoted slot. If a card is near the top, it is recent — that is the whole story. Position here cannot be bought or applied for.
If the gallery above is empty
Nothing is broken. The list only ever contains apps that are published right now, and publishing is opt-in and reversible — an owner can list an app on Monday and delist it on Tuesday. An empty gallery means exactly one thing: nothing is currently listed. The empty card says as much, and it is an invitation rather than an error.
It also means the fastest way to change it is to be the one who ships something. Build a project, Go Live, and publish it — the steps are above and the whole path takes one session, not one sprint.
In the meantime, there is plenty to look at that does not depend on what other people have published. The template library has the complete set of design systems a build can start from, with full-page previews of each. The platform overview shows the pipeline from prompt to live URL, and capabilities lists what a generated app can actually do. The documentation covers both the build-from-scratch and the connect-an-existing-repository paths, pricing sets out what each tier includes, and the community page is where to find other people building — and where showcasing your work is half the point.
FAQ
Questions about publishing and remixing
The things worth knowing before you list an app here, or start a project from someone else’s.
Your app could be the next one here.
Describe it in a sentence, go live to a real URL, then publish it to the showcase from its project page.