| # Field Notes: PitchFight AI |
|
|
| Build log for the Hugging Face **Build Small Hackathon** (Backyard AI track). |
| PitchFight AI is a practice arena for student founders — not a replacement for real mentors, investors, or hackathon judges. |
|
|
| --- |
|
|
| ## What we built |
|
|
| PitchFight AI is an AI founder pressure arena where student builders: |
|
|
| 1. Enter a startup idea (quick pitch, advanced form, or voice pitch) |
| 2. Get an AI-structured founder briefing |
| 3. Choose a judge persona and difficulty mode |
| 4. Survive multi-round pitch Q&A in a battle-style UI |
| 5. Enter an optional deal-style pressure round |
| 6. Receive a scorecard with coaching and a retry path for the weakest answer |
|
|
| **Stack:** Hugging Face Spaces · Gradio Server (`app.py`) · custom HTML/CSS/JS frontend · NVIDIA Nemotron API (backend-only) · `ffmpeg` for audio · optional MongoDB persistence. |
|
|
| The browser talks only to `/api/*`. Model calls never run in the frontend. |
|
|
| --- |
|
|
| ## Why this exists |
|
|
| Most student founders rehearse slides alone or with friends who are too nice. The first hard questions usually come from a real panel — and that is when answers fall apart. |
|
|
| We wanted a low-friction place to practice **under pressure** before that moment. The goal is coaching and repetition, not pretending an AI judge is a substitute for human feedback. |
|
|
| --- |
|
|
| ## Product decisions |
|
|
| - **Arena, not chatbot.** Flow is staged: landing → briefing → battle → deal → scorecard. It should feel like stepping into a fight, not opening a generic assistant. |
| - **Structured briefing first.** Raw ideas get structured before the judge attacks, so users practice defending a clear narrative. |
| - **Personas + difficulty.** Skeptical VC, technical judge, and hackathon judge modes change tone and pressure without swapping the whole product. |
| - **Scorecard over vibes.** Output is actionable: what landed, what was weak, what to rewrite — not just “good job.” |
| - **Voice as an entry path, not the whole app.** Voice pitch and voice answers are supported where enabled, but text mode stays fully usable. |
|
|
| --- |
|
|
| ## AI judge design |
|
|
| Judges are prompt-driven personas routed through a single backend model layer. Design choices: |
|
|
| - **Follow-up questions, not monologues.** Each round pushes on claims, gaps, and vague traction. |
| - **Persona-specific pressure.** VC mode leans market and defensibility; technical mode probes AI necessity and feasibility; hackathon mode focuses on demo clarity and MVP. |
| - **Attack tags / rubric hooks** (in config) keep scoring and feedback aligned with what was actually said, not generic startup advice. |
| - **Retry weakest answer.** After the scorecard, users can rework one weak response — closer to coaching than a one-shot grade. |
|
|
| This is simulated judgment for practice. Real panels bring context, chemistry, and standards no API can fully replicate. |
|
|
| --- |
|
|
| ## NVIDIA Nemotron usage |
|
|
| - **API:** `https://integrate.api.nvidia.com/v1` |
| - **Primary model:** `nvidia/nemotron-3-nano-omni-30b-a3b-reasoning` |
| - **Key handling:** `NVIDIA_API_KEY` lives in `.env` locally and in **HF Space Secrets** in deployment — never in the frontend or git. |
| - **Routing:** `core/model_router.py` → `core/nvidia_client.py` for judge questions, structuring, scoring, rewrites, and voice-related paths where enabled. |
|
|
| **Practical note:** This is a reasoning model. It can spend tokens on internal reasoning before the visible reply. We tuned `max_tokens` per task so the user-facing answer stays in character and concise. |
|
|
| We use Nemotron as the main inference backend for the demo build. We are **not** claiming fine-tuning or custom model training. |
|
|
| --- |
|
|
| ## Custom UI / Off Brand decisions |
|
|
| We deliberately avoided default Gradio widgets for the product surface. |
|
|
| - **Custom frontend** (`frontend/`) — cinematic landing, briefing layout, battle stage, deal screen, scorecard. |
| - **Game-like presentation** — spotlights, arena framing, persona cards, pressure-meter styling. Pitch practice should feel memorable in a demo, not like a form filler. |
| - **Gradio as host, not as UI.** `app.py` serves the static frontend and REST API; Gradio is the deployment shell on Spaces. |
|
|
| This aligns with an **Off-Brand** spirit (custom experience on HF infrastructure) without claiming we built a different framework. |
|
|
| --- |
|
|
| ## Hugging Face deployment notes |
|
|
| - **Space type:** Gradio Space, `app_file: app.py`, custom `/` homepage serving `frontend/index.html`. |
| - **Secrets:** `NVIDIA_API_KEY` required; optional flags for voice, deal battle, deck critique, MongoDB. |
| - **System deps:** `packages.txt` includes `ffmpeg` for audio pipelines. |
| - **Layout tuning:** Landing and briefing screens were adjusted for the Spaces desktop viewport — including the white HF navbar above the app iframe. We use `100svh` / `100dvh` with safe padding and a small JS viewport sync so the hero fills the **visible app area** without a dead band at the bottom or content hidden under chrome. |
|
|
| Local dev at `127.0.0.1:7860` does not show the HF navbar; we tested both locally and in the live Space while iterating on layout. |
|
|
| --- |
|
|
| ## What worked well |
|
|
| - **Backend-only inference** kept secrets out of the browser and simplified deployment. |
| - **Custom UI + `/api/*` contract** made it easy to iterate on flow without fighting Gradio components. |
| - **Phased product shape** (brief → battle → deal → scorecard) reads clearly in a short demo. |
| - **Persona and difficulty toggles** give variety without multiplying model integrations. |
| - **Honest coaching tone** in prompts and scorecard copy — useful feedback without overclaiming “investor approval.” |
|
|
| --- |
|
|
| ## Tradeoffs and limitations |
|
|
| - **Coaching tool, not truth.** AI judges can be sharp but wrong, repetitive, or too harsh. Users still need humans for real validation. |
| - **Reasoning model latency and token budget.** Longer waits and token tuning are part of the tradeoff for quality follow-ups. |
| - **Voice depends on environment.** `ffmpeg`, browser permissions, and API availability affect voice mode reliability on Spaces. |
| - **MongoDB persistence** is optional — not every deployment enables it. |
| - **No production-scale eval suite.** We did not run formal benchmarks or user studies for this hackathon build; quality is judged by manual demo runs and iterative prompt tuning. |
| - **Layout is viewport-sensitive.** Short or embedded viewports may still need scroll on dense screens (e.g. advanced briefing); landing is tuned for HF desktop first. |
|
|
| --- |
|
|
| ## Submission evidence |
|
|
| | Item | Link | |
| |------|------| |
| | **Live Space** | `[Add your HF Space URL]` | |
| | **Demo video** | `[Add demo video URL]` | |
| | **Hugging Face blog / write-up** | `[Add blog or post URL]` | |
|
|
| **Repo highlights for judges:** `app.py` (API + frontend host) · `core/api_handlers.py` · `core/model_router.py` · `frontend/` (custom UI) |
|
|
| --- |
|
|
| ### Not claiming |
|
|
| - Not claiming **OpenBMB / MiniCPM** |
| - Not claiming **Modal** |
| - Not claiming **Tiny Titan** |
| - Not claiming **Off the Grid** |
| - Not claiming **fine-tuning** |
|
|
