HoodHop: Designing Confidence Before Commitment
I took a community-product idea from market evidence to product strategy, interaction rules and a working cross-platform MVP—using AI to extend execution, not replace judgement.
Discovery was not the unit of value. Trusted participation was.
People could already find events. HoodHop had to help them evaluate, commit, participate and return without forcing small hosts into a heavy operating system.
The event detail experience had to answer “Can I trust this?” before asking “Will you join?”
- 01
Trust before RSVPMove host, attendee and event-state signals ahead of commitment.
- 02
RSVP is a state modelRepresent interest, requests, confirmation, waitlists and check-in.
- 03
Communities outlive eventsKeep persistent Hoods separate from temporary events.
The gap appeared after discovery: “Is this worth my time, and what happens after?”
Public reviews and product comparisons repeatedly surfaced trust, unclear commitment, host effort and fragmented continuity. The product therefore needed one coherent loop rather than another feed of listings.
Three market patterns changed the product architecture.
Listings did not provide enough confidence
Host credibility, attendee context, activity and event state needed to appear before the primary action.
“Going” hid operationally different states
Interest, approval, capacity, waitlists and attendance needed distinct behaviour.
One-off event pages lost community memory
A persistent Hood needed to hold identity, discussion and repeat events beyond one date.
Evidence boundary: these are secondary-research patterns, not claims from HoodHop participants. Primary user and host validation is still required.
Evidence became three product rules, each with a trade-off.
People needed to judge credibility and activity before committing.
Put host, attendees, event state and social intent above the RSVP action.
A denser detail page, but fewer unanswered questions at the decision point.
Interest, approval, capacity and attendance meant different things.
Model Interested, Requested, Confirmed, Waitlisted and Checked In as explicit states.
More state logic, but clearer capacity and user expectations.
Temporary listings could not preserve community continuity.
Separate the persistent Hood from each time-bound event.
A larger information architecture, but a product that can support return behaviour.
Lightweight first-time creation · one predictable host plan · Android + responsive web before native iOS
The working product turns those rules into visible states.
Sunday City Walk24 people · Hosted by Maya
Designers’ Coffee12 people · Active hood
Sunday City Walk
Maya hosts City Explorers18 events · 4.8 rating
One action, clear state changes
- InterestedSaved privately
- RequestedWaiting for host
- ConfirmedYour place is held
- Checked inParticipation recorded
Start with the essentials
Advanced host controls appear after publish.City Explorers
Walks, local stories and slow Sundays.
Reconstructed UI states based on the working product. Approved production screenshots can replace these without changing the story.
I did not ask AI to “make an app.” I directed a product loop.
Research
Separate facts, review signals and interpretation.
Decide
Turn evidence into scope, rules and trade-offs.
Specify
Define states, data, edges and acceptance criteria.
Build + verify
Inspect behaviour, permissions, responsive layout and regressions.
Delivered capability is separated from evidence still to collect.
A functional cross-platform MVP
Android and responsive-web surfaces connect discovery, evaluation, joining, creation and return.
From listings to trusted participation
I defined the multi-state commitment model, persistent Hood architecture and staged host-creation experience.
A repeatable prompt-to-state loop
Research decisions travelled with interaction rules, implementation constraints and continuous QA.
After launch I would measure: join completion, first-event publish time, interested-to-confirmed movement, and repeat participation in the same Hood.
Primary validation and verified post-launch product metrics are not yet available.
Three lessons from directing an AI-assisted 0→1 build.
Behaviour beats prompt length: specific constraints produced better work than larger instructions.
Vague decisions create vague output: AI made weak product reasoning visible quickly.
Next time: keep a decision log from day one and conduct primary host conversations earlier.
Depth for the interview conversation.
Research method and integrity
I compared official product pages, pricing, public reviews and adjacent tools. Facts, review complaints and my interpretation stayed separate. Public signals informed hypotheses; they did not become claims about HoodHop users.
Prompt architecture
Research prompts decomposed trust, hosting, pricing, reliability and continuity. Implementation prompts carried screen intent, state rules, edge cases, responsive behaviour and acceptance criteria. QA prompts started with reproduction and the smallest safe correction.
Scope and monetisation choices
I kept participation free, used one predictable host-plan direction and deferred direct messaging, full native ticketing, advanced analytics, multiple pricing tiers and native iOS until the core participation loop could be validated.