This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
My friend Riya runs Newvora, a small student-run startup. She builds websites and back-office portals for local businesses, mostly with AI coding tools. Three clients pay her every month, and some have extended their plans through next year. Her two teammates handle client meetings, outreach, and social media.
Her problem is that everything lives in her head. Clients send requests on WhatsApp, and she remembers who asked for what, who has paid, and which tool renews when. She told me she can't hand work over cleanly, and that most of her income goes into tool subscriptions. Studying around all of this isn't easy either.
So I built Newvora HQ, a shared workspace for her whole team:
- AI Inbox: paste a client's WhatsApp message (English or Hinglish), and Gemma turns it into one task per request, with type, priority, and a clarifying question when the message is vague. [It can also read a pasted chat screenshot.]
- Board: To do, Doing, and Done, with assignees, comments, and an activity log of who changed what.
- Clients and Dues: monthly fees, the one-time setup fee balance, a payment ledger per month, and a "month end is near, collect from these clients" reminder.
- Tools: each subscription's budget, usage so far, what's left per day, and a warning before it renews or runs out.
- Notifications: assignments, comments, renewals, and overdue payments, per team member.
- Report: a monthly summary she can copy or print instead of collecting numbers from many places.
- Light and dark themes.
What Riya Said
I showed her the first version and asked for honest feedback. She found no issues with it, but she told me what she would actually use: money and tool tracking. Her words, translated from Hinglish:
"If I could track my tools, get warnings about payment dues, and track which clients have paid their monthly fee and how much of the establishment (setup) fee each has paid, and if clients could tell me about their feature additions systematically in the app, so that when I assign it to someone they get notified..."
"Also check whether I can connect different tools to the app through APIs, so I can get all the reports in one place."
"It will be very important, and new, and tough, but every developer or business person is stuck tracking around 100 different tools."
That feedback is why I added Dues, Tools, Notifications, and the monthly report. Connecting live tool accounts is on the roadmap below.
Demo
-
Live app: https://newvora-hq.onrender.com
- Passcode for judges:
newvora2026 - It runs on Render's free plan, so the first load can take about a minute, and the data resets when the service restarts. Everything in it is sample data.
- Passcode for judges:
- Video walkthrough:
Code
Newvora HQ
Internal operations workspace for Newvora, a student-run agency building client websites and portals. Tracks client requests from WhatsApp, tasks, team activities, and agency finances.
Built with FastAPI (Python), SQLite, and vanilla HTML/CSS/JavaScript (no frontend build step, no frameworks, no CDNs). All AI features are powered by Google's open-weight Gemma model via the Gemini API (or local Ollama).
Quickstart
1. Prerequisites
- Python 3.10+
- (Optional for Stage 2) Google Gemini API Key with access to Gemma models.
2. Setup
Create a virtual environment and install dependencies:
# Windows
python -m venv venv
venv\Scripts\activate
# Install dependencies
pip install -r requirements.txt
3. Environment Variables
Copy .env.example to .env:
cp .env.example .env
Configuration options in .env:
-
GOOGLE_API_KEY: Google AI Studio API key for Gemma. -
AI_PROVIDER:gemini. -
AI_MODEL:gemma-4-26b-a4b-it(default). -
PORT: Server port (default8000). -
DB_PATH: SQLite database file…
How I Built It
Stack: Python with FastAPI, SQLite, and a plain HTML, CSS, and JavaScript frontend (no framework). AI features call Gemma (gemma-4-26b-a4b-it) through the Gemini API. It's deployed on Render, and I built it mostly with Antigravity.
The AI Inbox is the core. It sends a message to Gemma with a strict prompt and expects JSON back. It then strips code fences, validates the allowed values, and retries up to twice if parsing fails. A sample message I wrote:
"bhaiya, stock wala table me last month ka data update kardo, and dashboard thoda slow hai"
This should become two tasks: a data update and a bug. The model got that right, and each task came with a sensible clarifying question.
I started local, and it failed. My laptop has 8 GB of RAM and no GPU, so I began with gemma3:1b in Ollama:
| Test | What the 1B model did |
|---|---|
| Two requests in one message | Dropped the request type and invented a client_feedback field |
| "Add a download button" | Labeled it a data update instead of a new feature |
| Vague message | Invented a type, though the clarifying question was good |
It also wrapped answers in code fences and added chatty notes. I couldn't run a bigger local model, so I moved to Gemma through an API. The same two messages then came out correct.
Two lessons I took from this:
- Small models need a strict output format, and the app has to check what comes back.
- A single WhatsApp message often holds several requests, so the model returns a list of tasks, not one.
I also added a rule that only messages with "urgent," "asap," or a deadline get high priority, after the model marked "the dashboard is a little slow" as high.
All AI calls go through one small function, and the model name is a config setting.
Why Does Open Innovation Matter?
I'll be honest about what I can and can't claim. In this demo, messages go to Google's API, so I'm not saying client data stays on a laptop. Here is what open weights actually gave me:
- I could test for free before committing. Running small Gemma models locally showed me what size the task needs, and it cost nothing.
- No lock-in. Because Gemma's weights are open, the model isn't tied to one provider.
- Privacy has a path forward. Her clients' stock figures and business numbers are sensitive. With an open model she can eventually host the same model herself, so that data never goes to a third party.
- Cost. She spends most of her income on tool subscriptions, so a free-tier API plus an open model that can later run on her own server matters a lot to her.
What's Next
These are Riya's own requests, and I checked what's actually possible:
- Live usage from other tools. Anthropic's Usage and Cost API needs an organization admin key (not available for individual accounts), Convex exposes usage through log streams, and Supabase's usage data is in its dashboard. Each tool needs its own connector, and powerful keys shouldn't live in a demo app. For now, usage is entered manually or read from a pasted receipt.
- Real alerts by email or Telegram, and scheduled reminders.
- Permanent storage. The repo includes a paid Render config with a persistent disk for her own account.
- Client request form: a place where clients submit requests themselves, so they land in the Inbox already structured.
Prize Categories
-
Best Use of Gemma: Gemma (
gemma-4-26b-a4b-it) does the request parsing and report summaries, served through the Gemini API. - Best Use of Render: the full app (backend and frontend) is deployed as a Render web service.
Top comments (0)