What Now? – A Local-First AI Next-Action Coach for a Tired College Student

Arpita Singh — Mon, 05 Oct 2026 06:58:30 +0000

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

What I Built

I built What Now? for a friend of mine. She's 20, in her second year of CS, and she has the kind of schedule that looks fine on paper and falls apart by evening.

Here's what I kept noticing. She isn't confused about what matters. She has a DBMS assignment due tomorrow, placement prep she's behind on, a gym membership she pays for and doesn't use, and a real need to rest. She knows all of it. But at 7:30 PM, after a full day of college, the gap between knowing and starting is where the evening goes. One reel becomes ten. "I'll start after this episode" becomes three. The assignment stays open in a tab she doesn't touch.

It isn't laziness. Deciding what to start takes more energy than starting it.

What she needed wasn't another planner. She's tried those. They hand her a list of twelve things and call it clarity, which is the same problem wearing a nicer font. What she needed was for something else to make the call. One thing. Right now. Small enough that saying yes doesn't feel like a commitment.

That's what I built. A loop, not an app. She opens it, sets her energy on a 1–5 slider, says how many minutes she has, and hits one button. The app pulls her active tasks, sends the context to a language model running locally, and gets back a single action:

Open the DBMS assignment PDF and write the first SQL query for Q1.
Why: due tomorrow at 9 AM, high urgency.
First step: open the PDF. Timebox: 15 minutes.
Fallback: if still low energy, review one DSA problem instead.

That's the whole output. No list. No options. No priority matrix asking her to rank things she's too tired to rank.

The flow, end to end:

She adds her tasks once, whenever she has the energy to think about them. Title, deadline, roughly how long it'll take, how much energy it costs, and how much it matters.
Later that evening, she opens the app. Nothing to re-enter. Her tasks are already there.
She sets energy to 2 and minutes to 45. The check-in form is the first thing on the page, because that's the only decision I want her making at 7:30 PM.
The app sends her context to Gemma 3 4B, running locally through Ollama, and gets back one action with a reason, a two-minute first step, a timebox, and a fallback.
The action card appears below the form. She reads it, and either starts or she doesn't.
Either way, she taps Done, Skip, or Blocked. The outcome gets logged, so the app builds up a history of what actually got done versus what got suggested.
Next time she checks in, the loop runs again.

The goal was never to turn her into a productivity machine. She can still watch her shows and play guitar. The goal was to close the gap between knowing and starting.

Demo

Local-first, so there's no hosted URL, the app runs on her laptop alongside Ollama.

Code

GITHUB

How I Built It

Stack: FastAPI with HTMX on the front end, SQLite for storage, and Gemma 3 4B running locally through Ollama.

Four files carry the project:

prompts.py holds the system prompt. It tells the model to return strict JSON with five fields: action, why, first_step, timebox_minutes, fallback.
agent.py calls Ollama's /api/generate endpoint with format: "json", which constrains output to valid JSON at the sampler level. No markdown fences, no "Sure, here's your answer."
db.py stores tasks and logs every action with its outcome.
main.py wires the routes and swaps HTML fragments with HTMX.

The prompt does most of the heavy lifting. It tells the model to pick exactly one task, to respect energy levels (if energy is 2 or below, no high-energy tasks unless the deadline is under 24 hours), to keep timeboxes under 25 minutes, and to write like a peer rather than a coach. No "let's crush it" or "you got this." The model isn't doing anything clever here. The context carries the thinking. The model just picks and phrases.

Swapping models is one environment variable:
WHATNOW_MODEL=qwen2.5:7b uv run uvicorn src.what_now.main:app

I went with Ollama over the alternatives because it handles quantization, memory, and model downloads without me writing any of that myself. It exposes a plain HTTP endpoint, so the Python side is a single httpx call. Nothing about the app is tied to Gemma specifically. The prompt, the schema, and the check-in flow all work with any instruction-following model you can run locally.

Why Does Open Innovation Matter?

Her task list contains her exam schedule, her placement prep, and goals she hasn't shared with anyone. A closed API would mean sending that to a server, paying per call, and trusting a vendor's logs.

Running Gemma locally through Ollama means:

Nothing leaves her laptop.
No API bills and no rate limits.
Every prompt is in the repo. She can read exactly what the model sees.
When a better open model comes out, she swaps one environment variable.

That last one is the part I keep coming back to. If I'd built this on a closed API, the project would be a wrapper around someone else's product, and it would stop working the day they change their pricing or deprecate the model. Because the model runs on her machine, it's hers. She can read it, change it, or replace it without asking anyone.

Prize Categories

Best Use of Gemma

Introduction to Object-Oriented Programming (OOP)

Arpita Singh — Fri, 02 Oct 2026 18:38:53 +0000

Object-Oriented Programming (OOP) is a programming paradigm centered around structuring code into self-contained units called objects. Instead of storing related data across separate, disconnected arrays, OOP bundles data and actions together to model real-world entities cleanly.

Key Building Blocks:

i) Class: The structural blueprint or template (e.g., User or BankAccount). It defines what fields and methods its instances will have.

ii) Object: A concrete instance created from a class residing in memory (e.g., user1).

iii) State (Fields): The data or properties an object holds, such as email, balance, or status.

iv) Behavior (Methods): The actions an object can perform, such as login(), deposit(), or withdraw().

The 4 Core Pillars:

i) Encapsulation: Hides internal data using private fields and exposes controlled access via getters and setters to protect data integrity.

ii) Abstraction: Exposes essential features while hiding underlying implementation details using abstract classes and interfaces.

iii) Inheritance: Enables child classes to reuse properties and methods from a parent class via extends.

iv) Polymorphism: Allows methods to execute differently based on the object invoking them, through method overloading and dynamic overriding.

By enforcing separation of concerns, OOP prevents silent data corruption, eliminates synchronization bugs, and makes large software applications modular, scalable, and easy to maintain.

DEV Community: Arpita Singh