I led the rebuild of a mutual-aid app for an Israeli community-help operator. People post a request (a ride to hospital, a lost dog, a wheelchair for a week) and nearby neighbors who opted in get alerted, then reply by chat, WhatsApp, SMS or a call. The new version replaced a legacy app in the same store listings, kept its users and data, and decides in one database query who should hear about each request.
The operator already had an app with real users and years of requests in a MySQL database. It was hard to extend: it had no groups, no in-app chat and no per-user alert settings, so alerts could only be narrowed in coarse ways. The brief was to rebuild the backend and the app without losing a single user, and to let every person choose exactly which requests should wake their phone: which categories, which keywords, how far away, which cities and which hours.
The diagram is wider than the screen: swipe sideways to see all of it →
The app also talks to the chat service directly through its SDK, using a user token the API issues. Images go to object storage and only their URLs are kept in SQL. Login is by phone number and one-time SMS code. Blocked users are turned away by a server status code that the app maps to an “access denied” screen.
Category, keyword, distance and city rules compile into one LINQ query. Distance uses a SQL Haversine function mapped into EF Core, and the effective radius is the smaller of the reader's range and the request's own radius. No user list is loaded into memory just to throw most of it away. Trade-off: a scalar distance function can't use an index, which is fine at this scale. A spatial index is the next step if the user base grows a lot.
Every matched user gets an inbox row, even without a valid device token, so nothing is lost after reinstalling or turning notifications back on. Push goes only to users outside their quiet hours, and quiet hours can cross midnight (22:00–06:00). Trade-off: more rows in the notifications table, so the inbox is paged (10 per page).
Creating a request saves it and puts it on a queue. A hosted background worker then picks the audience, writes the inbox and sends one batched push request. The person posting doesn't wait for hundreds of phones. Trade-off: the queue is in-process, so items waiting during a restart can be lost. A separate worker host is already scaffolded for moving it out.
Instead of extending the old MySQL app, the data went through a staging database with bulk copy. Then a T-SQL script with a @DRY_RUN switch, guard checks and duplicate handling moved it into the new schema. The new app shipped under the old store identities, so existing installs simply updated. Trade-off: a second schema and a one-off tool to maintain until cut-over.
Taken from the commit history of both repositories. A selection:
Most endpoints only read data, but EF Core was tracking every entity it loaded.
Made no-tracking the default for the whole context, and opted in to tracking only in the update paths. Also removed includes that weren't needed from the posts query.
The legacy database had requests with free-form times, reports with duplicates, a separate location table, and users identified only by phone.
Built a two-step migration: bulk copy from MySQL into a staging schema, then a T-SQL mapper with overflow-safe times, report de-duplication, guard THROWs on missing reference data, and a dry-run mode that reports counts and rolls back.
The first version sent notifications inside the create-post call, so posting got slower as the audience grew.
Turned off sending inside the call and added a queue with a hosted worker. Device tokens are refreshed on login, and only users with valid tokens get a push.
Posts in private groups could show up in the feeds of people who weren't members.
Filtered feeds and notifications by group membership, added an explicit “public post in a group” option, and closed other access gaps found in the posts API during a security pass in Feb 2026.
The location and quiet-hours filters disagreed with what users had set, and a request's own radius was ignored.
The effective radius is now min(reader range, request radius), and the quiet-hours check handles ranges that cross midnight.
Targeting relied on the location saved in the profile, which goes stale for people who move around.
The app sends the current location on open and every 5 minutes, and skips refreshing the home feed when the location hasn't changed. Users can also follow several cities.
With Hebrew and Arabic as first-class languages, some third-party components ignored the layout direction (the slider, the places autocomplete, the chat header on iOS).
Forced the direction through the i18n layer, patched the places input with patch-package, upgraded the slider library, and went through RTL alignment screen by screen.
Several requests failing with an expired token at once each tried to refresh it, and blocked users could get stuck in a loading state.
The Axios interceptor now shares one in-flight refresh between all callers. Blocked users get a dedicated status code that takes them to an “access denied” screen.
Shipping as a new store listing would have meant asking every existing user to install it again.
Moved the iOS and Android configuration to the legacy app's existing package identities and aligned version codes, so stores accept it as an update.
A small replay of the targeting rules with six made-up neighbors. No client code or data. Change the request and see who gets an inbox entry, who gets a push, and why the others don't.
Free scoping call · 30 minutes · No commitment
Write a few lines: the process or system, what hurts today (time, errors, cost or an AI pilot that stalled) and who uses it. After a short call you get a written plan and a fixed quote within ≈3 days.
Opens a pre-filled email · reply within one business day
The model reads. The code counts.
All projects