Build a Hugging Face demo app with no code, without Gradio or Spaces

Why every other guide points at Spaces

Hugging Face Spaces is the obvious answer to this question if you read the docs cold. Spaces is HF's hosted runtime for Gradio and Streamlit apps. You write Python, push to a repo, the platform builds a container and serves the app. For people coming from a notebook the path is short. For people who only know they want a working web demo, it forces a detour through Gradio's idioms, Spaces' build pipeline, and HF's URL space.

That detour is real but small if you already write Python. It is large if you do not, and it is unnecessary if the demo is just a fetch call against an HTTP endpoint. The Inference Providers REST endpoint takes a JSON body or a binary audio blob and returns JSON. Anything that speaks fetch can talk to it. A React component is enough. Once you accept that, the question stops being "how do I learn Gradio fast enough to ship a demo this weekend" and becomes "who writes the React for me."

The friction stack you skip

Here is what does not appear in the loop when the demo is a React fetch instead of a Gradio Space. Each item is a thing the Spaces path asks for and the no-code-React path does not.

That list is the whole point. The dollar value of skipping any one item is small. The compounding value of skipping all of them is what turns "weekend project" into "twenty minute conversation."

Why the sandbox is already warm

The interesting part is not the prompt. The interesting part is what is already running before the prompt arrives. The mk0r sandbox is built from a single Dockerfile committed to the appmaker repo. Lines 26 to 57 of docker/e2b/e2b.Dockerfileinstall everything the agent might need to wire a model demo together. The image is baked once and every session boots from the same snapshot. That is why "install python3" never appears in any plan the agent writes.

When you ask for a Hugging Face demo, the agent already has curl, npm install, pip install, a running Vite dev server, and a working browser to verify the result in. None of those are conditional. None of them block the first turn. If you wanted a Python sidecar (a lightweight transformers wrapper, say), pip is one apt-installed binary away.

The two artifacts, side by side

Concretely, here is what a Whisper demo looks like in each world. Left is the Spaces + Gradio path: an app.py, a requirements.txt, and a Spaces-flavored README. Right is the React + Inference Providers path: one component, one fetch call, one rendered transcript. Read both. The Gradio version pulls weights into the Space and runs them on Space hardware (or queues for ZeroGPU). The React version delegates inference to the HF Inference Providers fleet and the demo runs anywhere the static bundle is served.

# Hugging Face Spaces: app.py
import gradio as gr
from transformers import pipeline

# Load model on Space hardware
asr = pipeline(
    "automatic-speech-recognition",
    model="openai/whisper-large-v3",
)

def transcribe(audio):
    if audio is None:
        return ""
    return asr(audio, return_timestamps=False)["text"]

demo = gr.Interface(
    fn=transcribe,
    inputs=gr.Audio(type="filepath", label="Upload audio"),
    outputs=gr.Textbox(label="Transcript"),
    title="Whisper demo",
    description="Drop an audio file.",
    allow_flagging="never",
)

if __name__ == "__main__":
    demo.launch()

# Plus: requirements.txt
#   transformers
#   torch
#   gradio
# Plus: README.md frontmatter (Spaces config)
#   ---
#   title: Whisper demo
#   sdk: gradio
#   sdk_version: 4.44.0
#   app_file: app.py
#   pinned: false
#   ---

The shape of your weekend

Here is the same Saturday on both paths. The toggle below is the honest version. Gradio is a fine tool and the Spaces team has done careful work to keep the build pipeline short. The point is not that one is bad, it is that they end up at different artifacts and one of them is a Python container and the other is a Vite app you can keep iterating on for months.

When this is the wrong path

A page on this topic that does not name its limits is selling something. Three honest cases where Spaces still wins.

• You want HF community discoverability. A Space is indexed inside the Hugging Face ecosystem. People browse Spaces by model and tag. A Vite app on a personal domain is invisible to that audience. If "more HF users find this" is the goal, ship a Space.
• You need free GPU. Spaces offers a ZeroGPU tier that is queue-based but free. mk0r's sandbox is 1 vCPU, no GPU, and it does not host model weights. If your demo runs a 7B param model that you cannot afford to call via Inference Providers, a Space with ZeroGPU is the right call.
• The demo IS the notebook. If you already have a polished Jupyter notebook and the artifact you are sharing is essentially that notebook, Gradio wraps it in three lines. Asking an AI agent to translate a notebook into a React app is more work than gr.Interface(your_function).launch().

What the agent does not do for you

For the same reason: rate limiting on the Inference Providers side is real and the agent will not magic it away. If your demo gets posted to a community and a thousand strangers click it in an hour, the read token gets throttled and the React app needs a fallback. The agent will write the fallback if you ask it to (a queue, a graceful error, a cached last-good response), but it does not auto-add it on turn one. A demo built as a fetch UI is closer to a real product than a Spaces page is, which means it inherits real product concerns earlier.

The other category the agent will not solve: model-side cold starts. If you call a model that the chosen provider has not warmed recently, the first response is slow. That is a property of the provider, not the React UI. Spaces hides this behind its own "starting up" loader. mk0r exposes it as a slow fetch, which is honest and slightly worse UX out of the box. Worth knowing.