As someone who ran a travel startup in mainland China for a few years, forgive me for being unimpressed. Here's what happened. I loaded the page and consistently expected to see something impressive to justify the title, but only got:
- Source/Destination detection
- (DateJS style...) natural language temporal specification
What is so impressive about that? It's not even multilingual. Does it do typo detection? Does it do non-airline routes? Does it do passport/visa law interpretation? Embassy/agent/border point locations, open times and fees/currencies for visa acquisition? Black market vs. theoretical currency conversions? Credit card acceptance? Processing times? Time-of-day detection and night-time travel warnings?
You could hire me as a once off or occasional consultant for some more cheap ideas and reality-checks (full stack engineer from AU, previously lived US, so not ignorant of performance issues or your team cultures, either) or you could continue retreading old ground. Either way, there's a lot of the latter left to do before impressive happens.
Oh yeah... and the slow thing really is a problem. All I can think is that you are scraping data from many sources, because for the query I ran, there is exactly 1 (one) carrier, and a fixed schedule, with exactly 1 (one) price per standard, linear fare-period. There is no excuse for a non-instant response, unless your architecture is somehow borked.
> flexibility on dates ("mid July for 10 to 15 days")
Leave and return date flexibility exists within sites like Kayak, I use it all the time. Though it would be nice to make it more flexible, I agree, but this is not a new or killer feature.
> - broadness on destinations ("Southeast Asia", "Western Europe", "California")
Many people have this, usually powered by iffy geonames databases that are monolingual, out of date, or just plain wrong. These existing systems work fine for major destinations though. Best of luck doing the smaller ones and/or other languages better.
> - non-geographic searches ("Somewhere warm")
Iffy. Looks cute on advertising, but of dubious value given that everyone's definition is different. Example: Warm for a northern European or Canadian might be southern France in the European winter. At the same time, even further south and where it may be warmer in northern Africa, someone from LA or Sydney would not find it 'warm'.
> no-one else has succeeded in building a product like this
Major travel aggregators such as Qunar.com and Kayak.com are pretty ballpark. While you can definitely top their UIs in numerous small ways, you will have to make the net UI change valued enough to sway and keep users. Good luck with that.
I would go back to your target market and their use cases ... look at what they value ... un-tech-bias your judgements .. re-align your USP. (Suggestion: consider a range of 'cheapstake' to 'livin it fine' budget per day in a city/country and refocus on helping people to find new and innovative destinations they might like to visit but have never considered, by helping them to find destinations that meet their budget requirements. I know this is really a strong potential selling point for loads of weather-dissatisfied Londoners, and South America and Asia are strong potential regions for north Americans. Ditto south&SEA for Chinese, who are cashed to the hilt right now.)
> While you can definitely top their UIs in numerous small ways, you will have to make the net UI change valued enough to sway and keep users.
... also, complex enough to implement that the existing players can't just immediately emulate your changes (simultaneously letting all their users know about their great, new 'innovation', thus killing your only USP) should you actually gain any traction.
What is so impressive about that? It's not even multilingual. Does it do typo detection? Does it do non-airline routes? Does it do passport/visa law interpretation? Embassy/agent/border point locations, open times and fees/currencies for visa acquisition? Black market vs. theoretical currency conversions? Credit card acceptance? Processing times? Time-of-day detection and night-time travel warnings?
You could hire me as a once off or occasional consultant for some more cheap ideas and reality-checks (full stack engineer from AU, previously lived US, so not ignorant of performance issues or your team cultures, either) or you could continue retreading old ground. Either way, there's a lot of the latter left to do before impressive happens.
Oh yeah... and the slow thing really is a problem. All I can think is that you are scraping data from many sources, because for the query I ran, there is exactly 1 (one) carrier, and a fixed schedule, with exactly 1 (one) price per standard, linear fare-period. There is no excuse for a non-instant response, unless your architecture is somehow borked.