Day 10 of 10
Deploy your app. Push to GitHub. Write the README. Share the link. Today you become someone who ships.
Ten days ago you had a blank file and a question mark.
Today you have a working AI application: document intelligence, web research, a live UI, an agent that reasons and acts. You built every piece yourself. You understand every line.
Now you make it real. A project is not finished until someone else can use it. That is what today is for.
Run through this before touching deployment:
# Does it run clean from scratch?
# In your project directory:
uv sync
# Make sure .env exists with your key
cat .env # should show: GROQ_API_KEY=sk-...
# Run the app
uv run --env-file .env marimo run app.py
If it breaks, fix it now. Deploy a working thing, not a “mostly working” thing.
Check that your API key is loaded from an environment variable, not pasted into the code. One accidental commit with a hardcoded key and you will be rotating keys at midnight.
Hugging Face Spaces gives you a permanent public URL for free. It runs Docker containers, which means all your packages work — sentence-transformers, strands, everything.
Step 1: Push to GitHub
Create a .gitignore first so your API key never gets committed:
echo ".env" > .gitignore
echo "__pycache__/" >> .gitignore
echo "*.pyc" >> .gitignore
Generate the lock file so Hugging Face can reproduce your exact environment:
uv lock
Now commit everything — the lock file and pyproject.toml must be in git or the Docker build will fail:
git init
git add app.py app_backend.py pyproject.toml uv.lock .gitignore
git commit -m "Initial commit: AI assistant with document and research modes"
Push to a public GitHub repository.
Step 2: Add a Dockerfile
Create Dockerfile in your project directory:
FROM python:3.11-slim
RUN pip install uv
WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN uv sync --no-dev
COPY app.py app_backend.py ./
EXPOSE 7860
CMD ["uv", "run", "marimo", "run", "app.py", "--host", "0.0.0.0", "--port", "7860"]
Commit it:
git add Dockerfile
git commit -m "Add Dockerfile for Hugging Face Spaces"
Step 3: Create a Space
Go to huggingface.co and create a free account. Click your profile, then New Space. Give it a name. Under SDK, select Docker. Set visibility to Public.
Hugging Face will give you a git repository URL for the Space. Before pushing, add the required Space configuration to the top of your README.md — without it the build will fail with a configuration error:
---
title: Your App Name
emoji: 🔍
colorFrom: blue
colorTo: indigo
sdk: docker
pinned: false
---
The --- lines must be at column zero with no leading spaces.
Commit it, then push:
git add README.md
git commit -m "Add Hugging Face Space config"
git remote add space https://huggingface.co/spaces/YOUR_USERNAME/YOUR_SPACE_NAME
git push space main
If the push is rejected with “not authorized”, your remote URL needs your credentials embedded. Get a token with Write access from huggingface.co/settings/tokens, then update the remote:
git remote set-url space https://YOUR_USERNAME:YOUR_HF_TOKEN@huggingface.co/spaces/YOUR_USERNAME/YOUR_SPACE_NAME
git push space main
If the push is rejected because the Space was initialized with default files, force push:
git push space main --force
Step 4: Add your API key
In your Space settings, go to Variables and Secrets. Add GROQ_API_KEY as a secret. The app reads it from os.environ.get("GROQ_API_KEY") — same as your local .env.
Your app is now live at https://huggingface.co/spaces/YOUR_USERNAME/YOUR_SPACE_NAME.
If the build fails, check the Logs tab in your Space. Most failures are missing packages in the Dockerfile.
One paragraph. Not a novel. The person reading your README has 30 seconds.
# [Your App Name]
[One sentence: what it does.]
[One sentence: why you built it.]
## Run it locally
uv sync
cp .env.example .env # then add your GROQ_API_KEY
uv run --env-file .env marimo run app.py
That is it. What it does, why it exists, how to run it. Three things. Done.
If you want to add screenshots, add one. Not a gallery. One image showing the app in use.
Before you share anything, write this:
“I built [X] because [Y], and it lets you [Z].”
Not a features list. Not a technology stack. The thing, the reason, and what someone can do with it.
If you cannot write this sentence, the project is not clear enough yet. Simplify it until you can.
Example: “I built a research assistant because I spend too much time on background reading before meetings, and it lets you ask a question and get a sourced, structured answer in 30 seconds.”
That sentence is your pitch, your LinkedIn post, your DM to a senior engineer you want to impress. Write it first.
Post the link somewhere public. LinkedIn. Twitter. A group chat. A forum you read. Anywhere that puts it in front of another human being.
You do not need to wait until it is perfect. It will never be perfect. Ship it while it still scares you a little. That fear means you care about the outcome.
When someone uses your app and tells you what they think, that feedback is worth more than another week of polishing in private.
Ten days. Zero Python to a live agentic application.
You did not just learn about AI. You built with it. You understand what an LLM is because you watched one hallucinate. You understand prompt engineering because you saw the same chatbot become three different products. You understand RAG because you built retrieval by hand. You understand agents because you watched your code decide what to do next.
That stack of understanding does not live in notes. It lives in the files you wrote.
The next project will be harder. It will expose gaps. Fill them. Build the next thing. Every tool you want your agent to have will require you to learn something: a new API, a library, a concept. That is not an obstacle before building. That is the learning being the building.
The people who get good fast are the ones who ship before they feel ready, learn from what breaks, and go again.
You are already one of those people. You just proved it.