Good Catch

A read-only second set of eyes that finds rental listing, calendar, guest-promise, and important-date mistakes before they become expensive surprises.

Comment

Inspiration

Self-managing Airbnb and Vrbo owners juggle discounts, calendars, listing promises, amenity rules, and important local dates across disconnected tools. The expensive mistakes are often small and ordinary: a discount left on, two channels showing different availability, a holiday restriction missing from the listing, or a major local event treated like a normal stay.

Good Catch began with a simple idea: give the owner a second set of eyes and show only the few things worth checking.

What it does

Good Catch is a read-only protection service for vacation rentals. An owner sends one public listing link. Good Catch checks visible evidence and returns a short, source-backed Owner Protection Audit covering:

  • discounts and minimum-stay settings that deserve confirmation;
  • Airbnb and Vrbo calendar differences;
  • guest promises that conflict with date-specific restrictions;
  • important events and travel dates worth reviewing;
  • listing copy, photos, and recurring review themes when they reveal a supported mismatch;
  • dates and settings that already look intentional and should be left alone.

The audit costs $99. Optional monitoring at $29 per month or $290 per year turns the audit into one short weekly email: what changed, what still looks right, and the one decision—if any—that deserves five minutes.

Good Catch never asks for a password and never changes a rate, listing, calendar, or guest message. The owner sees the evidence and stays in control.

A concrete example

In one pilot-property audit, Good Catch found a six-night discount that reduced the publicly displayed stay total by $298. The finding did not claim the property was underpriced or promise revenue. It showed the visible setting, the arithmetic, and one owner decision: keep the discount intentionally or remove it intentionally.

The same audit found Airbnb appearing open while Vrbo appeared blocked for the same dates, and identified an amenity promise that needed clearer holiday wording. Just as importantly, seven important date windows already looked intentional, so Good Catch recommended nothing for them.

That is the product: the catch the owner would have missed, plus the confidence to leave everything else alone.

What existed before Build Week

Before Build Week, Good Catch existed as a local, human-in-the-loop evidence prototype under the internal project name EventSpotter. It could structure property facts, validate sources and claims, generate an Owner Protection Audit, compare monitoring receipts, and render an unsent weekly owner email.

It had no public product experience.

What we built during Build Week

The Build Week extension created the first complete owner-facing version of Good Catch:

  1. An isolated Next.js public site that cannot import private owner evidence, operator routes, or local engine files.
  2. A responsive homepage that explains the product, the audit, weekly monitoring, pricing, and trust model in plain language.
  3. Clear visual examples that separate observed findings from hypothetical outcomes.
  4. Automated checks for the public/private boundary and required homepage content.
  5. Browser-led desktop and mobile review of spacing, hierarchy, copy, overflow, and interaction.
  6. A production deployment of the public Good Catch website.

The local operator workflow remains separate and uses fictional committed fixtures. Real owner inputs stay in ignored local files.

How we built it

The product uses JavaScript, Node.js, Next.js, React, Markdown, JSON evidence receipts, and no-dependency validation scripts.

The architecture deliberately separates three surfaces:

  • public-site/: the only public deployment target;
  • the root Next.js app: a loopback-only operator workspace;
  • src/, scripts/, and data/: the local evidence, validation, audit, and monitoring engine.

The system is evidence-first. Public availability is never called a booking. A score never makes an unsupported fact publishable. Attendance, demand, pricing, revenue, sellout, proximity, amenities, and event affiliation require supporting evidence before they appear in owner-facing copy.

How Codex and GPT-5.6 helped

Codex with GPT-5.6 was the primary engineering partner for the Build Week extension.

It:

  • mapped the existing audit, monitoring, and trust boundaries before changing the architecture;
  • designed and implemented the isolated public-site boundary;
  • built the responsive owner homepage;
  • translated technical evidence receipts into plain owner language without weakening source rules;
  • added deterministic boundary and content checks;
  • ran the site locally and inspected real desktop and mobile renders;
  • iterated on composition, spacing, hierarchy, overflow, and copy;
  • reviewed the final diff and packaged the public site for deployment.

The public website does not pretend an AI is autonomously changing a rental. Codex helped build and review the product; the current owner workflow remains read-only and human-approved.

Challenges we ran into

The hardest problem was not generating more advice. It was deciding what could safely be said—and then making that evidence feel simple.

Early versions read like technical reports. They repeated caveats, surfaced too many events, and made the owner work too hard to understand the value. We learned to put the catch first, collapse the action to one decision, keep trust rules mostly invisible, and say “nothing needs your attention” when that is the honest result.

A second challenge was deployment safety. The repository contains private local workflows and ignored owner evidence, so the public site needed a checked boundary rather than a normal full-repository deployment.

Accomplishments we are proud of

  • Turning a large local prototype into a product a new owner can understand quickly.
  • Preserving owner control instead of using automation as theater.
  • Showing a specific $298 visible-setting catch without turning it into an unsupported savings claim.
  • Treating “no action needed” as a valuable result.
  • Preventing the public build from importing private operator or owner files.
  • Using Codex not only to write code, but to reason about scope, trust, product language, and visual quality.

What we learned

Events are a reason to look, not the whole product. Owners do not want another event newsletter or pricing dashboard. They want to know:

What am I missing, what should I check, and what can I safely leave alone?

The strongest product promise became: a second set of eyes for your vacation rental.

What's next

The next validation gate is deliberately human: put the $99 audit in front of self-managing owners who do not know the builder, measure whether they act on a supported finding, and learn whether they want the weekly protection email afterward.

Only after that proof will we consider deeper integrations for calendar, listing, pricing, or email data. The product will remain read-only unless owners clearly ask for something more.

Built With

Share this project:

Updates