Building A Geospatial Care-Navigation Platform For Developmental Disability Services
Project period: 2025-2026 KiNDD platform build.
Most service directories start with a search box.
KiNDD started with a different premise: for developmental disability services in California, geography is not a convenience feature. It is the structure of the system.
A family’s ZIP code determines which Regional Center serves them. That Regional Center shapes intake, service boundaries, provider relevance, and the next steps a family needs to understand. If the product treats Regional Centers like an optional filter or an insurance type, the experience is misleading before the first search result appears.
The core model became:
family location -> ZIP code -> Regional Center assignment -> relevant providers and guidance
That is the product. The map is just the most visible expression of it.
Problem Context
Families looking for developmental disability services often have to connect several fragmented systems:
- a public service geography they may not understand
- provider lists that are hard to search
- therapy types and diagnoses that do not map cleanly to everyday language
- insurance or funding constraints
- contact information, driving distance, and practical access
- bilingual support needs
The original web application was a provider map. That was useful, but it was not enough. A pin on a map does not tell a family whether that provider is relevant to their Regional Center, whether the service area matches their ZIP code, or what the next step should be.
The engineering challenge was to make geography part of the domain model, not just part of the UI.
Architecture
The public-safe architecture is simple:
The important layers are:
- User surface: web map and iOS app.
- API layer: Django and Django REST Framework for provider search, Regional Center logic, and AI endpoints.
- Geospatial layer: PostgreSQL/PostGIS for provider locations, Regional Center service areas, ZIP routing, and distance queries.
- AI layer: guided help over structured provider and Regional Center context.
The geospatial layer is the trust layer. If it is wrong, everything above it becomes less credible.
Why Regional Centers Are Not A Filter
The biggest domain mistake is treating Regional Center as a user-selected category.
That is not how the system works.
Regional Centers are geographic service areas. A family does not choose one the way they choose a provider specialty. Their location determines it.
That distinction drove several product decisions:
- ZIP code lookup became a first-class flow.
- Regional Center boundaries needed to be visible on the map.
- Provider relevance had to be tied to geography.
- Copy had to explain Regional Centers as place-based service assignment, not insurance.
- AI prompts had to preserve the same rule.
This is the kind of product invariant that belongs everywhere: database models, API responses, UI language, onboarding, and AI behavior.
What The System Needed To Do
The first-load experience had a practical job:
- Get the user’s location or ZIP code.
- Resolve the ZIP code to a Regional Center.
- Show the Regional Center service area.
- Load relevant providers for that geography.
- Preserve search and filtering for therapy type, insurance, age group, and diagnosis.
That sounds straightforward, but it forces the backend and frontend to agree on the same source of truth. If the iOS app uses nearest-point heuristics while the backend uses ZIP assignments, the product can disagree with itself. If the map renders polygons from one dataset while the API resolves providers from another, trust erodes.
The engineering direction is therefore: one authoritative service-area model, exposed consistently to every client.
Why PostGIS Matters
Early map products can get far with latitude, longitude, and Haversine distance. That eventually breaks down.
For KiNDD, PostGIS gives the platform a better foundation:
- service-area polygons can be stored and queried directly
- provider distance can be indexed and filtered
- map-ready boundary data can be served from the same source of truth
- future service-gap analysis can build on real spatial data
That last point matters. Once the product has trustworthy geography, it can do more than help one family search. It can show where access is thin, where travel burden is high, and where Regional Center catchments have service gaps.
That is the difference between a map app and infrastructure.
What Changed From Website To Platform
The commissioned website version proved the map and provider directory were useful. The platform version added the pieces needed for a public-interest product:
- a Django/PostGIS backend as the canonical data layer
- a web map for public access
- a SwiftUI iOS app for family-facing use
- bilingual support
- AI assistance over structured context
- public-source research RAG
- nonprofit and clinical stakeholder documentation
The technical work and founder work became inseparable. Every engineering decision had a governance shadow: What can the app safely claim? What data needs review? What should the AI refuse to do? What will a clinical advisor need to validate? What can a nonprofit eventually own?
Lessons
The main lesson is that maps are not neutral. In a care-navigation product, the map encodes assumptions about access, responsibility, and relevance.
For KiNDD, the correct abstraction is not “show me nearby providers.” It is closer to:
given where this family lives, what service system are they in,
what resources are relevant, and what next step is safe to suggest?
That requires a different architecture than a generic directory. It needs geospatial data, clear domain rules, careful copy, and eventually AI that is grounded in those same rules.
The map is the interface. The service geography is the product.