Public product
Bathroom Buddy
Production restroom discovery across mobile, web, data quality, and operations
A cross-platform product for finding public restrooms with map search, community-maintained details, ratings, reports, and accessibility preferences. The challenge is not merely placing points on a map; it is keeping information useful, reviewable, and safe as it changes.
Project outcomes
What changed in the work.
- iOS + Android
- public app releases
- Map + community
- discovery and feedback loops
- Refresh + review
- location data lifecycle
- Role
- Hands-on engineering across mobile, web, backend, data workflows, and release readiness
- Scope
- product · mobile · frontend · backend · architecture · data · etl · testing · security · sre
- Status
- Public product
Product walkthrough
A few screens from a public product
The app is designed around a fast, informed decision: start quickly, find what is nearby, and filter for the practical details that matter before walking inside.
Screen 01
Start with the decision, not an account wall
A clear entry point for exploring, finding, or contributing without burying the useful path.
1 / 3
The problem
Start with the constraint.
Restroom information is often incomplete, stale, or hard to use when someone needs it. The product needs to support fast map discovery while treating crowdsourced and provider-sourced data as information that must be refreshed, moderated, and reviewed.
What I contributed
- Implemented across the mobile, web, backend, data-workflow, and release surfaces.
- Built product capabilities around search, location detail, community feedback, and accessible-use preferences.
- Contributed data freshness, moderation, test, and operational safeguards without exposing private implementation details.
Sanitized architecture
A public product surface is separated from application services and restricted operations tooling so discovery, data quality, and review can evolve without making internal controls public.
Mobile and web
Map discovery, preferences, community feedback, and product flows.
Application services
API boundaries for product behavior, identity, validation, and domain workflows.
Data lifecycle
Location refresh, normalization, matching, change detection, and review queues.
Operations
Restricted tools for moderation, corrections, audit, release, and investigation.
Engineering decisions
Context, choice, and tradeoff.
Treat location data as a lifecycle, not a one-time import
Context: Provider records and community information can change, disagree, or become stale.
Options: Overwrite records blindly, or retain provider identity and compare incoming changes before publishing them.
Decision: Normalize provider identity, track refresh history, score candidates, detect changes, and route uncertain changes to review.
Tradeoff: This adds workflow and storage complexity, but prevents freshness from becoming an invisible source of product risk.
Result: A controlled refresh and review path that supports data quality without claiming that every record is automatically correct.
Make safety checks assist moderation instead of replacing it
Context: Community reports and reviews make the product better but also introduce quality and safety concerns.
Options: Publish everything immediately, or block all contribution behind manual review.
Decision: Use deterministic checks and asynchronous moderation workflows, with operations tooling for review and correction.
Tradeoff: The system requires careful operational ownership, but avoids treating automated judgment as the final authority.
Result: Useful community contribution with a defined route for follow-up and accountability.
Keep public discovery and restricted operations separate
Context: Moderation, audits, and incident investigation have different access needs from a customer-facing map experience.
Options: Combine product and operations flows, or create distinct boundaries for each audience.
Decision: Use separate public product surfaces and restricted operational workflows.
Tradeoff: More surface area to maintain, balanced by clearer ownership boundaries and lower accidental exposure risk.
Result: A product that can grow community data while preserving room for moderation and operational stewardship.
Quality & operations
How the work is made operable.
- Automated and integration test suites cover application and workflow behavior.
- Location refresh and moderation workflows make data quality an operational concern, not only a schema concern.
- Release safeguards and telemetry are treated as part of shipping a public product.
Lessons
What carries forward.
- Data quality is a product feature when users need information in the moment.
- Responsible automation needs a clear escalation and review path.
- A credible product story includes how it is operated, not only how it looks.
Want to discuss the technical decision-making behind this work?
Contact Kyle