Habitat — Bird’s geospatial operating system

Bird expanded extremely quickly. Every city had different pricing, currencies, regulations, vehicle capabilities, operational rules, geofences, parking policies, speed limits, products, and experiments.

Hardcoding those behaviors wasn’t sustainable. Every market launch required engineering work. Every pricing change required deployments. Every new feature required code changes.

That model simply couldn’t scale. Instead, we asked a different question: what if every aspect of the business became configurable?

The original version of Habitat was intentionally simple. Zones contained configuration. Configurations inherited through geographic hierarchy: Country → City → Neighborhood → Area. Lower-level zones overrode higher-level zones.

Given a GPS coordinate, Habitat would resolve every matching geographic region and merge the resulting configuration into a single response. PostGIS performed the geospatial lookup while JSON configuration merged according to geographic precedence.

Simple. Fast. Highly effective — until Bird kept growing.

The next challenge wasn’t performance. It was duplication. Cities shared pricing. Countries shared currencies. Vehicle types shared speed limits. Copying configuration everywhere quickly became unmanageable.

Instead of embedding configuration directly inside zones, I introduced reusable configuration objects attached to one or more geographic regions. Configuration became normalized. Schemas described configurable attributes. Keys described metadata and validation. Configurations became reusable building blocks.

Changing a single configuration could instantly update hundreds of markets simultaneously.

Eventually location alone wasn’t enough. The same location could behave differently depending on vehicle model, mobile platform, day of week, time of day, weather, and operational state.

Habitat introduced request context. Every configuration attachment could now include rules determining whether it should apply — only Bird One scooters, weekdays after 7 PM, iOS only, Android only.

Configuration became conditional instead of static.

Once configuration became contextual, A/B testing became a natural extension. Product managers could define experiments directly inside Habitat.

Each experiment contained enrollment rules, traffic allocation, experiment groups, and configuration overrides.

Rather than deploying separate code paths, products could be launched gradually, measured, and iterated entirely through configuration.

As Bird expanded globally, geographic lookup became one of the platform’s biggest challenges. City boundaries became increasingly detailed. Governments required exact polygon definitions. Approximation wasn’t acceptable.

PostGIS performed well — until it didn’t. Solving that problem was a collaborative effort. I worked with systems engineers and architects—including Chan Nguyen and several other engineers—to move beyond the PostGIS-and-Redis approach and design an in-memory RTree index.

Behind the scenes, we also used Uber’s H3 and Google’s S2 to quickly map coordinates to geographic sectors. In our benchmarks, our RTree implementation outperformed both while preserving the exact polygon resolution the platform required.

The improvement was dramatic.

Eventually database performance stopped being the bottleneck. Reading configuration was.

To support thousands of requests per second, Habitat transitioned from database-backed lookups to immutable configuration snapshots. Workers periodically generated complete snapshots of all active configuration, published them to S3, and coordinated rollout through ZooKeeper.

Each service loaded the newest snapshot into in-memory caches before atomically switching traffic. Configuration updates became effectively instantaneous while maintaining consistency across the cluster.

This is probably my favorite evolution. Originally Habitat exposed configuration keys. That worked well for engineers — not for Product Managers.

Prat Kapur led the conceptualization and productization of Habitat’s transformation from configuration management into a product-launch platform. His product framing helped turn the underlying technical capabilities into a system that Product and Operations teams could understand and use directly.

So we moved one level higher. Instead of configuring keys, Product Managers configured products. Products contained features. Features contained settings. Settings automatically generated the appropriate configuration UI based on metadata.

Engineers defined capabilities. Product Managers launched products. Operations configured markets. Everyone worked inside the same platform using terminology appropriate to their role.

Habitat eventually became the central control plane for Bird. It controlled pricing, geofences, slow-speed zones, no-ride zones, vehicle capabilities, firmware behavior, feature flags, experiments, product rollouts, emergency shutdowns, market launches, and the rider experience.

Every scooter continuously asked Habitat the same fundamental question: given everything I know about this request… how should I behave?

It wasn’t configuration. It was policy.

Habitat taught me one of the most valuable lessons of my career. At first glance, it appeared to be a configuration service. In reality, it became something much larger — a policy engine.

Every decision about how a scooter should behave — from pricing and speed limits to experiments, product rollouts, and emergency operational changes — flowed through the same underlying platform.

Looking back, I realize Habitat wasn’t managing configuration. It was managing intent. It allowed engineers to build capabilities once, while enabling Product Managers and Operations teams to continuously evolve business behavior without writing new code.

That’s the kind of platform that quietly disappears into the background — until you realize the business can’t operate without it.