AN MVP I DESIGNED, BUILT & TOOK TO MARKET
My other case studies show how I work inside large teams. This one shows what happens with no team at all. Poopetrator is a dog-waste reporting product for apartment complexes and HOAs, and I took it from an empty repository to a pilot-ready product on my own: research, product decisions, UX and visual design, the working application, and the marketing site that sells it.
Yes, the name is a joke. The product isn't. The interesting part of this project is less any single screen than the decisions about what not to build so that a real property could start using it.
THE PROBLEM
Complaints arrive by email, in a resident Facebook group, or as a note at the office. They're late, they're vague, and they rarely reach whoever actually cleans up. There's no record to show the board, and residents who never hear back simply stop reporting.
That gave the MVP a clear job: turn a vague complaint into a pin, a photo, and a person on it, and close the loop so the resident knows it was handled.
THE RESIDENT EXPERIENCE
The resident is a passer-by holding a leash. Every field is a reason to give up, so the design question for each step was “can we remove this?” There's no app to download and no account to create. GPS is captured as soon as the page opens, and the photo and note are both optional.
MANAGERS, BOARDS & VENDORS
The manager dashboard is designed for speed of triage: a live map and a compact list, a persistent status filter, and a detail panel that is a sidebar on desktop and a bottom sheet on a phone. Status changes appear instantly, before the server confirms them.
Grounds vendors get a link, not a login: the exact location, the photo, directions, and one tap to mark the job done. Managers choose instant alerts, a daily digest, or alerts only past a threshold, and every change is recorded in an audit trail.
WHAT I BUILT, AND WHAT I DELIBERATELY DIDN'T
An MVP isn't a smaller version of the finished product. It's the least you can build to learn whether anyone wants it. I held every feature to the same test: does a pilot property need this in order to say yes? If not, it waited, however good an idea it was.
Leaving analytics out wasn't an oversight. It was the first item on the list for after the pilot, once there's real behaviour worth measuring.
THE BOARD REPORT
Residents use the product, but the property manager pays for it and has to justify it to an HOA board. So the board report got real design attention: pick a date range and print. It shows totals, the share resolved within 24 hours, median time to resolve, reports per week, the top problem areas, and who handled what. It's the reason to buy, designed as carefully as the reason to use.
// sample data — demo property
THINKING PAST THE FIRST USE CASE
Once the core loop worked, it was clear that “resident pins a problem, manager sends someone” isn't only about dog waste. Broken lights, overflowing bins and damaged fences follow the same pattern. Rather than fork the product, I made the brand a skin: Poopetrator and FixItPin run from the same app and database, and the web address decides which one you see.
Each property chooses which kinds of issue residents can report. With a single category, the interface never mentions categories at all. Even the language adapts: a resolved report reads “Cleaned up” or “Fixed” depending on what it was.
HOW IT WAS BUILT & LAUNCHED
I designed most of this in the browser rather than in Figma, because a GPS fix, a slow cell connection and a phone camera behave in ways a mock-up can't show. I also built the marketing site, with its free 60-day pilot offer and pilot sign-up page, and set up deployment for both.
INSTRUMENTING THE PILOT
With pilot properties using it, analytics moves from “not yet” to the top of the list. These are the questions I'd instrument first: