DEV Community: Benedicta

Little Outside: An AI Vocabulary Coach That Starts With Going Outside

Benedicta — Mon, 12 Oct 2026 05:46:56 +0000

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

What I Built

I built Little Outside, a small AI-powered progressive web app designed to help people spend less time staring at a screen and pay more attention to the physical world around them.

The idea came from a fairly simple observation that there are already plenty of apps that can tell us to take a break, go for a walk, be present, or spend less time online.

I didn't want to build another app that asked people to spend more time on a screen in order to learn how to spend less time on one.

Instead, Little Outside starts by giving you a reason to leave the screen.

You choose the kind of experience you want, and the app gives you a small real-world mission.

It could be something as simple as looking for an interesting texture, noticing something you've never paid attention to on your usual route, or finding a detail in your surroundings that tells you something about the place you're in. Then you put the phone away.

Little Outside asks you to describe what you noticed. Its vocabulary coach then helps you find a more precise word for that observation.
For example, you might come back and write:

There were so many things packed together in the shop that everything looked scattered.

Instead of simply giving you a definition from a dictionary, the vocabulary coach can suggest a word such as cluttered, explain why that word fits your observation, and then ask you to rewrite your original thought using the new word.

That creates the loop i wanted:
Choose → Explore → Notice → Reflect → Discover a word → Rewrite → Save

The vocabulary is therefore not a separate flashcard exercise.

The real world comes first. The vocabulary comes from what you actually noticed.

Demo

Live Demo: https://little-outside.onrender.com

The core flow is:

Choose a mission.
Go outside and complete it.
Record what you noticed.
Ask the vocabulary coach to help you find a better word.
Rewrite your observation.
Save the completed adventure to your journal.

Demo video:

Code

GitHub Repository:

BenedictaUche / little-outside

Little Outside

A small app for getting off your screen, paying attention to the world around you, and finding better words for what you notice.

Built for the DEV Hacktoberfest 2026 “Touch Grass” challenge.

Why Little Outside?

It is surprisingly easy to spend an entire day looking at a screen without really noticing what is happening around you. Little Outside gives you a reason to step away.

Instead of telling you to "go outside and relax," it gives you a small, specific adventure to try. You might be asked to notice five different sounds, find something that has changed with age, or take a short walk and pay attention to the things you normally pass by.

The fun part is finding the right words for what you experienced.

How it works

Choose what you want
        ↓
Get a small outdoor mission
        ↓
Go outside
        ↓
Write about what you noticed

…

View on GitHub

The project is built as an open-source Next.js application. The repository contains the application code, local mission and vocabulary data, AI integration, PWA configuration, and the persistence layer used for the journal.

How I Built It

I built Little Outside with Next.js, TypeScript, Tailwind CSS, Serwist, and IndexedDB.

There are two important architectural decisions behind the project.

The real-world missions don't depend on AI. I deliberately kept the mission system local and deterministic. When a user starts an adventure, the app can generate an appropriate mission from its local mission data instead of asking an AI model to invent one every time.

That matters because the most important part of the application is not the AI. It is getting the user outside. The AI should enhance that experience rather than become a dependency for every part of it.

Gemma handles the vocabulary coaching The AI portion of the application uses Google's Gemma open-weight model, accessed through OpenRouter.

The request flow looks roughly like this:

User reflection
      ↓
Mission page
      ↓
/api/vocabulary
      ↓
Vocabulary service
      ↓
Gemma via OpenRouter
      ↓
Structured vocabulary response
      ↓
Word + definition + explanation + example + rewrite prompt

The browser never talks directly to OpenRouter. The API key remains on the server, and the application validates the model response before passing it back to the client. The vocabulary response is structured around the actual reflection rather than being a generic word of the day.

The model is asked to provide:

a useful word for the observation
its meaning
why it fits the user's description
an example
a prompt for rewriting the original observation

How the AI fits in

I used Google's Gemma through OpenRouter to help users find more precise words for things they notice outside. When a user submits an observation, the app sends it to a server-side API route, which handles the vocabulary request.

I also wanted the experience to remain useful when the AI provider or network is unavailable, so the app includes a local vocabulary fallback.

Local fallback

I also didn't want a temporary network or AI failure to completely destroy the experience. The vocabulary system has a curated local dataset that can be used when the online AI provider is unavailable.
The application also keeps the missions and journal experience local.

Completed adventures are persisted using IndexedDB, which means the journal isn't dependent on a remote database just to remember what the user has done. This is because the goal of the application is to encourage people to disconnect from the internet for a while.

It would be slightly ironic if the app itself became unusable the moment the connection disappeared.

Progressive Web App

Little Outside is also configured as a PWA using Serwist.
The application has a web app manifest, application icons, and a service worker setup so that it can behave more like an installable application.
The local mission data, vocabulary fallback, and journal persistence are particularly important here because they give the application useful behavior beyond simply loading a webpage.

Why Does Open Innovation Matter?

For Little Outside, using an open-weight model matters because i didn't want the AI component to become the entire product.
The core experience belongs to the application:

the missions
the reflection flow
the vocabulary structure
the local fallback
the journal
the PWA experience

Gemma is one component inside that system.

Using an open-weight model also gives the vocabulary layer a replaceable boundary. The application doesn't have to be designed around one permanently closed AI provider.

The provider is separated from the rest of the vocabulary logic, which means the application can change how the model is served without having to redesign the entire user experience.
More importantly, open models make it possible to think about applications where AI is small, specific, and useful, rather than putting a chatbot in front of every problem.

Prize Categories

Best Use of Gemma
Little Outside uses Google Gemma as the vocabulary coach at the heart of its reflection experience. It receives the user's real-world observation and helps turn that observation into a more precise piece of writing.
Best Use of Render
Little Outside is deployed using Render, which hosts the production Next.js application and its server-side AI API routes.

Check it out

If you'd like to try Little Outside or see how it was built:

Live app: https://little-outside.onrender.com
GitHub: https://github.com/BenedictaUche/little-outside

I Built a Food Research Tool for My Friend. She Told Me She Wouldn't Use It.

Benedicta — Mon, 05 Oct 2026 06:42:05 +0000

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

What I Built

I built Gastronomical, an AI-powered research and content creation tool for food creators. I built it for my friend, Amasco, who creates food content mainly through carousels.

Her workflow usually starts with a basic idea. Maybe she wants to make a post about chili recipes or desserts without added sugar. She starts with a research of finding recipes, comparing different versions, checking measurements and serving sizes, finding the right images, and eventually turning everything into a carousel. Since she doesn't have a content manager, she has to do all of this herself.

I thought i could solve that by building a better research tool.

My first version was basically a research dashboard. It searched for sources and images and used AI to analyze what it found. Technically, it worked. Then i showed it to my friend, and she told me she wasn't going to read through all of that. That was useful feedback.

She wanted the actual recipes, measurements, serving sizes, useful comparisons, relevant images, and something that could help her get to a finished carousel faster. So i changed the product around her actual workflow.

Now, Gastronomical takes a food idea, finds relevant recipes and sources, extracts the useful information, and turns the research into creator-ready content and a carousel.

The goal is to do less research and more creating.

Demo

The live application is available here: Gastronomical

I also recorded a short demo showing the complete workflow from searching for a food topic to generating a carousel:

The most important part of the demo is the actual creator workflow. I wanted to show that Gastronomical isn't just an AI research interface. The point is to go from a food idea to usable content with as little repetitive work as possible.

Code

There are a few parts of the codebase that I found particularly interesting:

Searching the web with SerpApi

Gastronomical uses SerpApi for Google Search and Google Images. I wanted the application to work with current web information rather than asking an AI model to rely entirely on what it already knows. The search results become the evidence that the rest of the research pipeline works from.

Extracting recipes

When Gastronomical finds a recipe page, it first looks for structured recipe data such as JSON-LD. That gives me access to information such as ingredients, instructions, cooking time, and yield when the website provides it. If that structured data isn't available, the application falls back to extracting useful page content.

One important rule is that Gastronomical does not turn incomplete information into a complete recipe. If a source doesn't provide a measurement, the application doesn't invent one. If a page isn't actually a recipe, it remains a source rather than being presented as one.

Giving the AI structured output

Once the research has been collected, it is passed to Qwen through OpenRouter. Instead of asking the model for one large block of text, i ask it for structured information:

`{
  "summary": "...",
  "commonIngredients": [],
  "differences": [],
  "techniques": [],
  "observations": []
}`

That makes the output much easier for the application to work with and keeps the AI layer separate from the presentation layer.

How I Built It

The basic architecture looks like this:

The frontend is built with Next.js, React, TypeScript, and Tailwind CSS.

When a creator searches for a food topic, the application sends the request to the research API. SerpApi handles the Google Search and Google Images requests, and the returned pages are normalized into a common structure.

For recipe pages, i prioritize structured recipe data before falling back to page content. This is important because I want the application to preserve what the source actually says rather than having an AI model reconstruct a recipe from a vague snippet.

The collected evidence is then passed to Qwen, an open-weight model accessed through OpenRouter.

The AI is instructed to work only with the supplied sources. It should not invent ingredients, measurements, techniques, or cultural information that aren't supported by the research.

One of the design decisions I made was to keep AI-generated content separate from visual design.

The model generates the information for the carousel, but React controls how the carousel looks. The slides use a fixed 1080 × 1350 format, with the food image covering the slide and the content layered over it.

I then use html-to-image to turn the rendered carousel into downloadable PNGs.

That means i can completely change the visual design without changing the AI generation logic.

Deploying with Render

I deployed Gastronomical with Render so i could test it as an actual production application rather than only running it locally.

The deployed application connects the frontend to the same research and AI workflow, with API credentials kept in environment variables rather than exposed in the client.

Render made it possible to get the application online quickly without spending the hackathon building infrastructure instead of the product.

Monitoring with Sentry

Gastronomical also depends on several external services. A search request can fail, a recipe page can be unavailable, or an AI provider can return an error. I added Sentry so i can see what happens in production when something goes wrong.

That is particularly useful for a product like this because an external service failing shouldn't simply look to the creator like the app doesn't work.

Why Does Open Innovation Matter?

Gastronomical isn't built around the idea that one AI model should know everything about food.

The application retrieves information from the web first, then gives that evidence to an open-weight model to reason over. That separation gives me much more flexibility. I can change the model without rebuilding the rest of the application, and i can control what information the model is allowed to use.

It also makes experimentation possible. If another open model performs better at recipe comparison or content generation, i can test it against the same research pipeline instead of rebuilding the product around a proprietary model.

For this project, open innovation is what makes the AI layer replaceable and gives me control over how the product uses AI.

Prize Categories

Best Use of SerpApi: SerpApi powers the live web and image research used to ground Gastronomical's AI workflow.

Best Use of Render: Render hosts the deployed production application.

Best Use of Sentry Agent Tracing

Try Gastronomical

Live Demo

Source Code

Demo Video

Building this for my friend reminded me that the person using the product doesn't care how interesting the technology is if it gives them more work.

My first version was built around what i thought was interesting. The second version was built around what she actually needed.

That's my biggest takeaway from building for a friend.