CASE STUDY · DEPENDENCY REPLACEMENT
Tutorliy: Replace the location-search dependency, keep the matching system.
Tutorliy
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.
The problem
Tutorliy already had a tutor-search journey: a person chose a location, and the platform used coordinates to find tutors within a radius. The location picker relied on Google-backed autocomplete. The matching behind it was a different responsibility.
I started by separating those two pieces. Choosing a place name was the part that needed a new provider. Finding tutors using the selected coordinates was already handled by MongoDB, and there was no good reason to disturb that working logic.
The constraint
The existing MongoDB geospatial query path was part of the live matching flow. Replacing it would have widened a relatively focused task into a riskier migration.
I kept the coordinate handoff between autocomplete and matching as the boundary. The new search path still needed to give the matcher usable coordinates, while the radius rules and tutor data stayed where they were.
The decision
I chose a Bangladesh-focused, self-hosted autocomplete path using OpenStreetMap data and SQLite FTS5. The frontend would ask our own API for location suggestions instead of relying on the previous external service.
There is maintenance work in owning a local search index, but it is a more contained responsibility than owning an entirely new matching engine. The new provider could change without forcing a change to the way tutors were found.
What I implemented
The implementation was deliberately split into search data, an autocomplete API, the UI handoff and the existing geospatial matcher.
Prepared Bangladesh location data from OpenStreetMap for a local text-search index.
Used SQLite with FTS5 to support location-name lookup and autocomplete suggestions.
Connected the location selector to a first-party API that supplies coordinates to the search flow.
Kept the existing MongoDB radius-search responsibility and 2dsphere geospatial behavior intact.
Limited the change to the dependency boundary rather than rebuilding the whole tutor-search product.
Rechecked location selection and radius-based tutor results together after deployment.
How I verified it
A working autocomplete response was not enough. I checked that a user could select a result from the new path and still reach tutor results through the existing radius logic.
That distinction is important: the change needed to work all the way through the product, not only at the new API endpoint. I have not attached made-up latency, cost or search-quality numbers to that verification.
What stayed unchanged
The MongoDB geospatial matching layer, tutor coordinates and existing radius-query responsibility were preserved. The external location-search dependency above them was replaced.
Keeping that boundary stable reduced the number of moving parts and meant the release could be checked against known tutor-search behavior.
What this project demonstrates
I like this example because it was not about introducing another fashionable stack. It was about knowing what not to rewrite.
I removed a dependency where it belonged and left the proven matching work alone. On an existing product, that kind of restraint often matters more than the size of the diff.
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.
Related case studies
See all
