A private class copilot for solo yoga teachers, powered by Gemma on their own laptop
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle What I Built Saathi is a desktop app for solo yoga teachers. It runs Gemma locally through Ollama and does the three jobs that eat a teacher's evenings. Class prep. Pick tonight's class and who is attending. Saa

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 馃捀
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle
Saathi is a desktop app for solo yoga teachers. It runs Gemma locally through Ollama and does the three jobs that eat a teacher's evenings.
I built this for a yoga teacher I build software for. She teaches six 45-minute classes a week over Google Meet, alone. I built her booking site, so I know what it stores: every student's age range, experience, goals, injuries and surgeries.
That last part is the whole reason this is local. Those health notes are the most useful input for planning a safe class, and also the last thing she should paste into a hosted chatbot. Every solo teacher, physio, personal trainer and tutor who keeps client notes has the same problem. A flat monthly price from them is easy to justify when the alternative is an evening of planning and follow-up emails after each teaching day.
Code: https://github.com/harsh8398/saathi-yoga-copilot
Privacy that is structural, not promised. The student's injuries never leave the machine. There is no server to breach, no vendor privacy policy to read, and no data-processing agreement for a one-person studio to sign. For health information in Canada, that is a much easier conversation than "we send it to an API, but we promise".
Cost that fits a $10 class. Her first class is $10 CAD. A per-token bill that scales with every plan and every email makes this a poor business for someone teaching six classes a week. Local inference costs her electricity. Two full plans took my battery from 94% to 92%.
A model she can change. The model is a setting. I started on the default gemma4:e4b build, which was 9.5 GB and too heavy for a 16 GB laptop, moved to the 6 GB e4b-it-qat build, and nothing else in the app changed. If a better or smaller open model lands next month, she swaps it in. If she wants it to sound more like her, the voice lives in a prompt she can edit, and later a fine-tune on her own newsletters is possible without asking anyone's permission.
I want to be straight about this because it is the real tradeoff.
On my M1 Pro with 16 GB, Gemma generated at about 2 to 4 tokens per second. Without streaming, a full plan took around six minutes of staring at a spinner. With streaming, the first callouts show up after roughly a minute and the plan fills in as it is written, but the last plan I timed, for three students, still took 9 minutes 11 seconds. A hosted API would answer in seconds.
That is the honest price of keeping the data home. For a teacher who plans a class once, it is tolerable. It is not something I would call fast, and a smaller model or a faster machine would change it.
The output has rough edges too, and I would not hide them from a customer:
Best Use of Gemma. Gemma does all the reasoning: structured class plans, per-student modifications grounded in the student's own notes, and warm follow-ups in the teacher's voice, constrained by a JSON schema, entirely on-device.
I found Building Local-First AI Apps: What Changes When the Data Stays on the Device by sanskarcodes useful while thinking through what changes when nothing leaves the machine.