Doorstep: A Local AI Walking App Designed for People with Limited Mobility

Most apps that push you to "get outside" share an unspoken assumption: the thing stopping you is a lack of motivation. But an open-source app called Doorstep starts from the exact opposite premise — what if you genuinely want to go out, and the real constraint is your body?

Built for the Hacktoberfest Open Source AI Challenge (Week 1: Touch Grass), this project uses a locally-run open-source model, Gemma 3 4B, to completely rethink what "walking recommendations" should mean.

A Problem Every Similar App Ignores

Before writing a single line of code, the developer read through roughly ninety other submissions to the challenge: task generators, trail guides, birdsong recognition apps, leaf-peeping route planners, apps that lock your phone to force you outside…

Every single one assumed the same thing: the obstacle is insufficient motivation.

Not one was designed for people who desperately want to go out but can't — someone three weeks post-surgery, someone whose knees decide each morning how far they'll get, or an eighty-year-old who can make it to the corner and back, and on some days, not even that.

Doorstep asked a question no one else had asked:

How far can you walk today?

This isn't a goal. It's a ceiling. Some days that number is smaller, and that's okay.

Once it has today's number, the app finds every place genuinely within that range, then asks a locally-running open-source model to pick exactly one worth visiting. Here's what the interface looks like:

How far can you walk today?  [=====o----------------]  200 metres

   Balbhim Mandir (temple)
   138 metres · has seating · has shade
   "Most of the route is shaded, and there's somewhere to sit at the end."

Afterward, it asks just one more question: Did you go? The entire loop is that simple. No step counts, no pace, no calories, no streak counters.

Privacy Is the First Principle

Doorstep holds two things about you: how far your body can manage today, and the precise point from which those distances are measured. Together, they amount to a medical record with a home address attached.

This even created a problem for the demo. The app shows place names rather than coordinates — "temple 130 metres away," "café at the end of the road." Even with no numbers on screen, a screenshot taken at the developer's actual home would narrow down his location to within a few streets.

So the demo was run in a public park in a city where the developer doesn't live, with a few days of history manually seeded so the dashboard wouldn't be blank. The app is real, the OpenStreetMap data is real, every sentence Gemma wrote is real — the only thing that's fabricated is the address.

As the developer put it: "A tool that asks for your home address should be able to demo itself without revealing its author's home address."

Ollama is a tool that lets users run open-source large language models on their local computer — no cloud API, no account required, with model weights stored directly on the user's own drive. Gemma 3 4B is a small open-source language model released by Google with roughly 4 billion parameters; it can run on the CPU of an ordinary consumer laptop at speeds fast enough for real-time interaction. Together, these two components mean all of Doorstep's AI inference happens locally on the user's device. While the app is running, it makes no outbound network requests except for the initial download of OSM map data. For an app holding a sensitive combination of data like "reachable distance + precise starting point," local inference isn't a performance optimization — it's the foundation of the privacy architecture. With no server, there's no data to leak or to be compelled to hand over.

Core Architecture: Distance Is Arithmetic, Not a Model Judgment

Doorstep runs Gemma 3 4B locally via Ollama. Neighborhood data from OpenStreetMap is downloaded once. The tech stack is just Node and a single HTML page, with the daemon bound to the local loopback address.

The One Rule That Actually Matters

The design principle the developer kept coming back to: the model decides which place to pick, but never decides how far.

Every location is filtered at the code level against today's reachable range before it ever reaches the model:

const eligible = places.filter((p) => p.metres <= reach);

By the time Gemma sees the list, every option on it is already safe. The worst it can do is pick a boring one.

This isn't about keeping the architecture clean. For this user group, a language model that enthusiastically recommends "just a little further" is equivalent to an app that strands someone two streets from home with nowhere to sit. Distance is the one thing in this product that can't be left to judgment — it must be handled by arithmetic. If the model returns a location that isn't on the list, it's treated as a hallucination rather than a suggestion, and the app falls back to the nearest place with seating.

When There's Genuinely Nowhere to Go

There are no mapped locations within 100 metres of you today.

This is because map data here is sparse — not because of you.

The app won't quietly expand the radius to manufacture a result, and it won't invent a bench. For this user group, a fictional destination is worse than no answer at all — because they will actually walk there.

The Same Code Is a Different App in Different Cities

One of the most insightful parts of the project came when the developer pulled map data for two Indian cities roughly 300 km apart:

	Smaller city	Larger city
Places within 1200m	28	701
Benches	0	24
Tagged trees	3	566
Anything within 200m	None	3

Same code, same radius, same query. In the larger city, Doorstep has temples, cafés, and five hundred tagged trees to choose from. In the smaller city, it can only say "there's nothing within your range" — not because the streets are empty, but because OpenStreetMap doesn't know they exist.

The developer's first instinct was "India has no mapped benches." A second data pull proved that wrong. The real answer is more interesting: OSM is volunteer-annotated, so the street furniture layer reflects where the contributors live, not where the benches are. For an app that promises "somewhere to sit within 200 metres," this means the places with the sparsest data are exactly the places least likely to have had an app built specifically for them.

As a result, the list of what counts as a destination looks nothing like what you'd write staring at a map of Europe. In India, temples and shrines (shaded, quiet, with seating), parks, markets, and corner shops are widely tagged; benches, drinking fountains, and individual street trees are almost never mapped. When a bench exists, it's the best answer. When one doesn't, a temple courtyard at seven in the morning is a real destination — and it's on the map.

OpenStreetMap (OSM) is an open geographic database maintained by volunteers worldwide — essentially the Wikipedia of maps. Anyone can add roads, buildings, benches, drinking fountains, and other features for their own neighborhood. The Overpass API is OSM's query interface, letting developers retrieve map features by geographic area and tag type — for example, "fetch all nodes tagged amenity=bench within a 200-metre radius of a given coordinate." OSM data quality correlates directly with the number of active contributors in a given area. Cities in Europe and North America tend to have detailed street furniture annotations, while other regions may have just as many benches but remain invisible in the database because no one has ever uploaded their coordinates. This structural bias means the practical usability of OSM-based applications is geographically uneven in ways that often hurt the places that need them most.

A Near-Catastrophic Bug That Almost Shipped

Map data comes from Overpass — a free, volunteer-run service — so the developer wrote a loop to try multiple mirrors. The first version destructured the response like this:

({ elements = [] } = await r.json());

That default value is a trap. A mirror that returns HTTP 200 with no data produces an empty array, and an empty array is truthy — so it gets treated as success. Doorstep would then silently save a blank map.

The real-world consequence for users: the app tells someone there's nowhere to go within range of their home. That's the most discouraging thing this app could possibly say, caused entirely by a = [].

After the fix, a "200 but no elements" response is treated as a mirror failure and the next one is tried. As a side note: kumi.systems returns 500, overpass.osm.ch returns HTML with a 200 status, and only overpass-api.de actually delivers.

Deliberately No Streak Counter

Streaks punish bad days. But here, a bad day isn't a failure of willpower — it's a physical condition being endured. A streak counter tells someone whose body "took a week off" that they've broken something.

So Doorstep tracks the number of days you went out in a month (a hard week doesn't erase them), and the average reachable distance on the days you did go — the days you didn't go are never factored in. The model is also explicitly instructed: never mention distance, pace, progress, "try harder," or reflect someone's health condition back at them. It's told to write like "a friend who noticed something" — not a coach.

The streak mechanic is ubiquitous in fitness and habit apps, rooted in the behavioral psychology concept of loss aversion — breaking a streak feels worse than starting from zero, which drives users to maintain a behavior. Duolingo, Fitbit, Apple Fitness, and most mainstream apps rely on this mechanism to boost retention. But for people with chronic illness, post-surgical recovery, or age-related limitations, this design causes systematic harm: when "not going out" is a necessary physical rest rather than a failure of will, a streak counter resetting adds psychological burden and may even push users to go out when their body isn't ready. Doorstep replaces the streak with a monthly day count, so every outing is recorded and no absence generates a penalty signal.

Why Open-Source Innovation Matters Here

The developer gives three reasons, and the first alone is decisive.

1. This is health data, and it's tied to your home address. An app that knows you walked 150 metres today and 400 metres yesterday is tracking whether your body is getting better or worse — and it also knows the precise starting point of every measurement, because it has to. A medical record with a slider, combined with a home address, in the same file. The developer admits that the instinct of "I don't want to expose both of these numbers together even for a hackathon" was exactly the argument for keeping everything local. Once set up, Doorstep has no network calls to audit — because there are no network calls.

2. It has to work with the signal turned off. The map is downloaded once. After that, it runs in a basement flat, on a prepaid SIM that's run out, in an alley with no coverage. A closed-source API makes the most critical moment — a person standing at their front door deciding whether to venture out — dependent on a network connection.

3. Every answer costs nothing. A service that charges per request is a service a retired person will turn off.

There's one more reason the developer didn't anticipate: building on a small local model forced him to move all distance logic entirely out of the model — because he couldn't trust a 4B model with numbers where getting it wrong could hurt someone. A frontier API might have been convincing enough to let him hand the decision over to the model entirely, resulting in a more dangerous product. The absence of an escape hatch led to a safer design.

A Small Model Doing Exactly What It Should

Gemma 3 4B does exactly one thing here that it's actually good at: reading a short list of real places and saying which one is worth visiting today, while every decision that could cause harm stays in the code. It runs on a laptop CPU — which is precisely why an app holding someone's mobility record can stay on their own machine.

Doorstep's value isn't in technical complexity. It's in thinking deeply enough about who it's for. It's a reminder that the real ethics of AI products are often found in the decisions about what you choose not to let the model do.