DEV Community: Noorin S

I Built an AI App That Wants You to Close It

Noorin S — Fri, 09 Oct 2026 03:57:01 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Most AI apps are built to keep you talking. I wanted to build one whose success condition is the opposite: the best interaction with it is closing it.

OFFLINE is an expedition-map-style web app. You tell it how much time you have and what you need. A local Gemma model then writes you a short outdoor mission made of small, strange, sensory steps, and the app gets out of your way. Its last message is always the same:

You're done. Close OFFLINE.

What I Built

OFFLINE is an AI adventure guide designed to become unnecessary.

The flow takes about thirty seconds of screen time:

Check in. Pick how long you have (15, 30, 60 or 90+ minutes) and what you need: clear my head, explore, move, be alone, or surprise me. Optionally say roughly where you are (city, park, village). There's no GPS and nothing is requested from your browser.
Get a mission. Gemma writes the whole thing: a title like "The Quiet Corner", a one-line premise, 4 to 7 steps, a reflection question, and the closing line.
Walk it. Your mission is drawn like a route on an old map, with a red X marking where you are. Each step asks for one concrete thing: "Turn toward the most interesting sound you can hear and walk a little way toward it."
Put the phone down. Press the button and the screen turns into a bare night chart: one calm ring timer, the instruction, and nothing else. You come back for the next step only when you're ready.
Close it. A one-line reflection, an ink stamp ("EXPEDITION COMPLETE"), and a button that says CLOSE OFFLINE.

Who it's for: anyone who opens their phone "for a second" and loses an hour, and anyone who wants a reason to walk somewhere familiar and notice it differently. It's for people who don't want a hiking app, a fitness tracker or another feed.

What it deliberately does not have: streaks, badges, points, accounts, history, notifications or a chat box. Every one of those would pull people back to the screen, which is the opposite of the point.

Code

NS007-dev / offline

OFFLINE

An AI adventure guide designed to become unnecessary.

Created by Noorin Sakhi.

Built for Hacktoberfest 2026, Challenge 2: Open-Source AI ("Touch Grass").

What OFFLINE is

You open the app, say how much time you have and what you need, and a local Gemma model writes you a short outdoor mission: a few sensory, non-optimized steps like "turn toward the most interesting sound you can hear." Then the app tells you to put your phone down. It reveals the next step only when you come back for it, and its last message is: "You're done. Close OFFLINE."

It is deliberately not a chatbot, a hiking planner, or a map app.

Why it exists

Most AI products are built to keep you talking to them. OFFLINE's success condition is the opposite: the best interaction with OFFLINE is closing OFFLINE. No feeds, streaks, badges, or accounts. The screen should be…

View on GitHub

Run it in about five minutes (you need Python 3.10+, Node 20.19+ or 22.12+, and Ollama):

# 1. a Gemma model (any Gemma tag works)
ollama pull gemma3:1b            # small and fast; or a larger one if your machine can take it

# 2. backend
cd backend
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
OFFLINE_MODEL=gemma3:1b python3 -m uvicorn app.main:app --reload

# 3. frontend (new terminal)
cd frontend
npm install && npm run dev       # open http://localhost:5173

No API keys, no accounts, no cloud. python3 -m app.cli --time 30 --need surprise generates a mission straight in the terminal if you want to test Gemma before the UI.

How I Built It

The stack

React + TypeScript + Vite  ->  FastAPI  ->  Ollama  ->  Gemma (open weights)
                                  |
              validate -> safety screen -> retry once -> hand-written fallback

Gemma writes every mission. The app contains no mission templates for the main path. It sends Gemma a short check-in and asks for JSON that matches a schema, using Ollama's structured outputs. The hand-written missions exist only as a fallback, and the app tells you when you're seeing one.

Making Gemma interesting, not just correct

My first missions were safe and samey. "Take a deep breath and notice your surroundings" is not a quest. Three changes fixed most of it:

A voice. The system prompt casts Gemma as a quiet, slightly mysterious game master and bans clichés outright ("be present", "connect with nature", "embrace the moment").
A twist per step. Every step must ask for one concrete thing with a small rule that makes it feel like a game: "Follow the quietest direction for ten steps," not "Take a walk."
A random lens. Each request carries one of twelve lenses (sound, colour, age, edges, light and shadow, small things, texture, direction, stillness, signs of people, weather and air, looking up) that Gemma threads through the mission, so two requests rarely come out alike.

LENSES = [
    "sound: what you hear, where it comes from, what is just out of earshot",
    "age: things that were here long before you, and things that will outlast today",
    "edges: borders, corners, thresholds, where one place turns into another",
    # ...nine more
]

Never trust a model you can't audit

A small local model will sometimes ignore instructions, and this app tells people to walk around outdoors, so I treat everything Gemma returns as untrusted input. Safety is three layers:

Layer	What it does
Prompt	Tells Gemma the rules: ordinary public places only; no trespassing, climbing, unsafe road crossings, approaching strangers, ignoring signs, being lost on purpose, special equipment, purchases, or after-dark activity.
Safety screen	A deliberately blunt filter over every sentence. It blocks "Climb the fence" and "Open Google Maps," but lets "Do not search your phone for it" through.
Validator	Enforces the design rules: 4 to 7 steps, at least two phone-down steps, durations that fit your time, and a final line that tells you to close the app.

If a mission fails, the backend retries once and tells Gemma exactly what was wrong ("step 3 has no instruction; durations add up to 41 minutes, more than the 30 available"). If it fails again, or Ollama is down, slow or missing the model, you get a hand-written mission that passes the same validator, with an honest notice explaining why. The app never pretends Gemma wrote something it didn't.

Things the tests caught

I wrote 30 backend tests and 15 browser tests. The backend tests run against a pretend Ollama server I can make misbehave on command: bad JSON, an unsafe mission, a slow reply, a missing model, or no server at all. That earned its keep:

My safety filter blocked my own fallback. It flagged "keep your phone in your pocket" as phone use. I narrowed the rule and added a regression test.
Screen-reader users had no heading on step 2 onward. My accessibility check caught it, and it's fixed.
A "pop-in" animation shrank buttons to 41px mid-animation and failed my 44px tap-target check. I dropped the scaling.

An honest note on what I did not measure: the automated tests use a stand-in model, so they prove the pipeline, not how good Gemma's missions are. That part I judged by running real missions myself (see the field test above).

The design journey

I redesigned the interface three times, and it's the part I learned the most from:

A calm forest-green theme. It looked fine and felt like every other app, a slideshow of words you tap through.
A bright, quirky sticker style. Too childish, and it still looked like an app.
An expedition map. Parchment, contour lines, a compass whose needle swings and settles, a dotted route with a red X, and a night-chart "phone down" screen. The goal was a page that doesn't feel like it's on a device at all.

Accessibility and privacy by construction

Choices are real radio buttons (arrow keys work), headings take focus on every screen, tap targets are at least 44px, and all motion switches off under prefers-reduced-motion. Phone-down timers compare against the clock, so they stay correct when your screen sleeps. There are no cookies, no localStorage and no third-party requests, and a test asserts that the browser only ever talks to localhost.

Built with an AI pair-programmer

In the spirit of transparency: I built OFFLINE from a written build spec, using Claude as my coding partner in a long back-and-forth. I made the product calls, ran everything on my own machine, hit the real errors (a failed ollama pull, a model-name mismatch), and redirected the design when it wasn't right. The runtime has no closed dependency at all. The only AI inside the app is open-weight Gemma running locally.

Why Does Open Innovation Matter?

I built OFFLINE for people who are trying to spend less time with technology. A cloud API would quietly undercut that, and an open model fixes it in four ways:

Privacy is a fact, not a promise. The mission is written on your machine. There's no server to trust, no key to leak, and no log of when and why you wanted to get outside. The only context Gemma ever sees is "30 minutes, clear my head, a park."
No signal needed once you leave. The mission is generated before you go. After that, every step and timer lives in the page, and the app makes no network request again. You can walk out of Wi-Fi range with your mission in your pocket.
I could swap the model by changing one word. The model is a single environment variable (OFFLINE_MODEL). I could trade a tiny, fast Gemma for a larger, more creative one on the same laptop without touching code, and see the difference in the missions right away. A closed API would have chosen that trade-off for me.
It costs nothing to run. No per-mission fee, no rate limit, no billing page. An app meant to be opened for thirty seconds shouldn't come with a meter.

There's also a quieter reason. An app that treats model output as untrusted input is much easier to build when you control the model, the prompt, the sampling and the schema. I could tune the temperature, constrain the output shape and reproduce failures locally. For a project that sends people out the door, that control is a safety feature.

Prize Categories

Best Use of Gemma. Gemma runs locally via Ollama and writes every mission end to end: title, premise, steps, reflection and closing line. It's constrained with a JSON schema, steered by a voice and a rotating creative lens, validated and safety-screened, and swappable across Gemma sizes with one setting.

What's Next

OFFLINE is deliberately small, and I'd like to keep it that way. If I keep building, it would be:

Gentle context, kept ephemeral: optional daylight and weather so missions fit the hour, never stored.
A "found it" step type: missions that ask for something to spot, and read it back in the reflection.
Sound for the end of a timer: a soft chime, for people who put the phone in a pocket.
A real phone field test on cellular, away from the laptop.

Known limits: the safety screen is a keyword filter, not a guarantee. OFFLINE doesn't know your surroundings, so it can't verify any place exists. Small models vary from run to run, and it can't buzz you while your screen is locked.

Made by Noorin Sakhi, MIT licensed. If you try it, I'd love to hear what your mission was and what you noticed.

I built my sister a personal stylist that lives on my laptop

Noorin S — Mon, 05 Oct 2026 08:02:59 +0000

Every morning, I get asked the same question: "What am I going to wear?"

Her closet is full of potential outfits, but choosing takes time, she doesn't want to repeat an outfit, and she wants whatever she wears to feel like her.

So I built her something. It's called ClosetCue.

I started it for the Hacktoberfest Build for a Friend challenge. I missed the submission cutoff by about twenty minutes, so this isn't an entry. I still wanted to share it, because it's the project I'm proudest of so far.

I asked her first

Before writing any code, I asked my sister what the problem actually was. Her answers became the product:

Choosing outfits for school mornings and for going out is hard.
Not repeating outfits is a big worry.
Choosing what to wear is stressful.
Her two main occasions are school and shopping / going out.
Style matters most to her.
She's willing to photograph her entire wardrobe.
Her dream feature: an outfit waiting for her every morning.

The problem wasn't "nothing to wear." It was decision fatigue.

What ClosetCue does

She photographs the clothes she already owns. A local AI model reads each photo and writes a caption: category, type, colour, pattern, style, season. She can correct anything it gets wrong. She picks the styles and moods she loves, and then the app styles a look for School or Shopping / Out, using only clothes she actually owns.

She can tap Wear this to file the outfit, or Try another and tell it why. Every look she wears goes into an archive, so the app remembers.

The AI doesn't get to break the rules

The decision I'm happiest with was splitting the work on purpose:

The AI handles	Plain code handles
Reading clothing photos	Storing the wardrobe
Proposing outfits	Remembering what was worn
Explaining why a look works	Blocking repeats
	Checking an outfit is complete (top + bottom or a dress, plus shoes)
	Ranking and validating

The AI proposes four outfits. Then code throws out anything invalid or recently worn, ranks what's left (pieces she hasn't worn lately and her chosen styles score higher), and shows the best one. No complete outfit repeats within 14 days, and every look comes only from her real closet.

If I'd let the AI do everything, it would eventually suggest a jacket she doesn't own. Putting the rules in normal code means they can't be ignored.

Why open-weight matters here

ClosetCue runs an open-weight Gemma model on my own laptop through Ollama. It costs nothing to run, needs no account or paid API, and her photos are read on the same machine that stores them.

I'll be exact about what that means. Photos and the database stay on my laptop. The AI runs locally, so nothing is sent to an AI service. The browser does load the typefaces from Google Fonts, and downloading the model the first time needs internet. It's also a single-user local app with no accounts, so it shouldn't be put on the public internet as it is.

It had to look like her, not like a dashboard

I didn't want a chatbot or an analytics screen. I wanted it to feel like opening a magazine: a serif masthead, hairline rules, ivory paper, one oxblood accent, and big numbered photos with captions, like a fashion spread.

What went wrong

This is the part I learned the most from.

Uploads froze. At first, every photo waited for the AI to finish reading it before the next one could upload. Ten photos took forever, and reloading the page lost everything. I rebuilt it so photos save instantly and the AI reads them in a background queue on the server. It survives reloads and restarts, and unfinished pieces show "Reading…".

Outfits hung. When the AI was busy with photos, asking for an outfit just sat there. Now the AI gets 25 seconds, and if it's too slow, a simpler mode takes over. The simple mode still builds valid, non-repeating outfits, so she's never left waiting.

A hosting lesson. I wanted to put it online, then realised that would mean accounts, private storage per user, and a plan for the AI. It's a rewrite, not a setting. So it stays local for now, and that's in my "next" list.

Her reaction

[Replace this with what she actually said or did when she used it. Keep it honest, even if it's mixed.]

What's next

Choose several pieces and build a look around all of them
Build an outfit by hand
Accounts and private per-user storage, so others can use it safely
A real morning notification

Try it

The code and setup steps are on GitHub: NS007-dev/closetcue

Built with React, TypeScript, Vite, Tailwind, Python, FastAPI, SQLite, Ollama and Gemma.

If you build something for one specific person, I recommend it. Asking her what she needed did more for the project than any technical choice I made.