DEV Community: Danish Irfan

I Built an AI App That Actually Wants You to Put Your Phone Away 🌿

Danish Irfan — Mon, 12 Oct 2026 06:58:21 +0000

I Built an AI App That Actually Wants You to Put Your Phone Away 🌿

This is my submission for the Hacktoberfest 2026 Week 1: Touch Grass Challenge.

What I Built

I spend most of my day in front of a computer.

I work in software engineering, and since I work remotely, there are days when I barely have a reason to leave the house.

And I realized something funny while thinking about this challenge.

We already have apps for almost everything. Apps to make us productive, apps to entertain us, apps to track our habits, and apps to remind us to use other apps.

But what if I built something that actually encouraged people to put their phones away?

That's how I came up with Outside Lab.

Outside Lab is a small AI-powered outdoor experiment app that helps you discover which outdoor activities work best for you.

The idea is simple.

Instead of telling everyone to walk 10,000 steps or spend an hour exercising, the app encourages you to try little outdoor experiments and pay attention to how you feel.

Maybe you spend five minutes sitting in your courtyard.

Maybe you take a short walk.

Maybe you spend a few minutes playing with your dog.

Nothing particularly extraordinary. Just small moments away from your screen.

And yes, your own courtyard counts. You shouldn't need to organize a hiking expedition just to get some fresh air.

How the prototype works

I built the prototype around a simple three-step experience.

1. Check in before going outside

You tell Outside Lab how you're feeling, choose an activity, and decide how many minutes you'd like to spend outdoors.

2. Put your phone away

Start the session, leave your phone alone, and go do whatever you chose.

The timer keeps track of elapsed time using actual timestamps, so you don't need to keep the app open and stare at a ticking clock.

3. Come back and reflect

When you're done, you record how you're feeling afterward and optionally write a short observation.

The app saves your session to a personal journal, where you can see your outdoor time, activities, and before-and-after mood ratings.

That's the prototype's core experience.

But I wanted to take the idea further.

Where AI comes in

Imagine using Outside Lab for a couple of weeks.

You might discover that sitting outside for five minutes doesn't seem to change much for you, but walking around for ten minutes often leaves you feeling more refreshed.

Or perhaps spending time with your dog feels more enjoyable than walking alone.

Instead of giving everyone the same advice, I want Outside Lab to learn from these little experiments and suggest what each person should try next.

For example:

"You've tried sitting outside a few times. How about a short walk today? Let's see whether changing the activity makes a difference."

That's the reason I integrated an open-weight Qwen model through Backboard.

The idea isn't for AI to tell you how happy you should be. It's to help you ask better questions about your own experiences.

And importantly, a change in mood doesn't prove that an activity caused it. Outside Lab treats these observations as clues worth exploring, not scientific conclusions.

Demo

GitHub repository: https://github.com/danishirfan21/Outside-Lab

The repository contains the working session-tracking prototype, including a React frontend and a lightweight browser preview.

You can try the basic experience without needing an API key. The repository's README explains how to run the full application locally.

The AI integration is also implemented, although successful live inference is still being verified. During testing, Backboard accepted our requests but reported failed model runs. Rather than pretending those requests succeeded, the app keeps its ordinary starter suggestions separate from AI-generated recommendations.

This is an early prototype, and I'm sharing it as one.

Code

Source code: https://github.com/danishirfan21/Outside-Lab

The project is open source under the MIT License.

I wanted the code to be approachable enough for someone else to clone it, try it, experiment with another open-weight model, or build something better on top of it.

How I Built It

For the prototype, I kept the architecture fairly simple.

The frontend is built with React and TypeScript, with FastAPI handling the backend.

I used browser storage for the personal journal, so you don't need to create an account just to record a few minutes spent outside.

For AI, I integrated Backboard with an open-weight Qwen model.

When you request an AI recommendation, the backend is designed to send a small summary of your previous sessions to the model. The model's job is to propose one realistic outdoor experiment based on that history.

The application itself handles the actual numbers, like elapsed time and the difference between mood ratings. I didn't want an LLM making up statistics that ordinary code could calculate more reliably.

One surprisingly important detail was the timer.

If you put your phone away or lock the screen, browser timers aren't always dependable. So I used timestamps to calculate elapsed time and added recovery for interrupted sessions.

I also wanted the app to remain useful when AI wasn't available. You can still complete an outdoor session, record your mood, and review your journal without making a model request.

For the current prototype, the React production build passes, along with 8 frontend tests and 12 backend tests.

What I'd like to build next

This is the part that excites me most.

Right now, Outside Lab is a prototype for recording simple outdoor experiments.

Eventually, I'd like it to become a personal AI outdoor companion that gets to know what works for you over time.

Here are some directions I'd love to explore.

Personalized experiments

Rather than suggesting random activities, the AI could look at your previous experiences and design small comparisons.

Maybe you try walking instead of sitting. Or spending ten minutes outside instead of five.

Over time, it could help you discover which activities you actually enjoy repeating.

Learning from longer-term patterns

A single session doesn't tell us much.

But what happens after 20 or 30 sessions?

I'd like Outside Lab to help people explore patterns across activities, durations, and different times of day, without pretending correlation is causation.

Making outdoor time easier to remember

For people who work remotely, it's surprisingly easy to spend an entire day indoors without noticing.

In the future, I'd like to explore gentle reminders and optional outdoor-time detection, perhaps through phone or wearable sensors.

But I'd want these features to respect privacy and avoid constantly tracking someone's location.

More real-world context

Eventually, the app could consider things like weather, available outdoor space, and personal preferences.

Someone with a courtyard should receive different suggestions from someone who prefers visiting a park.

Someone who only has five minutes should still be able to participate.

Less screen time, not more engagement

This is the principle I want to preserve as Outside Lab evolves.

I don't want to turn it into another app that pressures people to maintain streaks, collect badges, or keep checking notifications.

The best part should always happen outside the app.

Why Does Open Innovation Matter?

I think open innovation matters because ideas become much more interesting when other people can explore them, question them, and improve them.

Outside Lab is a small experiment, and I'm not pretending I've figured out the perfect way to encourage outdoor activity.

Maybe someone has a better idea for personalizing experiments.

Maybe someone wants to connect an open-weight model running locally.

Maybe someone can make the experience more accessible, improve the privacy approach, or help people who have limited access to outdoor spaces.

That's what I like about building this in the open.

Using an open-weight Qwen model also means the AI side doesn't have to remain dependent on one proprietary model forever. There are opportunities to experiment with different models, hosting arrangements, and recommendation approaches.

The prototype currently uses hosted inference through Backboard, but the underlying model and application logic are not meant to be locked to that setup permanently.

My Agent Session

I used Codex during development to help implement the prototype, review the code, fix bugs, and strengthen the tests.

One useful lesson was that getting automated tests to pass isn't the same thing as proving an external AI service works.

We got the application and its integration tests working, then discovered that our live Backboard requests were failing during model execution.

So we added better diagnostics and documented the problem instead of hiding it.

AI coding tools made it possible to build and iterate on the prototype quickly, but testing and verification still matter.

Prize Categories

I'm submitting Outside Lab for the Overall Touch Grass category.

The project also explores Backboard integration with an open-weight model, although that part is still undergoing live verification.

One last thought

I originally approached this challenge wondering what kind of AI application I could build that would genuinely involve the physical world.

I kept coming back to the same thought.

Maybe we don't need another complicated reason to go outside.

Maybe we just need a little encouragement to do it, and a way to discover which experiences make us want to do it again.

That's what I hope Outside Lab can eventually become.

An app that helps you understand your relationship with the world outside your screen.

Because sometimes the best thing technology can do for us is remind us to stop using it. 🌿

Dispatch: I Built My Friend an AI News Agent That Knows When News Actually Changes

Danish Irfan — Mon, 05 Oct 2026 06:16:49 +0000

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

What I Built

My friend Hammad didn't need more news.

He needed less noise.

The idea started with a simple request: an AI news scanner that could understand what a user cares about and produce a brief summary so they could catch up quickly, with Pakistani news being one of the original use cases.

That became Dispatch.

Dispatch is a personalized AI news agent that learns what you care about, retrieves current reporting, and builds a concise Brief around your interests.

But while building it, I realized that summarization alone doesn't solve the harder problem.

If I follow a developing story, I don't want to be notified because another article was published. I want to know when the underlying story actually changed.

So Dispatch also lets you follow a story and tell it exactly what you are waiting for.

For example:

Notify me when API access becomes publicly available.

Dispatch then keeps track of what you already know, checks new reporting in the background, filters repeated coverage, and records a development only when there is evidence of a meaningful change.

What Dispatch can do

Understand interests written in natural language
Turn those interests into structured topics and search terms
Retrieve live Google News results
Build a personalized AI-curated Brief
Explain why each story matters to you
Let you dictate your interests by voice
Read your Brief aloud with synchronized text highlighting
Let you follow developing stories
Remember what you already know about a story
Let you define a specific notification condition
Distinguish repeated reporting from meaningful developments
Maintain a timeline of genuine developments
Automatically recheck followed stories every hour
Send an email when a development is actually worth notifying you about

The goal is simple:

Don't tell me that another headline exists. Tell me when something changed.

Demo

Live app

https://dispatch-55oo.onrender.com

The project is deployed as a single-origin application on Render: FastAPI serves the API and the built React frontend, while a separate Render Cron job runs the background monitoring cycle.

Code

https://github.com/danishirfan21/Dispatch-News-Agent

danishirfan21 / Dispatch-News-Agent

Personalized AI news agent that builds concise briefs, tracks developing stories, and alerts you only when something meaningfully changes.

Your news, without the noise. A personalized AI news agent that builds concise briefs, follows developing stories, and alerts you only when something meaningfully changes.

Live app · GitHub repository

Why Dispatch exists

Dispatch started with a request from my friend Hammad: he wanted an AI news scanner that could understand a user's interests and turn the day's reporting into a short brief that was actually worth catching up on.

That simple idea exposed a bigger problem: getting more news is easy; knowing what is new, relevant, and worth interrupting you for is hard.

Dispatch therefore does more than summarize headlines. It learns what you care about, creates a personalized Brief, remembers the state of stories you follow, checks fresh coverage over time, and distinguishes a genuine development from another article repeating the same facts.

The result is a news workflow built around signal instead of volume.

What it

…

View on GitHub

How I Built It

Dispatch has a React + TypeScript frontend and a FastAPI backend, with MongoDB Atlas storing user profiles, Briefs, Watches, development history, and the notification outbox.

The core stack is:

React + TypeScript + Vite + Tailwind CSS for the frontend
FastAPI + Python for the backend
MongoDB Atlas for persistent application state
Backboard for the AI reasoning layer
MoonshotAI Kimi-family open-weight model, routed through Backboard/OpenRouter
SerpApi for live Google News retrieval
ElevenLabs for speech-to-text and narrated Briefs
Mailjet for email notifications
Render for the web application and hourly background monitoring

Backboard + open-weight AI

AI is not an optional decoration in Dispatch. It sits in three core parts of the product.

1. Understanding the user

A user can write something messy and human like:

New AI models and developer tools, major cybersecurity news, NVIDIA and semiconductor updates. Skip celebrity news and speculation.

The model converts that into structured interests, search terms, and excluded topics.

2. Building the Brief

SerpApi retrieves current reporting, but raw search results are still just another feed.

The model evaluates those articles against the user's interests, rejects weak matches, merges articles covering the same event, prioritizes substantive developments, and selects up to five stories for the Brief.

Each story also includes a personalized explanation of why it matters to that particular user.

3. Detecting meaningful change

This became the most interesting part of the project.

For every followed story, Dispatch stores a known_state: what the user already knows.

When a Watch is checked:

Dispatch searches for fresh reporting about that story.
Previously seen URLs are removed.
The model receives the current known state, the new evidence, the user's optional notification condition, and recent recorded developments.
It returns structured fields including:
- whether a material change occurred
- whether the user's condition was satisfied
- a summary of the change
- an updated known state
- supporting article IDs
The backend verifies that the model actually cited articles from the retrieved evidence.
A deterministic similarity check prevents a reworded version of a recent development from being recorded again.
Only then is the development persisted.

I deliberately made this conservative.

A model claiming "something changed" is not enough by itself.

Automatic monitoring

A separate Render Cron service runs every hour.

It does not call the public web application. Instead, it directly invokes the same Python monitoring services used by manual checks.

For every due active Watch it:

retrieves fresh news
runs meaningful-change analysis
records verified developments
creates notification jobs when appropriate
processes the email outbox

A failure checking one Watch does not stop the rest of the batch.

Reliable notifications

Notifications use a small transactional outbox in MongoDB.

A notification moves through:

pending → processing → sent

or, if delivery keeps failing:

pending → processing → retry → failed

The worker atomically claims each notification before sending it, which prevents two concurrent workers from sending the same email twice.

Retryable failures are attempted up to three times with backoff.

ElevenLabs

I used ElevenLabs in both directions.

Speech-to-text: the Setup screen can record the user's voice using the browser MediaRecorder API. The audio is sent to ElevenLabs Scribe v2 and the resulting transcript is placed back into the editable interests field.

Text-to-speech: Dispatch can narrate the current Brief using ElevenLabs' timestamp-enabled TTS API.

The backend maps ElevenLabs' character-level timestamps back to the corresponding headline and summary sentences. The frontend then highlights the sentence currently being spoken.

So the audio player is not simply playing an MP3. The text follows the narration.

Why Does Open Innovation Matter?

Dispatch depends on language-model reasoning for much more than producing text.

The model has to turn unstructured human preferences into structure, reason about relevance across multiple articles, compare new evidence with an existing known state, and decide whether something represents a genuinely new development.

Using an open-weight model means that this reasoning layer does not have to be permanently tied to one closed model vendor.

The application is built around structured prompts and validated JSON outputs rather than proprietary model-specific behavior. That gives me room to change hosts, experiment with different open models, self-host where practical, and keep improving the reasoning layer without redesigning the rest of the product.

A closed API could perform many of the same individual tasks. What open innovation changes is control and portability.

The intelligence at the center of Dispatch can evolve independently of a single provider.

That matters especially for a product whose long-term value depends on improving how it decides:

Is this actually new, or is the news cycle just repeating itself?

Prize Categories

I'm entering Dispatch in the following categories:

Best Use of Render
Best Use of Backboard
Best Use of ElevenLabs
Best Use of MongoDB Atlas
Best Use of SerpApi

Best Use of Render

Render hosts the production FastAPI + React application and runs the independent hourly Cron job responsible for continuous story monitoring and notification delivery.

Best Use of Backboard

Backboard is the central model gateway for Dispatch. It powers natural-language interest parsing, personalized Brief curation, and structured meaningful-change reasoning.

Best Use of ElevenLabs

ElevenLabs powers both voice input through Scribe v2 and narrated Briefs through timestamp-aware text-to-speech, including synchronized sentence highlighting.

Best Use of MongoDB Atlas

MongoDB Atlas stores users, structured interest profiles, saved Briefs, Watches, known story state, development history, scheduling state, and the durable email-notification outbox.

Best Use of SerpApi

SerpApi provides the live news retrieval layer. Dispatch uses Google News search both for initial Brief generation and for focused rechecks of stories being actively watched.