Show HN: Ikuyo a Travel Planning Web Application

I've just registered to test it out a little bit. I tried to replicate my upcoming trip that I have set up in Wanderlog, and have the following feedback:

- Overall, amazing! Snappy. Real easy to follow.

- I love the simplicity.

- I like that this is essentially excel (kind of), but with travel specific additions.

Now for the potential improvements:

- I can't add someone else as an editor, it seems. Clicking add just logs a "TripForm" with the form object. I don't see any network requests either.

- Expenses don't allow me to select how to split it (maybe this is an issue because there's no-one else part of the trip?)

- Timetable contrast needs a bit of work. Maybe needs some padding/margins or something.

- MapTiler doesn't seem to have a good enough database. I struggled to add 152 Morrison Road

- Activities can't span multiple days (I tried adding a train ride than arrived 45 mins past midnight)

- Adding/editing activities while on the timetable page, does not update them until I refresh (or navigate away)

Outside of all that, how are you planning to monetise this? The code is released under MIT, which doesn't stop anyone from adding some subscription plan, hosting it, and advertising it. May I suggest something like AGPL?

I built a web app that looked very similar a few years back: friends & family collaboration on a trip plan, itinerary with map view, packing list, notes/journaling, favoriting, private or public with commenting, that sort of thing.

My thesis was that the current common method of trip planning in a shared doc was messy, and a more structured, guided approach would make the process easier for users. And being able to share/show trip plans with others who aren't on the trip would be something people would want to do.

My goal was to scale it and get actual broad adoption, make it a social experience, but even getting a handful of users was an uphill battle.

I found that my thesis was likely wrong for a couple of reasons:

1. The messy shared doc approach had the benefit of being very low-friction. It's easier to just type a bulleted list than to click "add item" and fill out some form fields.

2. Browser usage was (I think) a limiting factor. I'm not sure if it would have worked as a native mobile app, but it definitely wasn't going to work as a web app.

3. When people want to show off their trip or look for travel inspiration, they turn to apps like Instagram and Tiktok. They want visuals with photos/videos, not a list with a map. It's very difficult to create a new purpose-built social network.

I ended up winding it down and moving on.

I don't mean this to be a Dropbox "why are you building this" comment, but more hopefully pointing out a few challenges that exist in the space that you'll likely need to think about if you want to scale.

Adding a sample trip might help a lot to give an idea of how to use it.

Inputs feel tedious and not smart enough; so much that it feels to get in the way instead of helping.

Activity date input shouldn’t be free date input; I inputted the start and end date earlier, couldn’t that be used to help limit the input range? End date/time feels tedious as well, it could be a duration input instead (eg 3h at this location).

It also lacks some extra planning features, like pooling the list of locations to visit (no dates yet), for later to be scheduled if it ends up interesting.

Personally I would remain using Wanderlog..

In logistics mode, I want a detailed, precise timetable focused on transportation and lodging. I don't even want to see my fun ideas.

In fun mode, I want a relaxed set of suggestions based on my current location, and a single timestamp telling me when I need to go back into logistics mode.

Does that make sense? Its almost like I want two travel agents: a didactic drill sargeant to get me from A to B, and a chill surfer bum that helps me go with the flow.

The collaboration part is not that developed (but does exist based on Matrix as decentralized and end to end encrypted storage). That works very well is ticket extraction for hotels, train or flight + search for connection using public transport APIs.

Disclaimer: I'm involved with that app

There's nothing I hate more than needing to be at a precise location at a precise time when I'm on vacation! (After all, it is a vacation.)

Previously, I had made a travel app for myself, however, it was different. The main feature was around the map and locations, with a necessary list of some POIs. When I was in the city, I used it to see if there was something interesting that I had pre-scouted not far from my location.

From the technical side, I took a look into the CSS and was surprised. Some of the CSS I could not even understand (like below), and there were thousands of different colours used hundreds of times. Not sure if it was by design.

grid-template-rows: [header]50px [macroplan]min-content [accommodation]min-content [t0000]var(--row-minute-narrow-height) [te0000 t0001]var(--row-minute-narrow-height) [te0001 t0002]var(--row-minute-narrow-height) ... in loop

Yes it is a sort of TSP, but you cannot assume fixed weights (as some roads can be open only some times of the day)

Some large countries may have multiple time zones, and itineraries can be confusing, this needs consideration from data modeling and ux side as well. The first glance at the UI didn't make it obvious for me how this is handled, I suppose local time is used always.

Whatever you do, please do not make the app as slow as Wanderlog - I literally had to create an Android app to interact with my trips because their app isn't optimized at all!

OP, let me know if you want to do a user group trying to help us organize a trip.

I noticed the MIT license, any plans to document how someone could self host this? Or would you be open to contributions from other people to do that?

I think it would be most useful in later stages of planning and sharing the result with friends. The major steps of planning a big trip (as I see it) are:

1. figuring out what activity options there are (brainstorming+researching what to do)

2. getting that into a sensible schedule with all constraints of opening hours, distance/travel between them, available time in the trip, budgets (either the glacier tour or that lodge with a skylight to see auroras, say), and preferences (some activities are cooler than two other ideas together)

3. booking

4. doing, and adapting on the fly as plans meet reality

I did these things in a Markdown file last time (CodiMD, specifically) and that worked surprisingly well. The big downside is that you can't have different views on the same data: to get from step 1 to 2, it would be cool if you can plot them on a map as an approximation of how much time you need to travel between them, or to give them all coordinates and have it show you a traveling salesman solution, just to have a starting point of what order makes sense. Or URLs for everything (info, reviews, booking status, ticket download..) gets messy. Ikuyo can view activities as a list and also as a map and also as a schedule, so that looks very promising!

Making a test trip, besides some unnecessary metadata like currencies (same, all euros) and target region ("various countries in Schengen" was not an option), I didn't really feel like it helped me get any of the stages done specifically. You need to pick a datetime for each activity up front, or you leave it as dummy, but either way you can't then drag&drop events to make a schedule. You need to open them up, press edit, and use the time selector UI. In Markdown, moving an event isn't drag&drop either but at least I can simply move the line to where on the schedule it makes sense and type the time directly

So I guess I'd put the activities in here once I've got a draft in Markdown? Then friends can view it in various ways. A friend previously (different trip than where I used Md) used a spreadsheet and that experience was relatively mediocre: Ikuyo would most definitely be better as a sharing format!

For during the trip, is there a way to save it offline? Comparing to Markdown or spreadsheets, I can download an HTML render or ODS file on my phone and view it any time, or even print it out. For viewing my trip on this website randomly during the trip ("what time did we need to be back in the village again?"), you'll always need internet and the website to be up right?

I had a peek at the source code as well and it looks all neat. After logging in, I needed to edit the URL to get back to the homepage (clicking the logo doesn't do it) and find the source link, but that's fine for me. The number of dependencies looks pretty reasonable and I could see myself hosting this!

If you’re going for PMF and traction… It needs to have all sorts of Nikita Bier onboarding juice, remove all barriers and friction for not only the person setting this up but most importantly their companions. Time to first usefulness is currently minutes. It needs to be seconds. And then layers of social sharing work so that the content this app generates is stuff that will be easily shareable on Instagram. And then layers of contact adding stuff for vitality.

Then your next problem is people don’t go on trips that often, so at best your users can only use it in spurts a few times a year.

And your reward for all of that is then figuring out how to get money out of these users. Ads?

None of that should be bad news. It’s good news. The hard truth is this is not a marketable piece of software. It’s a classic tarpit.

You’ve clearly built something that YOU love and are passionate about. That’s awesome. Keep building it, and get that little burst of dopamine when you add a feature that you love that is perfectly designed for exactly 1 user, the only one who matters.

And then when a profitable idea pops into your head you know what it will take to bring it to life. And if it’s a truly great idea, one that helps your users make money, it wont need any of the soul crushing growth hacks described above, people will beg you to use it and put up with all manner of warts and bugs because it helps them make money.

I travel "full time" with my girlfriend, and she does most/all of the planning. The hard part isn't writing down what needs to be done, it's coming up with the plan in the first place.

First you pick a location, then you pick points of interest. Then you need to devise a route that makes sense that lets you see all those points and how you're going to get between them. Trains/buses/taxis, the timetable for those modes of transportation, the backup for when you're inevitably late, the "point of no return" where it's time to give up on that attraction.

For some places, reminders when tickets go on sale for the thing you want to do if it's extremely popular. Where it makes sense to do things as day trips and where it makes sense to just move to a more rural location/camp to see things. What to do with your luggage and how to move it from place to place.

Admittedly, I haven't signed up, I just looked at the free example and showed it to my girlfriend. She uses excel + google maps for visualizing the plan and we're not sure what this gives ontop of that. We're also always together in person, I could see how if you were far apart, perhaps the commenting and stuff could be useful?

Fully open sourced https://github.com/CopilotKit/CopilotKit/tree/main/examples/...

In case you find it useful.

https://examples-coagents-ai-travel-app-git-main-copilot-kit...

on the other hand, if you add some more social elements it could be fun, theres a few apps that allow people to upload places and hotspots too so its more community driven, but also thats kinda instagram too.

There's been several alternatives mentioned on HN over the past year. A quick search through my browser history revealed https://altcha.org/open-source-captcha/ as the most recent link I'd been to.

Just to say I have no experience of any of the "alternative" captchas, I just hate the one you're using.

Also please get your app up and running fast so we can use it for our vacation in early September, haha :-) Thank you.