Project Name
City Expansion as a Configuration Task: GeoJSON Polygon Service Zone Engine for a North American Childcare Marketplace
A childcare marketplace expanding city by city across North America had made every new market launch an engineering project. Adding a service zone meant a developer updating hardcoded bounding-box coordinate logic, running tests, and deploying a new application build, a process that took days and pulled engineering capacity away from the product roadmap. Zip-code lists were inconsistent at city edges, bounding boxes misrouted addresses near irregular metro boundaries, and addresses outside coverage were not rejected cleanly at the point of entry. They propagated into the booking flow and required manual ops intervention to clear. Ksolves replaced the entire coordinate-matching approach with a GeoJSON polygon engine backed by RGeo, giving the ops team direct control over service boundaries without touching a single line of code.
- Bounding Boxes Producing Incorrect Routing: Rectangular coordinate boundaries could not accurately represent irregular city service zones. Addresses near metro boundaries were routed to the wrong market or failed silently, requiring manual correction by the ops team after the fact.
- Every New City Required an Engineering Ticket: Adding a new service zone meant a developer updating hardcoded coordinate logic, running tests, and deploying a new application build, a process that took days and created an unnecessary engineering dependency for what should have been a business decision.
- Zip-Code Lists Unmanageable at Scale: The initial approach of whitelisting zip codes as proxies for service zones was inconsistent across city edges, required frequent maintenance as postal boundaries changed, and could not handle partial coverage of a zip code area.
- Out-of-Coverage Addresses Reaching Operations: Addresses outside service boundaries were not rejected cleanly at the point of entry. They propagated into the booking flow, creating incomplete jobs that required manual ops intervention to cancel and communicate back to the parent.
- No Ops-Visible Boundary Management Tool: There was no interface for the operations team to view, audit, or adjust service boundaries. Every coverage question required checking in with engineering, adding friction and slowing market-specific decisions.
Ksolves designed and implemented a polygon-based geospatial service zone engine using RGeo for spatial containment logic and GeoJSON as the boundary definition format, replacing coordinate-based proximity checks with precise, ops-editable polygon containment. The governing principle was that service zone management should be a configuration operation, not a deployment operation.
- GeoJSON Polygon Boundary Definition: Each service zone is defined as a GeoJSON polygon, an arbitrarily shaped geographic boundary that accurately represents the actual operational footprint of a city market, including concave boundaries, exclusion zones, and metro areas that do not follow rectangular coordinates.
- RGeo Spatial Containment Engine: Point-in-polygon containment checks using the RGeo library determine in milliseconds whether a submitted address falls within any active service zone, replacing the bounding-box and zip-code approaches entirely.
- Ops-Editable Boundary Management: Service zone polygons are stored as database records rather than hardcoded values, enabling the ops team to add, modify, or deactivate a city boundary through an admin interface with no engineering ticket required and no application deployment needed.
- Clean Rejection at Point of Entry: Addresses outside all active service zones are now rejected with a clear user-facing message before they enter the booking flow, eliminating the downstream ops noise caused by out-of-coverage jobs reaching the queue.
- Multi-Zone Routing for Boundary Addresses: Addresses that fall within multiple overlapping zones are resolved by a priority-ordered zone assignment rule, preventing ambiguous routing at shared metro boundaries without manual intervention.
Technology Stack
| Category | Technology |
|---|---|
| Spatial Engine | RGeo |
| Boundary Format | GeoJSON |
| Database | PostgreSQL |
| Admin Interface | ReactJS |
- City Expansion Decoupled from Engineering: The ops team can now draw and activate a new service zone polygon through the admin interface with zero engineering involvement, reducing new city launch time from a multi-day engineering cycle to a same-day configuration task.
- Zero Out-of-Coverage Addresses Reaching the Job Queue: Clean rejection at point of entry means no out-of-coverage addresses propagate into the booking flow. Ops no longer handles invalid bookings created by addresses that should have been rejected before entering the system.
- Exact Boundary Enforcement Across All Metro Shapes: Polygon containment provides precise boundary enforcement regardless of metro shape, eliminating the systematic misrouting at irregular city edges that bounding-box logic could not handle.
- Zone Maintenance Removed from the Engineering Backlog: GeoJSON polygon definitions require no postal-boundary tracking. When coverage changes, ops updates the polygon directly, removing a recurring source of developer tickets that had no business reason to involve engineering.
Ksolves delivers geospatial backend engineering and web development services for marketplace platforms that need precise, ops-manageable service zone infrastructure to support geographic expansion without engineering dependency.
Before this engagement, every new city the marketplace entered required an engineering sprint, a deployment, and days of lead time. After Ksolves built the GeoJSON polygon service zone engine, city expansion became a configuration task completed by the ops team in minutes, out-of-coverage bookings were eliminated at the point of entry, and the engineering team’s roadmap capacity was returned to product development.
The polygon engine and ops boundary management pattern built here are directly replicable across any geographically-bounded marketplace where service zones are defined by operational territory rather than postal boundaries.
Is City Expansion an Engineering Sprint on Your Platform When It Should Be a Business Decision?
