Inspiration
When an accommodation does not match its listing, reporting the problem can feel almost as frustrating as the problem itself. Travelers are often asked for confirmation numbers, categories, evidence, and repeated explanations before anyone understands what happened.
We wanted to reverse that experience. FixMyStay begins with a simple conversation: tell us what went wrong. The platform organizes the details, asks useful follow-up questions, and only requests booking verification after identifying a potential issue.
What It Does
FixMyStay is a conversation-first support platform for travelers experiencing accommodation problems.
Travelers begin by choosing Talk or Chat. A guided assistant asks focused questions about:
- What happened
- Where it happened
- When it began
- What the listing promised
- What outcome would make the situation right
The conversation is transformed into an editable case summary. FixMyStay searches for relevant public information that may corroborate the report. These results are treated as supporting signals—not automatic proof—and remain subject to human review.
Only after a potential issue has been identified does the traveler verify their booking. They can then review the complete report before opening a trackable case.
FixMyStay also includes:
- A traveler dashboard with case progress and notification preferences
- An operations queue showing priorities, deadlines, ownership, and next actions
- A secure response page for accommodation providers
- Stay22 partner links for travelers who may need alternative accommodation
Instead of requiring providers to create another account, FixMyStay sends them a secure, case-specific link. They can acknowledge the issue, request more information, provide evidence, or propose a resolution.
How We Built It
We built the frontend with React, JavaScript, and Vite, creating a responsive interface for desktop and mobile devices.
The application is deployed on Vercel. Evidence searches are routed through a server-side Vercel Function so the Tavily API key is never exposed in the browser. The function validates requests, handles provider errors and timeouts, and returns a clearly labeled fallback when live evidence search is unavailable.
We used:
- Tavily for public evidence discovery
- Stay22 for alternative accommodation links
- Lucide React for interface icons
- GitHub for version control
- Vercel for hosting and serverless functions
The current prototype simulates voice transcription, booking verification, notifications, and provider submissions while demonstrating the complete end-to-end workflow.
Challenges We Faced
One of our biggest challenges was deciding when to request booking information. Asking for it at the beginning created the same form-heavy experience we wanted to improve. Moving verification until after the conversation made the process feel more natural while preserving trust.
Another challenge was presenting external evidence responsibly. Search results can support a report, but they do not automatically prove that every claim is correct. We designed the workflow around corroboration, transparent confidence signals, and human review.
We also had to secure the Tavily integration. The original approach risked exposing the API key in the browser and could silently replace errors with demo data. We moved the integration to a server-side function, added validation and error handling, and made fallback behavior visible to users.
Finally, we needed to connect three different experiences—the traveler, the operations team, and the accommodation provider—without turning the prototype into three separate products.
What We Learned
We learned that trust depends heavily on the order in which information is requested. Listening first and verifying later creates a much better traveler experience.
We also learned that an effective support workflow needs more than an AI conversation. It requires structured information, clear ownership, deadlines, human judgment, and understandable updates for everyone involved.
For the provider side, we found that a lightweight secure response link is more practical for an MVP than requiring every property to create and manage another account.
What We’re Proud Of
We created a complete workflow covering:
- Conversation-first issue intake
- Guided voice and chat reporting
- Structured case creation
- Public evidence discovery
- Delayed booking verification
- Traveler notifications and tracking
- Internal operations management
- Provider responses and proposed resolutions
What’s Next
Our next steps include:
- Real speech-to-text and telephone support
- Secure traveler accounts and persistent cases
- Booking-platform verification integrations
- Email and SMS notifications
- Automated provider-response delivery
- Photo and document evidence uploads
- Resolution analytics and listing-quality signals
