Dockly
An installable map for bike parking that riders can actually trust.
Overview
Dockly came from a gap I kept noticing in existing maps: they could tell you where you were, but not whether a bike spot would actually work when you arrived. I built it as a PWA to see how far a modern web stack could go for geospatial discovery, offline access, and field-friendly contribution flows.
The Problem
Bike parking is a confidence problem. Riders need more than a pin on a map - they need to know rack type, coverage, capacity, and whether the information is recent enough to trust. That made the engineering challenge twofold: keep map interactions fast on mobile, and make submissions quick enough that people would contribute while standing next to a rack.
Key Decisions
- I chose a PWA over native apps because installability, location access, and offline support were enough for the use case, and the web kept iteration cheaper.
- I centered the app around the map from the first render, then treated search, filters, and contribution as supporting flows rather than separate destinations.
- I used Firebase to keep auth, realtime updates, and asset storage lightweight for a project that needed fast backend setup more than custom infrastructure.
- I kept client state lean with Zustand and deferred heavier UI so the map could become interactive quickly on mobile.
- I designed the submission flow for on-the-street usage: minimal typing, quick metadata capture, and photos as proof.
Technical Highlights
Geospatial Rendering at Scale
The main constraint was map responsiveness on mobile. Marker clustering, zoom-aware grouping, and careful tap target sizing let the map stay useful without turning into a noisy cloud of points.
PWA Architecture
The product only worked if it felt dependable away from perfect connectivity. I treated installability, service worker behavior, and cached station data as core functionality rather than progressive enhancement. The install prompt is delayed until users have enough intent for it to feel helpful.
Performance Optimization
I kept the client state model intentionally small. Zustand handled UI state without pulling in a heavier abstraction, and route/code splitting plus lazy UI loading kept time-to-interactive centered on the map rather than the chrome around it.
Community Contribution Model
Contribution quality depends on reducing friction without inviting junk data. The flow uses GPS, quick metadata selection, and photos as proof so submissions can happen in the field, then passes entries through a lightweight moderation layer before publishing.
Tech Stack
Tradeoffs & Next Steps
- Google Maps sped up delivery, but it also tied a meaningful part of the experience to third-party APIs, pricing, and rendering conventions.
- Offline Google Maps support is not realistically available in the browser, which means true offline map behavior would likely require a native direction rather than continued PWA iteration alone.
- If I return to the product, I would invest next in trust signals and moderation tooling before adding more discovery features.
Outcome
Dockly proved that a web stack can deliver a credible field-use map product if performance and offline behavior are built in early. It deepened my experience with geospatial UI, service worker edge cases, and contribution systems that balance speed with data quality.