Hey everyone, I am the founder of Ryokô Planner, a Japan trip-planning app I am shipping during Shipaton 2026.

Build in public is a great way to stay accountable. It is a terrible way to decide what to ship. I am writing this from inside Shipaton: Ryokô Planner is live on the App Store and Google Play, built in Flutter, and the hardest product work was not the store listing. It was choosing what to ship and when to stop implementing features. A Reddit survey with fifty-plus replies, a tight persona, time on the floor at Japan conventions, and an in-app feedback loop after launch did more for the roadmap than any “ship it” comment. Advisors are not buyers. Go talk to the people who actually have the problem.

Your Users Are Probably Not On Builder Platforms

It is easy, when you build in public, to mix up the suggestions of people who follow the project with what the project actually needs. Those comments are often well-meant, and sometimes they are even right. They are still not a substitute for the needs of your target audience.

The people cheering your screenshots are usually other builders. They care about the process, the stack, the shipping ritual. That is a fine community to have. It is not a market. A hackathon timeline makes the trap worse: you are surrounded by other participants, posting progress, swapping stack advice. Useful. Not your customer.

That is why I struggle with the closed loop of maker platforms that promise to put your app in front of people. Your users are not there. At best you get a backlink. Fine. It still does not move you toward users, let alone paying customers.

A like from another indie hacker on a UI screenshot does not pay your server bill. A “ship it” comment is not market validation. If you are building for travelers, accountants, or teachers, they are not browsingProduct Hunt over breakfast. They are somewhere else. That is where you have to go.

A Personal Need Is Only a Starting Point

When I started Ryokô Planner, I was solving my own problem: how to stop living with forty Chrome tabs open just to organize one trip to Japan. I was already my first customer. Living inside the problem gave me a decent hypothesis, and a thin slice of validation.

It was not enough.

Looking at what the app became, and at the size of the original specifications, I was heading into months of Flutter work: multi-stop itineraries, points of interest scored against interests, editorial content, the unglamorous plumbing of a travel planner. I could not bet that much time on my own taste, or on whether the idea could even pay for itself. Shipaton rewards shipping a real app to real users. Real users do not appear because you opened a Devpost page. I needed to talk to the actual audience, see whether their needs matched mine, and find the holes in my game.

I used two complementary approaches: quantitative, then qualitative.

Volume first, Then Depth

Quantitative work means getting as many answers as you can from the right people. I went with a survey, posted on a Japan-focused subreddit where travelers already ask how to plan their trip. Fifty-plus responses. Not a scientific panel. More than enough to stop saying “I have a feeling that…” and start prioritizing.

A survey like that should be short enough that people finish it, long enough that you learn something, and fully optional on every question: half a survey beats an empty one abandoned out of frustration. Mix closed questions (checkboxes, scales) for stats with a few open fields for the things that will not fit in a box. If you ask for an email, keep it optional, say exactly what you will use it for, and follow the rules that apply to you : GDPR, for example, if you are dealing with EU respondents.

The most useful output, for me, was a feature ranking. Four ideas came out well ahead of everything else:

• Build a personalized itinerary, optimized around my interests
• Suggest original or lesser-known activities
• Help me organize getting around (trains, JR Pass, and so on)
• Give me practical tutorials (how to take the bus, how to use the JR Pass, local customs)

That was not a backlog of nice-to-haves. Those were the four features I refused to launch without. It ended the arguments with myself. Everything else could wait. Launch could not.

Open fields still are not enough. Use the emails people left and ask for a conversation. Sharpen the survey answers. Get the details that will confirm your hypotheses, or kill them.

Only then should you decide to start building. If you have not spoken to the audience, how would you know what they want?

Who Is the Audience, and Where Are They?

That question shows up too often after the first lines of code. It should come first.

For Ryokô Planner, the persona is not “people who like Japan.” That bucket mixes crowds that have nothing in common: the collector buying figures, the retired couple on a packaged tour, the digital nomad on a third stay in Fukuoka. They all like Japan. They do not share a problem.

Mine is a young professional who has always dreamed of going. During school the trip stayed out of reach: too expensive, too far, too complicated. A few years into a stable job, some savings, and finally a shot at it. The first big trip their savings will pay for. The kind of journey you plan for months, tell stories about for years, and really do not want to mess up.

That persona immediately told me where * not* to look, and where to look.

Not on Twitter/X, arguing in indie-hacker threads. Not on Indie Hackers. Not in maker Discords, and not in the Shipaton Slack treating other builders as a proxy for demand. On Japan subreddits, in Facebook trip-planning groups, on dedicated forums like Le Routard in France, in the comments under YouTube videos titled “3 weeks in Japan, itinerary,” in Instagram stories from people just back from Tokyo. The questions sound like: “14 days, first time, do we do Kyoto or skip Osaka?” and “Is the JR Pass still worth it?”

Those places are less glamorous than a Product Hunt launch. They are far more useful. That is where the real friction shows up: fear of splitting days badly between cities, the pile of tabs, the feeling of missing something essential, the couple that cannot agree on a route. Signals I would never have gotten by asking other developers what they thought of the app.

The persona is also a filter. Every feature, every screen, every article can take the same test: does this help that young professional lock in a trip without spending three months of evenings on it? If the answer is no, it does not matter how well it would play with other builders. It is not for them.

Validation Is Not a One-Off

Talking to your audience before you code is the minimum. It is not a stamp that stays valid until you hit “Submit to Review” on App Store Connect.

A survey at month zero is a snapshot. Months later you have mockups, new hypotheses, and features nobody asked for that you happen to find elegant. The risk is falling back into the original trap: building alone, then returning with a finished product nobody requested in that shape.

So I try to re-validate the important bets with the same audience throughout development. Not every pixel. The bets. Changing the core of the itinerary, adding an affinity score against interests, pushing editorial content instead of an activities marketplace: those are product decisions. They deserve to be checked with people who are actually planning a trip, not with your timeline.

In practice, it is a short list, repeated often:

• Send a prototype, even an ugly one, back to people who left their email on the survey.
• Do not ask “do you like it?” Ask “what would you do next to prepare your trip?” and watch where they get stuck.
• Keep early-user feedback and builder-follower feedback in separate buckets. Both can exist. Only one should drive the roadmap.
• Kill an idea you loved if your audience does not see a problem worth solving.

Build in public still helps, if you put it back in its place. Sharing the process brings other makers, technical notes, sometimes a morale boost on a Tuesday when nothing works. It does not replace a twenty-minute call with someone who has a ticket to Narita in four months.

Go See Them in Person

The internet gives you volume. Being there gives you the truth.

A form will not capture the pause, the “wait, let me show you how I organize this,” the couple talking over each other about the order of cities, the notebook and the camera roll full of screenshots. You see that face to face. It is often worth more than a hundred multiple-choice answers.

For Ryokô Planner, the obvious place is Japan-related conventions and fairs. In France, Japan Expo in Paris is the most visible, but it is not the only one: Japan Touch, regional events, smaller cultural fairs. Thousands of people who like Japan, including a slice who are preparing that first big trip, or who keep saying “someday.” Not every visitor is the persona. It is still probably the highest concentration of them I will find in one room.

The point is not to stick a QR code on a banner. It is to ask questions, watch people open the app for the first time, notice what they look for, what they do not understand, how they currently plan. You will quickly tell the tech-curious visitor from the one who already has an Excel sheet and twenty “places to visit” tabs. The second is your audience. The first might tell you the UI looks clean.

And listen for the sentence that comes back most often after a demo: “Okay, but does the app do X?” Often the answer is yes. And you just learned that capability is not visible enough. Sometimes the answer is no. Then you may have found another hole in the racket. Not every hole is worth filling. One enthusiastic request is not a roadmap. Always check whether the feature actually matters to the persona, or whether you are adding an exception to please the person standing in front of you.

Let’s be clear: a booth is not necessarily profitable. Badge, stand, time, travel. Word of mouth can help, but counting installs the following Monday to justify the invoice is usually the wrong metric. The value sits somewhere else. Direct contact opens doors a post will not: a partnership, a comment that reframes a feature, a conversation that turns into a tester, or simply the chance to rehearse your pitch with real users, push through shyness, and get out of your comfort zone.

Those conversations cost time, a badge, sometimes a stand. They return something no tweet will: confirmation that you are speaking to people who actually have the problem, in a place where they already gather.

If your product does not have “its” Japan Expo, an equivalent almost always exists. An industry meetup, a fair, an association, a café, a gym your persona already visits.

And validating the idea is only part of what showing up makes possible. Once you are there, you have people, a setting, and an energy you will never get from behind a screen. I used that to produce content: vox pops, a camera, questions to visitors about how they prepare a trip to Japan. The goal was social material, shot where the audience already was, instead of app screenshots narrated from my desk.

After the Store Listing, Keep the Loop in the App

Shipaton does not end when the build is on App Store. The brief is a real app in the hands of real users. Once Ryokô Planner was live, the question became: how do those users talk back without me standing next to them with a phone?

I did not want them to have to find the contact email and go to their mail client to write what was not in the app. Most of the people do not do that. I wanted the request to happen in the same session as the trip they are actually building. Two features in the Ryokô Planner do that work, in different ways.

The first is a menu entry that opens an in-app feature board with UserOrient, via the native userorient_flutterSDK. It is Dart widgets, not a WebView, which matters when you are asking someone mid-itinerary to pause and tell you what is missing.

Users can suggest features and vote. That is the post-launch version of the Reddit survey: still the audience, still a ranking, now attached to people who already installed the app.

The second channel is more specific to this product: users can suggest places to add to the catalog. Nobody files a missing shrine, café, or onsen they have no intention of putting on a trip. A place request is a usage signal. A feature vote can be a wishlist. A pin on a map they are building this week is closer to “I am actually using this.”

Both only work if you close the loop. A board you never look at is worse than no board: it teaches users that talking is pointless. A place request you ship in the next update does the opposite. It involves people in the product, tells you whether they are really planning, and makes the app look cared for. During a shipping contest, that reactivity is also a product decision: I would rather spend a sprint adding a requested neighborhood than polishing a screen only other Flutter devs will screenshot.

The same filter still applies. UserOrient will surface ideas that sound exciting and serve nobody in the persona. A suggested place can be a one-off. The board is input, not a mandate. You still decide.

Build in Public. Just Not for the Audience Next Door

Build in public is a solid tool for discipline and networking, and Shipaton is built around that habit. However, we have to be aware that it does not replace an acquisition strategy or a discovery method.

Advisors are not buyers. Your timeline is not your market. Your first customer, even when that customer is you, is only a hypothesis. The rest is won where your audience already lives: in a survey they will finish, on a call they will take, in a convention aisle between a merch booth and the line for an autograph, and later, in a menu inside the app you just shipped.

It is less comfortable than posting a screenshot. That is how you build for your public, not only in public.