DEV Community: Debasmita Modak

Put the Phone Down. The Sky Has Something to Show You.

Debasmita Modak — Sun, 11 Oct 2026 17:40:32 +0000

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

What I Built

On a clear night away from cities, the sky is full of stars, and I could name almost none of them. Every stargazing app I tried had the same problem: to see the sky, you stare at a bright screen held up against the sky.

Look Up is an offline night-sky field guide built around one idea: phone down, look up.

Tonight list. What's worth seeing right now from where you stand, with direction, height and best time, in plain words ("low in the east"), not raw degrees.
Quests. Each target starts as a puzzle ("three bright stars in a big triangle"). Hints only come if you ask.
Point & check. Hold the phone up and the compass and tilt sensors tell you if you're getting warmer. No camera.
A local AI guide. A small open-weight language model runs inside the browser, offline, and answers questions about the target.
Found screen. When you find something, the app gives you a fact and a 30-second countdown that asks you to put the phone away and just look.

There are 11 beginner targets: the Pole Star, the Summer Triangle, Cassiopeia, the Big Dipper, the Great Square of Pegasus, the Pleiades, Orion's Belt, Sirius, Antares, tonight's planet and the Moon. Levels are meant to remove help step by step. The real goal is that you stop needing the app.

It's for people like me: beginners who have never found anything in the sky except the Moon.

Demo

Try it: https://lookupsky.netlify.app/

It's built to work offline: open the site on Wi-Fi, ask the guide one question so the model downloads (about 470 MB, stored in your browser), then install it from the browser menu. Works best in Chrome on Android.

Here's a quest from start to finish:

1. The Tonight list: what's up right now, which direction to face, and when it's best to look.

2. A quest starts as a puzzle. No answers, just "find three bright stars that form a big triangle."

3. Stuck? Hints come one at a time, and only if you ask.

4. Point & check: hold the phone up, and when you're aimed right, it tells you to lower the phone and find it with your own eyes.

Code

meawdak / Look-Up

Look Up

Look Up: an offline night-sky field guide. Phone down, look up.
Built for the DEV Touch Grass challenge (Hacktoberfest 2026).
Try it: https://lookupsky.netlify.app/

What it does

Tells you what is worth seeing tonight from where you stand, with direction, height, and best time.
Offers puzzle-style quests for night-sky targets, with hints revealed on request.
Provides Point & check guidance using compass and tilt sensors without using the camera.
Includes a small open-weight AI guide that runs locally in your browser, completely offline.
Works offline as an installable progressive web app (PWA).

Why open-source and open-weight

Works with no signal under dark skies away from cell towers.
Location data stays on your device and is never sent to a server.
Runs without API keys, accounts, or ongoing running costs.
The model is swappable with any small GGUF model supported by wllama.

How the AI is kept honest

The sky…

View on GitHub

How I Built It

Stack: plain JavaScript and Vite, built as an installable offline web app (PWA). Positions of the Sun, Moon and planets come from astronomy-engine. Stars come from the HYG database, filtered to the 1,637 stars bright enough to matter. The AI is Qwen2.5-0.5B-Instruct (Q4_K_M quantised, about 470 MB), running in the browser through wllama, which is llama.cpp compiled to WebAssembly.

My laptop is an i3 with 4 GB of RAM, so "small" was not optional.

The one rule I built everything around: the sky engine decides what is true; the language model only decides how to say it. The model never calculates a position and never supplies a fact.

Here's how a question flows:

Code works out the facts for this target, tonight, from where you are.
A quick answer built by code appears instantly, so the screen never feels frozen.
The model gets a few short facts, written as words, and rephrases them.
A guard checks every name and number in the model's answer against the sky data. If anything doesn't match, the answer is thrown away and the quick answer stays.

The suggestion buttons ("How far away is it?") don't use the model at all. Code answers them directly. The AI is only used for questions you type.

What a 0.5B model taught me:

It can't read numbers. In astronomy, a lower magnitude means brighter. On my phone, the model looked at the raw numbers and told me Deneb was the brightest star in the Summer Triangle. It's not; Vega is. The fix was to let code do every comparison and give the model words ("the brightest of the three") instead of numbers.
Big prompts make small models copy. My first version sent a large block of data. The answers took 108 and 85 seconds on my laptop and mostly repeated my own hint text back to me. Sending fewer facts that are specific to the question made answers both better and faster.
The guard works. I asked "Who discovered it?" about a star. That fact isn't in my data, the model made up an answer anyway, and the guard rejected it. That was the moment the whole design made sense to me.

Speed, honestly:

Device	Version	Time
Laptop (i3, 4 GB)	First version	108 s and 85 s
Laptop	Smaller facts + guard	54.6 s (model load 4.3 s)
Laptop	Multithreading on	17.1 s (automated test run)
Phone (Android, 8 GB)	Early version, incl. load	47.9 s

That's still slow, which is why the code answers come first and the AI is an optional extra.

I built this with an AI coding agent (Google Antigravity) writing most of the code from my prompts. One lesson: it often said things worked without actually running the model, so I tested everything on my own laptop and phone.

What I deliberately didn't build: camera star recognition (phone cameras catch few stars, and the real technique is plate solving, not a language model), an AR sky map, accounts, cloud sync and weather. A sky darkness check is planned but not built. Levels 2 and 3 are only partly implemented.

I Took It Outside

I took Look Up outside for about 15 minutes, standing beside a main road with some bushes on one side. It did not go the way the app imagined.

The sky was barely there. I could see two to four stars with my naked eye, all of them fairly high overhead. Near the horizon there was nothing. The whole sky had a glow from streetlights, and there was heavy haze, probably smoke and pollution as well.

Northwest: one bright star, clearly visible. Everything else in that direction was too faint to make out.

East: Look Up told me Saturn was in the east, low in the sky. I looked for a while and couldn't find it. Low objects shine through the thickest part of the haze, and that side of the sky was the brightest from city lights.

What I learned: the app was right that Saturn was above the horizon, but being above the horizon is not the same as being visible. My sky engine knows where things are. It has no idea what the air and the lights around you are doing to them.

That is exactly the gap the planned sky darkness check is meant to fill: count the stars you can actually see, and let the app adjust what it suggests, or nudge you toward a darker spot. After that night, it moved from "nice idea" to the first thing I want to build next.

It wasn't the magical stargazing session I pictured. But for fifteen minutes I wasn't looking at a screen. I was squinting at a hazy sky, trying to find a planet. That's the whole point of the app, even when the sky doesn't cooperate.

Why Does Open Innovation Matter?

For this app, it's not a nice extra. Without open weights the app doesn't work.

Dark skies have no signal. The best places to stargaze are far from cities, which usually means far from mobile networks. A guide that calls a cloud API fails exactly where it's needed. An open-weight model runs on the phone itself.
Your location stays on your phone. The app needs to know where you're standing. Nothing is sent anywhere, because there's nowhere to send it.
No API key, no bill. It costs nothing to run, for me or for anyone who forks it. A student project can stay online without a credit card.
The model is swappable. Any small GGUF model can replace Qwen. When better small models come out, the app gets better without me changing the design.

Open data mattered just as much: the star catalogue, the constellation lines and the astronomy maths are all openly licensed. I wrote the glue. The sky came from other people who chose to share.

Thanks for reading. Now go outside and look up.

I Built My Best Friend an Offline Trek Planner With a Local Gemma AI That Can't Make Things Up

Debasmita Modak — Sun, 04 Oct 2026 21:42:16 +0000

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

Who I built it for

My best friend treks in the Himalayas, the mountains are where he feels most like himself, and the planning before each trip is a ritual for him, a way of settling into the journey before it begins. But I've watched that ritual turn into chaos more than once: a train ticket in an SMS, a homestay number in a WhatsApp chat, the gear list in a notes app and the rest in his head. He kept wishing it were all in one place, so he could stop worrying about what he'd forgotten.

So, I built Trek Organizer, an offline-first trek planning app with a local Gemma model at its heart that turns his scattered notes into one clear plan and tells him what's still missing.

What I Built

Trek Organizer is a phone-first trek planner that works offline. He enters his trip, travel, stays, trek days, gear, food and emergency contacts, and the app shows what's missing, what's unconfirmed and what's still to buy or borrow. On the trail, a Today screen shows only what he needs: where he's going, where he's sleeping, and who to call.

Gemma does two jobs:

1. Sort my notes. He pastes messy text, like a train booking SMS or a WhatsApp message from a guide, and Gemma pulls out the travel, stays, gear, food, contacts and permits. Each one shows up as a card he can Add or Skip. Nothing goes into his plan without his tap.

2. Plan check. Gemma looks at his trek conditions (month, altitude, days, camping or not) and his gear list. It suggests gear he's likely missing, with a one-line reason and an Add to Gear button. It also asks the questions he should be able to answer before leaving, like "What will you do if the jeep to the trailhead doesn't run?"

The rule I built everything around: it must not make things up

On a trek, a confident wrong answer is worse than no answer. If an AI says "there's water at camp 3" and there isn't, that's a real problem.

So Gemma is never trusted on facts:

Every extracted value is checked against his own text, in plain code, not AI. If Gemma returns a place, name, booking number or phone number that doesn't appear in what he pasted, the code deletes it and tells him something was left out.
Unknown stays unknown. Anything added from notes is marked Unknown until he confirms it himself.
Suggestions are labelled as suggestions, e.g. "Suggestion — check this yourself". It never suggests medicines.
The counting is done by code. What's packed, what's missing and what's unconfirmed are all calculated without AI.

I tested this with deliberately vague text, like "Ask Raju at the dhaba about a jeep. Leave early on the first day." Gemma didn't invent a phone number for Raju or turn "early" into a time.

Demo

Live app: meawdak.github.io/Trek-Organizer

Images from phone:

The planner works for everyone straight from the link. The Gemma features need Ollama running on your own computer: install Ollama, run ollama pull gemma3:4b, and follow the setup steps in the README

What He Said

"Planning a trek has two sides: the physical preparation and the mental one. For me, building the itinerary and going through that mental checklist is how I prepare myself psychologically before I head out.

Until now, that process was hectic. I'd be jumping between websites, YouTube videos, random notes and multiple AI chats, trying to hold it all together. And trek planning isn't something you can be casual about. It needs seriousness and caution.

When I first used Trek Organizer, it honestly exceeded my expectations. It doesn't just organise my plans, my itinerary and every little detail in one place. It also checks through everything and points out the things I tend to forget.

What surprised me most is that I actually trust it. I don't usually trust AI with something this important, but this one is careful. It doesn't guess, it doesn't make things up, and it treats planning a trek as the serious task it is. That's exactly how she built it, and it shows."

— my best friend

Code

meawdak / Trek-Organizer

🏔️ Trek Organizer

An offline, phone-first trek planner with a local AI that checks your plan and never makes things up.

Trek Organizer keeps everything about a trek in one place — travel, stays, trek days, gear, food, permits and emergency contacts and shows what's missing, unconfirmed or still to buy before you leave. On the trail, it works with no internet.

Its AI features run on Gemma, an open-weight model, locally through Ollama. Your notes and plans never leave your device.

🔗 Live app: https://meawdak.github.io/Trek-Organizer/
🏆 Built for the Hacktoberfest Weekend Challenge: Build for a Friend

📸 Screenshots

Dashboard	Timeline	Gemma — Sort my notes	Gemma — Plan check

💡 Why I built this

I built this for my best friend, who treks regularly in the Himalayas.

For him, planning a trek is part of the preparation itself. But his plans were scattered across booking SMSes, WhatsApp…

View on GitHub

How I Built It

Gemma 3 (gemma3:4b), run locally through Ollama on his everyday laptop: an Intel Core i3 (12th gen) with 8 GB RAM and no dedicated graphics card. The app talks to Ollama directly from the browser, so his notes and plan never leave the machine. While Gemma works, the app shows a timer and a Cancel button, because on a laptop like this a run can take a little while.
Gemma is set to temperature 0 and strict JSON output, with a short system prompt that tells it to only extract or check, never plan or invent. Its answer then goes through my own code: a filter that drops junk and duplicates, and a check that keeps only values found word-for-word in his text.
The app is plain HTML, CSS and JavaScript as an installable web app (PWA) with a service worker, so it works offline on a phone. There's no backend and no login, and his data stays on his device. Since Gemma runs on the laptop and the trek happens on the phone, he exports his plan as a JSON file and imports it on his phone before he leaves.
I planned the product and wrote the specs (PRD, UX and technical spec, plus agent rules like "never invent missing information"), then built it step by step with Antigravity, testing each step before moving on.

Why Does Open Innovation Matter?

His data stays with him. Booking SMSes have PNR numbers and phone numbers. Here, they're processed by Gemma on his own laptop and never sent to anyone's server. With a closed API, every note he pasted would leave his hands.
No internet needed on the trail. The app works fully offline on his phone. Gemma runs on the laptop while he plans at home, and everything it helped add is already saved in the app when he leaves.
It costs nothing to run. No API key or subscription for something he'll use every trek.
I control how it behaves. I chose the model, wrote its rules, and put my own check after every answer. I can swap in a bigger Gemma model on a stronger laptop without changing anything else. A closed API could change its behaviour or pricing under us.

My Agent Session

I built Trek Organizer with Antigravity in two sessions:

Prize Categories

Gemma: Gemma is the core of the app's AI features, running locally through Ollama.