Tutorliy: Replace the location-search dependency, keep the matching system.

Tutorliy

Tutorliy location search interface

Tutorliy’s tutor-search flow relied on Google-backed location autocomplete, while the matching logic underneath already worked through MongoDB geospatial radius queries. I replaced the autocomplete dependency without rebuilding the matching engine.

OpenStreetMapSQLite + FTS5MongoDB

The problem

Tutor search needed a different location-autocomplete path. The visible search dependency and the downstream tutor-matching logic were connected in the product flow, but they were not the same technical problem.

The constraint

The existing MongoDB geospatial matcher already handled radius-based tutor discovery. Rewriting it would have expanded the change surface without solving the dependency that needed to be removed.

The decision

Separate location search from tutor matching. Replace the external autocomplete layer, then keep the production radius engine intact and verify that the two still worked together.

What I implemented

The replacement path used Bangladesh OpenStreetMap data, SQLite FTS5 and a first-party autocomplete API.

  • Step 1

    Imported Bangladesh location data from OpenStreetMap into SQLite.

  • Step 2

    Used FTS5 for the local search/autocomplete path.

  • Step 3

    Connected the tutor-search selector to the local API.

  • Step 4

    Kept the existing MongoDB $near + 2dsphere radius-matching path unchanged.

How I verified it

After deployment, I checked the replacement flow in the production path and re-ran radius-based tutor searches against known listings. The location-search dependency changed; the matching behavior underneath remained the existing MongoDB path.

What stayed unchanged

Tutor coordinates and the MongoDB geospatial radius-matching engine were intentionally preserved. The project was a focused dependency replacement, not a rewrite of working matching logic.

What this project demonstrates

A migration does not need to become a rebuild. When the boundary is clear, the safer move can be to replace one dependency, preserve the proven subsystem around it, and verify the interaction between the two.

Have a dependency that needs replacing without a full rewrite?

Send the current system, the dependency you want to remove and the behavior that must stay intact.