Home
Nefe Tech LTD
d e v

I built an app to help Elderly and Disabled people in my neighbourhood

Mayuresh Smita Suresh

Mayuresh Smita Suresh

@mayu2008

February 28, 2026 7 min read 28 4
I built an app to help Elderly and Disabled people in my neighbourhood

This is a submission for the DEV Weekend Challenge: Community

My grandmother couldn't change a lightbulb, neither can take her dog on walk and I live 200 miles away, I cant be there every time.

Not because she was frail. Not because she lacked the will. But at 78, with arthritic hands and a second-floor flat with no elevator, climbing a stepladder to reach a ceiling fixture was genuinely dangerous. She lived alone. My family was two cities away. And she sat in a dim room for six days before she finally asked her neighbor — a stranger she'd shared a building with for three years — for help.

Six days in a dim room. Because she didn't know if it was okay to ask.

That's the problem NearbyHelp is built to solve. Not emergencies. Not disasters. The quiet, grinding, invisible difficulty of daily life for millions of elderly and disabled people who need small help — and have no idea who around them is willing to give it.

The Community

The community I built for is one that rarely gets built for: elderly individuals, disabled people, and anyone who lives alone and needs occasional help with day-to-day tasks that most of us take for granted.

We're talking about:

  • An 80-year-old who needs someone to carry a heavy box down from a shelf
  • A person with MS who needs a neighbor to pick up their prescription on the way back from the shops
  • A visually impaired resident who needs help navigating a council form online
  • Someone post-surgery who just needs their groceries picked up once

These aren't crises. There's no ambulance to call. There's no app for this. There's just... the hope that someone nearby is kind enough, and that you're brave enough to ask.

The second part of that equation — the willingness of neighbors to help — already exists in abundance. What's missing is the infrastructure to make that willingness visible. Right now, the goodwill is there. It's just invisible.

NearbyHelp makes it visible.

What I Built

NearbyHelp is a community-first web application where local volunteers register specific tasks they're willing to help with — and anyone nearby can open a map, see exactly who's available, how far away they are, and call them directly.

The philosophy is deliberate simplicity: one volunteer, one skill offer, one pin on the map.

No social network. No messaging layer. No karma points. Just a live map of willing neighbors, searchable by task type, sorted by distance.

Core Features

** Live Interactive Map**
Built on react-leaflet, the map shows every registered volunteer as a color-coded pin based on their task category. Tap a pin, see their name, what they can help with, and a direct call button. That's it. Designed specifically to be usable by elderly people on tablets — large tap targets, high contrast, no clutter.

** Haversine Proximity Sorting**
Every volunteer's distance from your location is calculated in real time using the Haversine formula — the same spherical geometry used in aviation navigation. It's not "roughly in your area." It's "0.4 km away." That specificity matters when you're deciding whether to ask someone for help.

** AI Skill Categorization (Google Gemini)**
Volunteers type what they can help with in plain English: "I can help move furniture and do heavy lifting" or "happy to help with tech stuff, phones, tablets, computers." Google's Gemini AI reads their natural language and maps it to a standardized tag: MAINTENANCE, TECH_HELP, ERRANDS, HOUSEWORK, TRANSPORT, COMPANIONSHIP. This means the map filter works reliably regardless of how different people describe the same task.

** One-Tap Direct Call**
Volunteers who opt in share a contact number. The app generates a native tel: link — on mobile, one tap opens the phone dialer. No messaging, no waiting for a reply. Direct human contact, immediately.

** Mobile-First List View**
A swipeable overlay on mobile showing volunteers as cards sorted nearest-first. Built specifically because many of the people looking for help are elderly tablet users who find maps cognitively harder to parse.

** Secure by Default**
Strict Row Level Security (RLS) in Supabase PostgreSQL. Users can only edit their own profiles. Volunteer visibility is opt-in. No one's location is stored with more precision than they choose to provide.

Demo

🔴 Live App: https://nearbyhelp.vercel.app

Sign in with Google, allow location access, and you'll see the map immediately populated with volunteers nearby. Use the filter panel to narrow by task type. On mobile, swipe up for the list view.

Screenshots:

The main map: color-coded pins by task category, live distance shown on each popup

screenshot 1
screenshot 2
screenshot 3

Code

Github code

How I Built It

The Stack

Every technology choice was made with two users in mind simultaneously: the volunteer (typically a younger, tech-comfortable neighbor) and the person seeking help (often elderly, on a tablet, with limited tech confidence). The stack had to be fast to ship, reliable in production, and genuinely accessible.

Next.js 14 (App Router)
React Server Components for near-instant page loads. The map page is a protected route — unauthenticated users are redirected cleanly. API routes handle the Gemini integration server-side so API keys never touch the client.

Supabase — the backbone of the whole thing
Supabase does three jobs here that would have taken three separate services otherwise:

  1. Authentication — Google OAuth, one provider, zero friction. First sign-in auto-creates a profile row via a PostgreSQL trigger. No separate user management.
  2. Database — PostgreSQL with a custom get_nearby_profiles function that does bounding-box pre-filtering before Haversine calculation, keeping queries fast even at scale.
  3. Row Level Security — Users can only update their own rows. Volunteer contact info is only exposed if they've explicitly opted in. Security is enforced at the database layer, not just the application layer.

The Supabase database trigger that auto-creates a profile on first Google login was one of the most satisfying pieces to build:

CREATE OR REPLACE FUNCTION public.handle_new_user()
RETURNS TRIGGER AS $$
BEGIN
  INSERT INTO public.profiles (id, display_name, avatar_url)
  VALUES (
    NEW.id,
    NEW.raw_user_meta_data->>'full_name',
    NEW.raw_user_meta_data->>'avatar_url'
  );
  RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

CREATE TRIGGER on_auth_user_created
  AFTER INSERT ON auth.users
  FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();
Enter fullscreen mode Exit fullscreen mode

Zero onboarding friction. Sign in, you exist in the database. Done.

The Haversine Formula
I implemented Haversine in pure TypeScript rather than relying on a library. I wanted to understand every line of the distance logic, and it's satisfying code to read:

export function haversineDistance(
  lat1: number, lng1: number,
  lat2: number, lng2: number
): number {
  const R = 6371 // Earth's radius in km
  const dLat = toRad(lat2 - lat1)
  const dLng = toRad(lng2 - lng1)

  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(toRad(lat1)) *
    Math.cos(toRad(lat2)) *
    Math.sin(dLng / 2) ** 2

  return R * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a))
}
Enter fullscreen mode Exit fullscreen mode

Every volunteer card on the map shows their distance to two decimal places. 0.4 km away. That specificity was important to me — vague proximity ("nearby") doesn't give someone the confidence to reach out. Exact distance does.

Google Gemini AI — the quiet magic
The AI feature is invisible to users, which is exactly how it should be. Volunteers type naturally. Gemini reads it and returns a standardized category. Here's the API route:

// app/api/categorize/route.ts
const TASK_TAGS = [
  'ERRANDS', 'HOUSEWORK', 'MAINTENANCE',
  'TECH_HELP', 'TRANSPORT', 'COMPANIONSHIP', 'OTHER'
]

const prompt = `
  You are a community volunteer task categorizer.
  Given this offer: '${skillText}'
  Return ONLY one tag from: ${TASK_TAGS.join(', ')}
  No explanation. Just the tag.
`
Enter fullscreen mode Exit fullscreen mode

The constraint of returning only one tag from a fixed enum was deliberate. I don't want AI creativity here — I want consistency. Every "I can drive you to appointments" maps to TRANSPORT. Every "I'm good with computers" maps to TECH_HELP. The map filter relies on this being reliable.

react-leaflet + Custom Pins
No Google Maps API key required. Leaflet is open source, fast, and renders beautifully on mobile. Custom SVG pins are color-coded by task category so you can read the map at a glance without reading any text — important for elderly users who may have reduced vision.

Tailwind CSS v4
Glassmorphism-inspired UI with high contrast ratios throughout. WCAG AA compliance was a design constraint, not an afterthought. Every interactive element has a minimum 44×44px tap target for accessibility.

The Architecture Decision I'm Most Proud Of

I chose to put the Haversine calculation in JavaScript rather than SQL, but the pre-filtering (bounding box) in a Supabase PostgreSQL function. This means:

  1. The database returns a small, geographically bounded set of profiles (fast)
  2. JavaScript sorts them by exact spherical distance (precise)
  3. The client renders cards in perfect nearest-first order (useful)

It's a clean separation: database does what databases are good at (filtering large datasets quickly), JavaScript does what it's good at (precise calculation on a small set).

What Was Hard

The mobile list view took longer than I expected. The UX challenge was real: elderly users navigating a swipeable overlay need smooth momentum scrolling, large text, and clear visual hierarchy. I went through four iterations before the swipe gesture felt natural enough that I'd be comfortable handing a tablet to my grandmother.

The other challenge was the Supabase RLS policies. Getting the policies right — where anyone can read volunteer profiles, but only the authenticated owner can write to theirs, and contact info is only exposed with explicit opt-in — required careful thinking. I've documented the full policy setup in the repo README for anyone who wants to fork it.

Why This Community. Why Now.

By 2030, 1 in 6 people in the world will be over 60. In many cities, over 30% of elderly people report feeling lonely. The infrastructure of community that used to exist — knowing your neighbors, looking out for each other — has eroded in modern urban life.

The solution isn't a government program or an expensive subscription service. It's already living three doors down from you. It's your neighbor who said "let me know if you ever need anything" and meant it — but never got the call because nobody had a way to make asking feel natural and safe.

NearbyHelp is that way.

It's not built for crisis. It's built for Tuesday afternoon when the jar won't open and there's nobody to call.

Built with Next.js 14, Supabase, Google Gemini AI, react-leaflet, and Tailwind CSS v4.

Live at https://nearbyhelp.vercel.app

Share this article:
View on Dev.to
Back to Blog

Related Articles

Continue exploring more tech content