Before You Build
Web AppShut Down

Cita Madre

Cita Madre helped users monitor Mexican consular appointment availability. The product reached real users quickly, but depended on external appointment systems whose operators may not share incentives with third-party automation.

View original story

Product snapshot

What it was

An appointment-finding helper for people trying to find Mexican Consulate appointments.

Who it was for

people seeking Mexican Consulate appointments

Problem / value

Reduce the pain and search effort involved in finding available consulate appointments.

Core workflow

Users monitored or discovered available consulate appointments and reduced the effort required to navigate a painful appointment-finding process.

Core dependency

Founder-public stopped-maintenance note tied to hostile-platform/process risk and delayed paid validation.

Product form

web appscraping-based utility

Pricing model

Pre-revenue; the founder said payments were added too late to validate monetary demand.

Competitors or alternatives

official MiConsulado / citas.sre.gob.mx appointment systemmanual appointment checkingWhatsApp or phone appointment workflows where availablescraping-based appointment monitors

What happened

Summary

The founder created Cita Madre to improve the process of finding appointments at Mexican Consulates.

Outcome

Founder-public stopped-maintenance note tied to hostile-platform/process risk and delayed paid validation.

Core risk

Hostile Platform Dependency

Timeline

  • Founder reported going from idea to real users in around one month.
  • Founder reported over 1000 visitors, 19 mailing list subscribers, and stopping work on December 2, 2023.

Before you build

Why it matters

Scraping-based and appointment-monitoring utilities are common indie projects. This case shows why builders must validate cooperation, durability, and paid demand before committing to a utility around a controlled external process.

Primary check

Validate official-system access, notification reliability, and willingness to pay before monetizing an appointment-search helper.

Checklist

  • Can you name the first buyer segment and the repeated job they need solved?
  • Can you reach that segment without relying on one fragile channel?
  • What happens if the platform, API, or data source changes terms or blocks access?
  • What evidence would disprove the hostile platform dependency risk?
  • Before building on an external process, ask whether the process owner benefits from your product existing.
  • Validate paid demand as early as possible when free traffic appears.
  • Separate evidence of user pain from evidence that the operating environment will allow a sustainable product.

Relevant if

  • You are building a similar web app with public-source distribution risk.
  • Your product depends on another platform, search channel, API, or third-party data source.
  • You need to validate who will repeatedly pay before investing in product polish.

Less relevant if

  • You already control a reliable acquisition channel for the exact buyer segment.
  • The product is an internal tool with no need for public distribution.

Pre-build tests

  • Run a landing-page or concierge test with the narrowest buyer segment before building the full workflow.
  • Ask users to commit to a paid pilot, not only to join a free waitlist.
  • Prototype the highest-risk platform or data dependency first and document backup options.

Transferable lessons

  • Before building on an external process, ask whether the process owner benefits from your product existing.
  • Validate paid demand as early as possible when free traffic appears.
  • Separate evidence of user pain from evidence that the operating environment will allow a sustainable product.