A useful map leaves
room for correction.

A pin is not permission.

While living in Manila during COVID, I found it difficult to distinguish designated smoking areas from places mentioned by word of mouth. I no longer smoke, but the information problem stayed with me: a confident-looking map can hide a very uncertain claim.

iYosi is an informational guide to designated and community-reported smoking areas in Metro Manila. Its purpose is to make the information current and correctable while supporting smoke-free rules and shared air. The map must distinguish a reviewed designated area from a report that people happen to smoke somewhere.

Keep different kinds
of evidence separate.

I separated place type from advisory status, and evidence review from community confirmation. A rating describes someone’s experience. A confirmation says whether a place or access route is still there. Neither turns a place into a verified designated area; that requires evidence review.

Browsing is anonymous after the adult-access prompt. Accounts are required for contributions. Location is requested only when a person chooses Near me, and browsing and search work without it. A separate public entrance pin can make directions more useful without confusing the entrance with the actual area.

Two clients.
One shared contract.

The shared API supports the map, place details, proposals, confirmations, reviews, reports, and account requests. It includes a PostGIS data model, an OpenAPI contract, and an internal moderation console. Proposed places remain pending until an administrator reviews and publishes them.

The Android prototype used Kotlin and Jetpack Compose; the iOS client uses SwiftUI and MapKit. Both distinguish review dates from community observations, make status visible, and send contributions to the same API. Shapes and text accompany map colors. Directions are constrained by the record’s status rather than offered indiscriminately.

Make the correction path
as real as the map.

The API repository includes contract and integration tests, an operations runbook, and a record of implemented backend behavior. The iOS delivery notes record a simulator build and launch against an isolated synthetic demo API with four fictional pins and local address suggestions.

The redesigned landing site makes the product’s priorities visible: “Find the place. Check the status.” An illustrative neighborhood leads into an app preview where visitors can switch between a designated area and a community report. Labels, shapes, and wording change together, with the evidence status, latest check, and access note kept prominent. The preview uses fictional sample places; it is not a directory of verified locations. Likewise, a successful simulator run is evidence of a working client, not evidence of public adoption or a completed launch. Keeping those distinctions visible is part of the product’s own standard.

Working prototypes.
No viable business.

iYosi had made substantial progress, with working prototype apps, a shared API, and a landing design. I stopped before turning that work into a finalized product.

The obstacle was commercial viability. Regulatory constraints and the difficulty of finding a workable way to monetize the idea meant I couldn’t see a viable business around it.

There is no finished product to use and no release planned. The implementation remains part of the project’s history.

This record preserves the questions and choices behind that work. The landing design uses fictional sample places; it is not a directory of verified locations.