Show HN: Ikuyo a Travel Planning Web Application
In the past ~8 months, I have been working on a side project that helps me plan my travels. While most months saw no or little progress, in the past ~3 months I have been adding tons of features to support my next big trip later this year.
I've written in my blog on the feature set [1] but in short they are:
- Timetable view of activities, accommodations, and day plans
- List view and map view of them
- Commenting on them
- Expense tracker
- Sharing and collaboration with friends
The source code is also available on GitHub [2]
This is an example of a view-only trip: [3]
So far, I think I'm satisfied with the features and is progressing really well in my travel planning.
Let me know what you think! Thanks!
[1] https://blog.kenrick95.org/2025/06/ikuyo-plan-your-next-trip...
[2] https://github.com/kenrick95/ikuyo
[3] https://ikuyo.kenrick95.org/trip/2617cd98-a229-45d4-9617-526...
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?
- On Trip Sharing, hmm that seems weird. While I understand that there's no 'loading' indicator yet, one should be able to do so if one is the 'owner' of the trip
- Expense split: because that feature isn't there yet
- Thanks I'll consider it
- The map I chose on MapTiler is OpenStreetMap, but I limit it to Point-of-interest only, maybe I need to expand it to match more kind of objects
- Aha, for that case, I find that it's so troublesome that I have to split the activity into two different elements for display in the timetable, so I disabled the case for now. Thanks for a great use case!
- Hmm strange, the activites should reflect live. Maybe the 'back-end' is a bit slow
Anyway, the 'back-end' is InstantDB ( https://www.instantdb.com ) and it's opening a WebSocket connection, that's why you don't see network calls when doing operations
P.S. I don't think I'll monetise this ever. If someone forks it and monetise it, as long as it doesn't affect me, I think I'm fine with it. If I run out of my 'free usage' quota, I'll probably limit the users to only handful of people
There are many different goals for developing software, and different ways to make money doing it. The AGPL can be useful for some of them, but can be rather limiting too.
If you haven't tried the app in the last few months, can you try it again and let me know what parts are feeling slow for you by emailing me directly at peter@wanderlog.com? I'd love to take a closer look, and especially if you've got specifics with screenshots/videos, I can try to fix some of these myself too.
No comments yet
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.
First and foremost, it's for my own personal use. I like to organize things and I find that the messy doc/spreadsheet way is way too messy for my liking, especially when I find a need to coordinate plans with other friends overseas. That's why I started this.
Secondly, it's for fun and for learning. I enjoy build websites and explore what browser can provide. I learned that browser have API for drag-and-drop element to pass data to a target element
So at the end of the day, I see it as a fun side project and nothing more.
Thanks for sharing your experience too :)
I think what these tools miss is that it’s kinda fun to plan a trip and I don’t necessarily need an app to help. It seems hard and like something I’ll need to learn once, and relearn when I need it again
This. If you want someone to use your thing, it needs to have a very strong value proposition over familiar general purpose tool.
This applies to basically every tool, but especially software.
It's not clear to me how much of this requires an account, but I would encourage making as much as possible accessible without a login. Some people will want to help plan but there are also many people who just want to come along for the ride.
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..
Yeah, some of the input elements are quite 'basic' as they use browser default input element. I shall improve of them in due time...
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.
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.)
Anyway, a dinner reservation for a group of 20 is different than planning an entire vacation to the minute.
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
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.
The only local time zone used is at the comments (but hopefully it is clearer since I show the time zone offset there? I don't show it on the events since I feel it could be way too verbose)
I understand that there could be case where one's trip crosses multiple time zones, but at this moment that wasn't supported yet.
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
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!
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)
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?
Probably you just need to copy `.env.example` into `.env` and replace the required API keys. [1] The whole 'back-end' is an external dependency hosted elsewhere by InstantDB [2] While they claim that you can self-host it too, I haven't been bothered to self-host it myself. Other than that, I'm using MapTiler Cloud for the mapping service [3] since I find that while there are free ones, those can be quite limited when doing things like geocoding (querying keyword to coordinates).
[1] https://github.com/kenrick95/ikuyo/blob/main/.env.example
[2] https://github.com/instantdb/instant
[3] https://www.maptiler.com/
I think this is one of the main reason I started this web app as a 'timetable' view first and then build other features later on
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 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!
May I check what's your browser & version? Thanks
I was trying not to add more external SDK since it contributes to the bundle size. Adding Sentry soon for some observability.
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...
No comments yet
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.
A gallery with a read-only private link would suffice.
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.
Unfortunately I've been challenged with the Recaptcha quite often too. That part is apparently injected by my shared hosting service (Hostinger) with no ability to turn off even when I check with their support. I hosted this at my main site (kenrick95.org)'s shared hosting service as a subdomain since I don't need to pay extra to do so.
I might consider moving it out somewhere else if I decide to maintain it separately from my main site.