Projects  ›  CleanStop

CleanStop

Community Restroom Status Utility

I designed and built a mobile-first restroom-status app that keeps unreviewed community updates separate from the information shown publicly.

Functional Alpha Offline — Pending Redeployment
CleanStop restroom-status application interface

Status

Functional Alpha

Project Start

May 8, 2026

Main Development

May–June 2026

Page Updated

August 2026

Overview

CleanStop began with a simple frustration: when someone needs a restroom, ordinary map listings show that a business exists but rarely answer whether the restroom is usable right now. Cleanliness, supplies, privacy, access, and the age of the latest information matter more in that moment than a long review of the business itself.

The project developed into a static, mobile-friendly alpha focused on short practical status rather than public comments or social features. It can operate locally through browser storage and can also use Supabase for shared report intake, place suggestions, and feedback.

The trust model is central to the product. A submitted report can be acknowledged immediately for the person who sent it, but it does not automatically change what everyone else sees. Pending and rejected reports remain private. The public interface reads approved summarized status.

How It Started

On May 8, 2026, I described a very simple app for people who need a restroom and want to know whether it is clean, stocked, and private enough to use. Stores and gas stations were the immediate context.

The first idea included community ratings and short comments, but the product direction changed as the trust problem became clearer. A completely open review feed would make the app vulnerable to stale information, abuse, and unverified claims. The alpha therefore separates contribution from publication.

Naming work explored several directions before CleanStop became the public name. The internal project record still uses Restroom App in places, but both refer to the same project.

Where can I find a nearby restroom that is usable right now, and how can that information remain current without becoming an unmoderated review feed?

Architecture

Public Interface

The user-facing application supports a small set of fast actions:

  • review candidate restroom status;
  • open a place detail view;
  • submit a structured update;
  • suggest a location;
  • provide product feedback.

The public interface shows approved summarized information rather than database or moderation details.

Local UX Layer

The application can run without a backend. Browser storage preserves pending acknowledgement, form continuity, quick-edit behavior, cooldown messaging, and fallback sample data. This made the product testable before shared infrastructure was required.

Private Intake Layer

When Supabase is configured, reports enter a private queue as pending. Place suggestions and feedback also remain private intake. A submission can be received without immediately changing public status.

Approved Public Data Layer

Approved reports feed summarized public status. Raw report history, pending and rejected submissions, anonymous session identifiers, reviewer notes, and moderation details remain internal.

Deployment Layer

The prototype includes a deployable static package and was previously deployed for private testing. It was taken offline after inactivity before a public launch and is now pending redeployment, security review, and final public testing.

Development Timeline

May 8, 2026

Concept origin

The app began as a simple clean-restroom finder prompted by uncertainty at stores and gas stations.

May 8–14, 2026

Product definition

Naming, cold-start coverage, moderation risk, place data, launch strategy, and possible future business tools were explored.

June 2026

Functional alpha

The static mobile interface, candidate and detail views, structured reports, local fallback behavior, and centralized copy were implemented.

June 2026

Supabase and trust architecture

Database schema, private report intake, place suggestions, feedback, public summarized status, row-level access planning, and manual review helpers were created.

June 2026

Private deployment preparation and testing

A deployable package was prepared and the Supabase-backed alpha was placed online for private testing.

Current phase

Redeployment and public launch preparation

The prior private deployment is offline. The remaining work is to review security and permissions, refresh candidate coverage, complete visual QA, redeploy, and begin a controlled public launch.

Results and Current Boundaries

Working alpha interface

The project provides the full basic user path from reviewing a candidate location to submitting a structured update.

Trust model implemented

The application separates pending private intake from approved public status instead of allowing every submission to overwrite what users see.

Deployable system prepared

The front end, schema, migrations, moderation helpers, documentation, and deployment package exist as a coherent alpha rather than disconnected mockups.

Current boundary

CleanStop is not currently live and has not been publicly launched. The alpha does not yet guarantee location coverage, restroom access, accessibility compliance, real-time discovery, automated trust scoring, or complete abuse protection. Those limits are part of the reason the next release should remain controlled.

Behind the Build

CleanStop is a product and trust-design project as much as it is an app. The important work was deciding what people need to know quickly, what should remain private, and how reports should move through review.

What I built

A responsive static web app with location cards, practical restroom-status fields, structured reports, local fallback behavior, and an optional Supabase intake path for privately reviewing submissions before they affect public status.

The key idea

A new report should not immediately overwrite what everyone sees. CleanStop keeps pending local or submitted information separate from approved public information, which reduces the risk of abuse and misleading updates.

Selected technical detail

Keeping pending reports out of public status

function getPublicReport(candidate) {
  return state.publicReports[candidate.id] || candidate.report;
}

function getPendingLocalReport(candidateId) {
  return state.pendingReports[candidateId] || null;
}

These two lookups keep the public view and the user’s pending update distinct. The interface can acknowledge a report without presenting it to everyone as approved information.

Evidence to show on the page

These are the strongest visual proof points for a recruiter or technical reviewer. The image and video URLs can be inserted after the Squarespace asset list is finalized.

Mobile interface
Mobile interface
The location list and restroom-detail experience on a phone.
Report flow
Report flow
The structured update form and pending-review message.
Trust model
Trust model
A simple diagram showing private intake, review, and approved public status.
What I confirmed

I reopened the local build and confirmed that the main files still load together, the forms are present, the public and pending data paths remain separate, and the app can operate without a live database. I have not yet completed a fresh phone-and-desktop walkthrough or reconnected the Supabase deployment.

How AI helped

I used AI to help shape the interface, write and revise the front-end code, think through database structure, and identify moderation and privacy risks. I defined the problem, narrowed the alpha, reviewed the behavior, and decided which features were useful now and which would create unnecessary risk or complexity.

Selected code and development records are shown for context. Additional source files are available for technical review on request.