DEV Community: Shaikh Ubaid Ahmed

TempoDesk: I turned lesson scribbles into private practice plans with local Gemma

Shaikh Ubaid Ahmed — Sun, 18 Oct 2026 16:12:27 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

A music lesson rarely ends when the student leaves.

Independent teachers still have to turn hurried notes such as "left hand tense in bars 9 to 12, count aloud, C major fingering slipped down" into something a student can actually practise. Then they often write a second version for a parent and decide what to check next week. Multiply that by a full afternoon of students and the unpaid admin adds up quickly.

I built TempoDesk, a local-first planning assistant for independent music teachers. A teacher pastes rough lesson notes, chooses the student's instrument and available practice time, and TempoDesk produces:

a realistic, time-boxed practice plan;
wins worth reinforcing and focus areas for the week;
a student-friendly recap;
a concise parent update;
measurable checkpoints for the next lesson; and
explicit questions wherever the notes do not contain enough information.

Lesson notes can contain details about children, their progress, and their schedules. TempoDesk sends them only to an Ollama server on the teacher's own computer. The settings screen rejects non-localhost model URLs, and the browser never stores lesson notes.

Who would pay for it? The target user is a solo music teacher with 15 to 40 students who loses an hour or two each week to follow-up messages and practice-plan admin. My proposed product is a ₹799 (about $10) packaged edition with a one-click installer and setup help. The open-source web version remains free. Teachers would pay once for easier setup and support, with no subscription.

Demo

Open the live TempoDesk demo

The hosted demo includes a Preview sample plan button, so it can be explored without installing a model. The sample is labeled clearly and does not pretend to be a live AI response.

Run it locally:

ollama pull gemma3:4b
npm start

Then open http://localhost:4173 and select Use example. If Ollama is not available, Preview sample plan shows the complete product flow without pretending that the sample came from a live model.

For a screenshot-ready demo state, open http://localhost:4173/?demo=1.

Code

shaikhubaidahmed / tempodesk

Private, local-first practice-plan assistant for independent music teachers, powered by Gemma through Ollama.

TempoDesk

TempoDesk is a local-first lesson-planning assistant for independent music teachers. Paste rough lesson notes and a local Gemma model turns them into a realistic weekly practice plan, a student recap, a parent update, and concrete next-lesson checkpoints.

Live demo: https://shaikhubaidahmed.github.io/tempodesk/

No student notes are sent to a hosted AI service. The browser talks directly to Ollama on localhost.

Why this exists

Independent music teachers often finish a day with shorthand notes and several follow-up messages still to write. Generic AI tools can help, but uploading notes about students—often minors—to a third-party service is a poor default. TempoDesk keeps that workflow on the teacher's own computer and turns the output into something immediately useful.

Features

Local Gemma inference through Ollama; no account or API key
Evidence-grounded prompt that records missing information instead of inventing it
Exactly time-boxed practice days with observable goals
Ready-to-send student and parent messages
Keyboard-accessible tabs…

View on GitHub

Browse the source code on GitHub

The project is MIT licensed, dependency-free at runtime, and includes focused tests for input validation, prompt construction, Ollama response parsing, output normalization, and copyable plan formatting.

I also tested the complete local model path with gemma3:4b: Ollama returned schema-valid JSON with the requested number of practice days and exact per-day minute totals.

How I Built It

TempoDesk is a small static web app built with semantic HTML, CSS, and JavaScript. It talks directly to Ollama's local /api/chat endpoint and uses Gemma 3 4B as its default open-weight model.

flowchart LR
  A[Teacher's browser] -->|lesson notes| B[Evidence-grounded prompt]
  B -->|localhost only| C[Ollama]
  C --> D[Gemma 3 4B]
  D -->|JSON matching a schema| E[Deterministic validator]
  E --> F[Practice plan + messages + checkpoints]

The model and ordinary code have separate jobs.

Gemma handles the part that benefits from language understanding: reading messy teaching shorthand, finding the learning priorities, adapting the tone for a student or parent, and turning observations into clear practice targets.

JavaScript handles predictable checks. TempoDesk validates the JSON, trims unbounded lists, enforces the requested number of practice days, reconciles every day's block minutes, escapes all rendered content through DOM text nodes, and falls back to safe defaults when a field is missing.

The prompt has a strict evidence rule. When the teacher leaves out a useful fact, the model adds a question to unknowns. In the sample, it asks which tempo is comfortable because the notes contain no metronome number.

The interface was designed around a fast two-step workflow: notes on the left, a sendable plan on the right. It includes visible labels and focus states, keyboard-operable tabs, an error summary that receives focus, 44px-or-larger controls, reduced-motion support, and responsive layouts tested at desktop and 390px mobile widths.

Scope choices

The MVP does not keep a student database, sync notes, send messages automatically, or require an account. Those features would weaken the privacy story and expand the project before the core workflow was proven.

The local-model dependency stays visible. The interface shows the connection status and settings, errors explain how to install the model, and the offline sample is clearly labeled.

Why Does Open Innovation Matter?

Open weights change the economics and the trust model of this product.

A cloud AI version would create a recurring inference bill for every lesson plan. I would either have to charge a subscription, ration usage, or silently send sensitive lesson notes to another company. Local Gemma makes the marginal inference cost effectively zero after the teacher owns the laptop and downloads the model. That makes a low-cost one-time license believable for a solo teacher.

It also gives the teacher control. They can work without an internet connection, choose a smaller Gemma model for an older laptop, inspect the prompt, change the behavior, or replace the model entirely. Their notes do not become someone else's data-retention decision, and the product does not break because an API price or policy changes.

Gemma performs the central transformation. Without its ability to interpret unstructured lesson observations and produce audience-specific language, TempoDesk would be a rigid form template.

Prize Categories

Best Use of Gemma: Gemma 3 runs locally through Ollama and performs the lesson-notes-to-practice-plan transformation.

What I Learned

The unknowns field was more effective than adding another instruction to "be accurate." It gives missing information somewhere to go, so the model can ask for a tempo, fingering edition, or deadline when the notes do not supply one.

Local-first UX needs to treat model setup as part of the product. A private architecture still needs a visible connection state, an actionable missing-model error, a smaller-model option, and a demo path that works before a multi-gigabyte download finishes.

TempoDesk covers one lesson at a time and produces one useful week. Keeping that boundary made the workflow specific enough for a teacher to use.

AccessPath-ai: I built my sibling a subway planner that won't strand him when a lift breaks

Shaikh Ubaid Ahmed — Mon, 05 Oct 2026 03:28:38 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

My sibling relies on step-free transit. A route planner can call a trip accessible and still send them through a transfer that becomes unusable when one lift fails. The usual route card does not say which equipment the journey depends on, when it was last checked, or where to go if it stops working.

I built AccessPath for that situation. It plans step-free NYC Subway journeys, checks the equipment and outage evidence behind each route, and prepares another valid route when the first one breaks. The rider's requirements stay fixed even when the network changes.

The demo starts at Grand Central-42 St and ends at Astoria Blvd. Plan A changes from the 7 to the N at Queensboro Plaza. I inject a clearly labelled failure of the transfer lift, which invalidates that plan and runs the graph search again. Plan B keeps the step-free requirement and transfers at Times Sq-42 St.

Both routes stay on screen so the change is easy to inspect. The result also includes current warnings, model confidence, source timestamps, and an evidence ledger. A simulated outage is always labelled as a simulation, never as a live MTA fact.

Demo

Live app: https://accesspath-ai.onrender.com
Video-demo: https://youtu.be/bitCWvo5Fdk

For the stable judging path:

Leave Grand Central-42 St and Astoria Blvd selected.
Keep Step-free and Short transfers checked.
Choose Outage demo.
Press Build my access plan.
Compare the interrupted Queensboro Plaza route with the Times Square reroute.
Open Evidence and review the sources, timestamps, and confidence labels.
Play the spoken journey briefing.

Code

shaikhubaidahmed / accesspath-ai

Evidence-first accessible journey planner for transit riders.

AccessPath

AccessPath is an evidence-first journey planner for riders who depend on step-free transit. It checks the infrastructure a route needs, shows the source behind each access claim, and calculates a backup when a lift failure invalidates the original trip.

The working demonstration plans a trip from Grand Central-42 St to Astoria Blvd. Its original route changes at Queensboro Plaza. A clearly labelled simulated transfer-lift outage blocks that interchange, so the planner finds a second route through Times Sq-42 St without relaxing the rider's step-free requirement.

Why this project exists

Most route planners treat accessibility as a filter attached to a station. A wheelchair user needs a stronger answer. The station entrance, platform, direction of travel, transfer path, and the equipment serving them all have to work at the same time.

My sibling relies on step-free transit, but ordinary route planners do not reliably account for inaccessible transfers or elevator…

View on GitHub

The repository contains the app, tests, deployment manifests, and a reproducible public-data pipeline. It also includes the TabPFN benchmark, the Tinker training and evaluation pipeline, and partner activation evidence. A checked-in replay fixture keeps the judging path available when an external service is down.

git clone https://github.com/shaikhubaidahmed/accesspath-ai.git
cd accesspath-ai
npm install
npm run dev

How I Built It

Where models and code separate

I decided early that the model should interpret what a rider says, while official data and deterministic code should decide whether a route is usable.

When configured, Gemma turns a short rider note into typed preferences such as stepFree, avoidLongWalks, and needsAccessibleToilet. It also writes a short briefing after the route has been calculated. Gemma cannot mark a station accessible, clear an outage, or loosen a hard preference to save time.

Official MTA records and the graph search handle those decisions. AccessPath checks every start, arrival, and transfer point. It adds a larger cost to transfers when the rider asks for shorter station changes, and it blocks an interchange when an outage affects a required platform path.

The Mastra workflow

Mastra runs the planning process as five typed steps:

rider note
  -> interpret access needs
  -> resolve MTA evidence
  -> compute constrained route
  -> explain verified result
  -> ground extra official evidence

Each step returns complete or fallback, along with its duration and a plain-language detail. If local Gemma is down, the workflow keeps the rider's explicit checkbox choices and uses local rules. If the live MTA endpoint times out, it switches to the recorded response and reports the fallback in the workflow result.

Building the transit graph

The data script combines the MTA Subway Stations dataset with Regular Subway GTFS. Adjacent stops become travel edges, while connections inside station complexes become walking edges. Equipment and outage feeds provide the current infrastructure state. Monthly availability records provide the reliability history.

The processed graph currently contains 496 stops and the travel and interchange edges used for routing. npm run data:sync rebuilds it from the official endpoints.

There are three evidence modes:

Live asks the current MTA outage feed.
Replay uses a timestamped response for a stable demonstration.
Outage demo adds one local, labelled Queensboro Plaza transfer-lift failure.

Each claim in the evidence ledger has a source type, URL, observation time, freshness note, and confidence level.

Estimating lift risk with TabPFN

The outage feed tells AccessPath what is broken now. TabPFN estimates which lift dependencies deserve more caution based on their history.

The pipeline uses monthly MTA availability and unscheduled-outage records. It creates one-month lags and three-month rolling features, then reserves the latest 20 percent of months for testing. Keeping the split chronological prevents future months from leaking into training.

I compare TabPFN with a histogram gradient-boosting baseline using balanced accuracy, F1, ROC AUC, and runtime. A real TabPFN run writes station-complex forecasts that the TypeScript route engine loads directly.

Model	Balanced accuracy	F1	ROC AUC
Baseline	0.7878	0.8574	0.8908
TabPFN	0.7888	0.8583	0.8946

The script writes a tabpfn artifact only when it has run with a real token. Fallback scores use a different label.

Fine-tuning the preference extractor with Tinker

The Tinker pipeline fine-tunes Qwen3.5-4B for one task: turning a rider's plain-language note into five typed constraints. The dataset covers wheelchair use, fatigue, crowd sensitivity, toilet access, and explicit walking limits. Four examples are kept out of training for evaluation.

The script evaluates the base model, performs 12 supervised LoRA updates, and evaluates the same holdout again. It records exact JSON match, per-field accuracy, loss, and elapsed time.

Base exact match: 0.0%
Fine-tuned exact match: 50.0%
Base field accuracy: 0.0%
Fine-tuned field accuracy: 90.0%
Training loss: 1.2858 (step 00) → 0.0002 (step 11)

The complete 12-step loss sequence was:

1.2858 → 0.1938 → 0.0861 → 0.0591 → 0.0380 → 0.0320
       → 0.0219 → 0.0125 → 0.0042 → 0.0020 → 0.00022 → 0.00019

On the four-example holdout, the base model produced no parseable JSON. The fine-tuned model matched two examples exactly and got 18 of 20 individual fields right.

The authenticated rerun preserved the baseline and fine-tuned sampler checkpoints under Tinker training model 828027e1-aa15-5721-abd1-eee47c49e1fd:train:0. Their complete tinker:// paths, model identity, dependency versions, and holdout outputs are in training/reports/tinker-evaluation.json.

Monitoring a route with Temporal

A route planned now may be wrong by the time the rider leaves. The Temporal workflow checks live evidence on a timer, retries failed planning activities with exponential backoff, compares the new route with the previous one, and records any change. If a worker restarts, Temporal reconstructs the monitor from its event history.

I would use this monitor for the hours before a concert or appointment. It records route changes without requiring a browser tab to stay open.

What the other services do

ElevenLabs speaks the evidence-bound route briefing. Browser speech synthesis remains available when the API is not configured.
Backboard runs the same held-out extraction notes through three open models and records field accuracy, latency, resolved model, and cost.
MongoDB Atlas stores expiring journey-plan documents.
Tiger Data stores source claims as timestamped evidence events for later time-aware retrieval.
SerpApi adds a current result from an official domain when destination evidence is needed.
Sentry wraps the planning workflow in an agent span and captures API failures.
The Render Blueprint deploys the public web application from the Docker image.
The DigitalOcean manifests deploy either the application or the private Ollama and Gemma inference service.

Technical checks

The current repository passes:

4 test files
11 tests
Oxc TypeScript lint
TypeScript client check
TypeScript server check
Vite production build
npm audit: 0 vulnerabilities
production SPA and API smoke test

The tests cover the hard access constraint and the Queensboro Plaza reroute. They also check TabPFN forecast loading with historical fallbacks, evidence labels, all five Mastra steps, malformed API input, health metadata, and Temporal's degraded response.

Focus on open-source infrastructure

A rider may write about wheelchair use, pain, fatigue, or toilet access. AccessPath can process that note with Gemma running through Ollama beside the app, including on a laptop, instead of requiring a closed model provider.

Mastra keeps the orchestration readable and replaceable. The deterministic fallback still enforces hard requirements when no model service is available. If another open-weight model handles the extraction task better, the Backboard benchmark and Tinker evaluation let me measure the difference without rebuilding the product around one vendor.

The same design helps with debugging. I can inspect the profile passed to the route engine, the graph rule that rejected a transfer, the data behind a warning, and the text Gemma received after the route decision. Model output never becomes an accessibility fact on its own.

AccessPath keeps rider notes local where possible. Deterministic code enforces safety constraints, and every factual claim carries a source.

My Agent Session

Pre-submission review of AccessPath, an evidence-first step-free transit planner

You

Review AccessPath before I submit it to the Hacktoberfest Weekend Challenge (Build for a Friend). Check that SUBMISSION.md matches what the repository and the live deployment actually do, and keep secrets out of anything public.

Agent

I'll start with the write-up, then verify each claim against the code, the checks, and the live app.

▸ Read SUBMISSION.md

Input

SUBMISSION.md

Output

Claims to verify:
- Mastra workflow with five typed steps, each returning complete or fallback
- Outage demo: Plan A transfers 7→N at Queensboro Plaza; a labelled transfer-lift failure forces Plan B via Times Sq-42 St
- 496 stops in the processed graph
- TabPFN vs gradient-boosting baseline (ROC AUC 0.8946 vs 0.8908)
- Tinker LoRA fine-tune of Qwen3.5-4B: exact match 0% → 50%, field accuracy 0% → 90% on a 4-example holdout
- 4 test files / 11 tests, lint, typecheck, build, npm audit clean
- Prize categories: Mastra, Render, TabPFN, Tinker (Arduino, Entire, Copilot deliberately excluded)

▸ Bash git log --oneline && git status -sb

Input

$ git log --oneline && git status -sb

Output

12 commits on main, tracking origin/main
5a63ac5 Improve evidence dark mode and simplify page
39b1111 Fix outage demo interaction and clarify workflow trace
c2bbf87 Record verified Render deployment
48a0a4c Configure free Render deployment
0d00d4b Add persistent Tinker training evidence
9a03cb1 Add verified TabPFN and Tinker evaluation evidence
07f05a8 Initial AccessPath project
(list trimmed)

Uncommitted: SUBMISSION.md (copy edit), .gitignore, package.json; untracked webreel.config.json

Agent

Before running anything, a secret scan of every tracked file.

▸ Bash git ls-files | xargs grep -nIE '<API-key, token, connection-string and local-...

Input

$ git ls-files | xargs grep -nIE '<API-key, token, connection-string and local-path patterns>'

Output

No API keys, access tokens, passwords, or database connection strings in tracked files.
.env is gitignored; .env.example contains only empty placeholders.

One account-scoped identifier: a Tinker training-run ID appears in SUBMISSION.md and training/reports/tinker-evaluation.json. It is not a credential, but it is omitted from this transcript.

Agent

Now the technical checks the submission lists.

▸ Bash npm test

Input

$ npm test

Output

 Test Files  4 passed (4)
      Tests  11 passed (11)
   Duration  639ms

▸ Bash npm run lint

Input

$ npm run lint

Output

oxlint src server shared scripts --deny-warnings
(no warnings)

▸ Bash npm run typecheck

Input

$ npm run typecheck

Output

tsc --noEmit && tsc -p tsconfig.server.json --noEmit
(no errors)

▸ Bash npm audit

Input

$ npm audit

Output

found 0 vulnerabilities

Agent

All four pass. Next, the public deployment and the exact judging path from the write-up.

▸ Bash curl https://accesspath-ai.onrender.com/api/health

Input

$ curl https://accesspath-ai.onrender.com/api/health

Output

ok: true, service: accesspath-api
live: TabPFN, Render, Mastra
fallback: Gemma, DigitalOcean, ElevenLabs, SerpApi, MongoDB, Sentry

▸ Bash curl -X POST https://accesspath-ai.onrender.com/api/plan # Grand Central-42 ...

Input

$ curl -X POST https://accesspath-ai.onrender.com/api/plan  # Grand Central-42 St → Astoria Blvd, mode=scenario, stepFree + avoidLongWalks

Output

Original route — unavailable — 53 min
  Grand Central-42 St (7) … Queensboro Plaza ⇄ transfer to N … Astoria Blvd
Recommended reroute — recommended — 60 min
  Grand Central-42 St (7) → Times Sq-42 St ⇄ transfer to N → … Queensboro Plaza (stays on N) … Astoria Blvd

activeOutages[0]: Queensboro Plaza, DEMO-EL-QBP-XFER, "Simulated transfer-lift outage", return to service: "Demonstration only"

trace:
  Understand access needs ............ fallback
  Check lift and outage information .. complete
  Find a route that keeps requirements complete
  Write the journey briefing ......... fallback
  Check extra destination information  fallback

evidence: mta-stations verified, mta-outages verified, mta-history high, scenario verified

Agent

I read the remaining public routes, since anything the server exposes is part of the submission too.

▸ Read server/app.ts

Input

server/app.ts

Output

GET  /api/health, /api/bootstrap, /api/evidence/scenario
POST /api/plan, /api/monitor (503 unless Temporal is configured), /api/voice
GET  /api/debug/recent → returns only requestId, generatedAt, mode (no rider notes)

Agent

Review result: the write-up holds up.

Verified
- The outage demo behaves as described. The reroute still passes through Queensboro Plaza, but stays on the N there. Only the 7→N transfer lift is marked failed, so the step-free requirement is kept rather than relaxed.
- The simulated outage is labelled as a simulation in the outage record, the evidence ledger, and the trace.
- The five-step workflow trace shows each step's status as complete or fallback, as the write-up says.
- Tests, lint, both typechecks, and npm audit pass.
- /api/debug/recent exposes no rider text.

Things to be aware of
- On the public Render deploy, Gemma runs in fallback mode, so the deterministic rules interpret the rider's preferences. The write-up already says "When configured", which is accurate, but a judge who opens the trace will see "fallback" on step 1. A sentence saying the hosted demo uses the rule-based fallback and Gemma runs via Ollama locally or on DigitalOcean would remove the surprise.
- /api/voice forwards any text to ElevenLabs with no rate limit. It is harmless on the current deploy because no ElevenLabs key is set. If one is added, put a limit on it first.
- The local SUBMISSION.md copy edit is not committed or pushed, so the public repo still has the older wording.

You

Prepare a clean session for the submission. Build it from this review only, not from earlier chats.

Agent

Prepared. The session contains only this review. It leaves out:
- credentials, tokens, and account identifiers, including the Tinker training-run ID
- local machine paths and personal contact details
- personal details about the person the project was built for. The transcript describes the users only as riders who depend on step-free transit.
- request IDs from the live API calls

Long tool output is trimmed to the lines that support each claim.

I used an AI coding agent during the challenge window. The work included data-source checks, route-engine debugging, an accessibility review, and a production smoke test. The agent also caught a compiled-path bug after the development build had passed. The embedded session is a curated, secret-free record of the final project review: it re-runs the checks, exercises the outage demo on the live deployment, and scans the repository for secrets.

Prize Categories

I have evidence for these categories:

Best Use of Mastra
Best Use of Render
Best Use of TabPFN
Best Use of Tinker