How to win Shipaton, part 1: coming up with an idea

Shipaton just kicked off. Developers are starting to build their apps (if they aren’t already). You’re interested in participating, but you don’t know where to start. Worst of all, you don’t even know what to build.

I’ve been there. In my past life, I competed in over 70 hackathons and ended up winning 45 of them. If you’re unfamiliar, hackathons are fast-paced, 24–48-hour sprints to build something cool, useful, or delightful. Shipaton is essentially a mobile hackathon with a slightly longer timeframe.

The keys to winning a hackathon—whether it lasts two months or 24 hours—are the same:

• Solve a real problem
• For real people
• In a way that delivers delight or an “aha” moment

I’m going to explain how to hit those three points and how they’ll help you win Shipaton. This article is the first in a series focused on ideating, building, and growing a mobile app with a shot at winning. By the end of this guide, you’ll have a concrete idea to build, a way to validate it, and confidence that your app solves a real problem.

Come up with a killer idea

The first step, before designing or building anything, is to come up with an idea—not just something you want to build, but something you need to build. That difference is crucial. Once the initial motivation fades, what you wanted to build becomes something you’ll “work on later when you have more time.” But the feeling of needing to build something is much stronger. It gets you through the bugs, the burnout, and even the users who hate your idea.

Your mission statement should be:

I need to build this, because I’m the only one who can get it right.

Getting to that point requires working on a problem that’s tangible, challenging, and shared by more than just you.

Discover a real problem

A real problem is one that exists for more than one person. A common mistake is building something for yourself and assuming others share your pain. More often than not, the problem isn’t as serious as you think—or it’s already been solved.

Here’s an example. I worked on a mobile app where the company had top-tier talent: successful founders, strong product leads, and a bold vision. The idea was to rival Twitch by letting viewers bet on what the streamer would do next. The thinking was that this would drive engagement, which would attract more streamers, and in turn, more viewers.

It worked at first. But after launch, users didn’t return. The team overlooked a key insight: most people watch game streams passively. They put them on in the background. They aren’t looking to engage more deeply.

The company started with a solution and went looking for a problem. Always start the other way around.

A real problem comes from real people with real pain or unmet needs. Discovering that is the first step to building something that matters.

Talk to people

The best way to find real problems is to talk to people. Not to pitch your idea—just to listen. Ask open-ended questions. Pose hypotheticals. Get them to imagine a perfect world.

Talking to users could’ve saved that Twitch competitor. A few honest conversations might’ve revealed that engagement wasn’t the issue.

It’s not always easy to start these conversations, especially if you’re unclear on the problem space. Narrowing your focus helps. Start with a domain you know. Maybe you once worked in a research lab and remember how tedious it was to recruit student test subjects.

There’s your starting point. Reach out to a few research groups. Ask if they struggle with recruitment. Offer to chat. Show up with curiosity and ask open questions. You may find your original assumption was wrong, but you might also uncover something real.

Start with a single problem

Things can still go sideways even if you’ve identified a real problem—especially if you try to solve too many problems at once, or your initial solution becomes too complex.

Let’s look at an example.

You’ve decided to build something for barbers to manage bookings. You create a solid mobile app that allows barbers to mark when they have free slots, and lets customers book those slots. Then, one of the barbers mentions they also struggle with payments and estimating profitability.

Instead of launching with the booking system, you decide to keep building—adding billing functionality and advanced charting features. What was meant to take two months turns into six. In that time, some customers may have found alternative solutions. And the new features? They may not even add much value beyond that one barber’s specific case.

This is why speed matters. And why narrowing down your scope is critical in the beginning. Your goal should be to validate your idea with the bare minimum set of features. Don’t try to build a full menu—just focus on getting one dish right.

Validate your idea

We have already talked about validating your idea in the previous part but product development in essence is constant validation of ideas. It doesn’t stop after validating the initial idea. Shipaton takes two months. If you truly want to win, you should be validating your product until the very last day. This means that validating ideas does not stop after you’ve built your prototype, it doesn’t stop after you have launched your product, and it doesn’t stop after you made some dollars from your idea. Building products is a continuous process of learning and discovery. 

In order to constantly validate your idea you need to gather feedback from users in a continuous way. When you’re first starting building your product, aim to release when your product has the feature your users asked for, but when you’re still slightly embarrassed about the state of your product. Embarrassment is the only way to know that you’re not spending time on something that might end up being useless in the end. If that feels hard here is how to validate your idea at every step:

• If you only have a rough idea of your app, make a paper or figma prototype. Send the link to users and ask them to test it out over a video call and narrate as they use the prototype
• If you app is only on your phone, give them your phone and ask them to use it
• If you have built a version of your app that can be distributed, let users install the app on their phone and schedule a call with them after they have tested it

In the beginning it is not about the amount of feedback, but the quality of it. Don’t implement analytics in your app, it doesn’t provide any benefit at this level. Instead aim to ask open ended questions, prompt users to provide suggestions, evaluate the given suggestions critically and build the features that make the cut. Launch your product as many times as it takes:

Eventually your idea will take shape into something that users would be interested in using, at which point, preferably earlier already, you should start asking how much they would be willing to pay for it. How much people are willing to pay for something is the best estimate of how much value they give to it. Your users hopefully want to pay some amount of money for the product, even if you ended up monetizing it with ads. Monetizing is also one of the requirements of Shipaton.

Get ready to throw it all away

Gathering feedback has now been mentioned a few times, and you probably have an idea what to do with feedback to improve your product. But what if it turns out that the thing you’ve built doesn’t solve a single problem for the user, they’re not willing to pay any money for it, or they just don’t find it useful. What do you do then?

The answer is simple but cruel: you throw it all away and start from scratch. 

This is also the core of a successful product development feedback loop. The faster you can build out your idea, the faster you can validate if the idea is worth it to the users in the way you thought. Spending a lot of resources on development in the beginning might be a wasted effort, so love your idea but also plan for abandonment from the beginning. Hopefully you only end up scrapping ideas and features, not completed products.

Determine metrics

A systemic approach to making informed decisions about whether it is worth it to persevere with an idea is to determine metrics for tracking success from the start. These are your benchmarks that tell you whether the thing you’re building is actually resonating with users. Without metrics, you’re flying blind.

Metrics don’t have to be complicated. In fact, they should be so simple that you can answer them in a sentence or two after talking to just a few users. Here are a few examples:

• Activation: How many people got to the core value of the app on first try?
• Retention: Did they come back the next day or the next week?
• Referral: Did they tell anyone else about it?
• Monetization: Did they say they’d pay for it?

You don’t need to track everything. Pick one primary metric that reflects whether your idea is working, and use that to guide what you do next. If you’re improving that one thing, chances are you’re heading in the right direction.

The Minimum Lovable Product

You may have heard of the Minimum Viable Product (MVP), a product that accomplishes the main use case but nothing else.  For Shipaton however you should aim for building something people truly love: a Minimum Lovable Product (MLP). Both minimum viable and minimum lovable products accomplish their purpose, but the latter does it in a way that delights the user and makes them come back. This can be for example by introducing a novel approach solution of an existing problem, such as a todo where accomplishing a task requires taking a selfie. In hackathons, your idea can be something that someone already comes up with, but with some novelty and love, you can still end up winning.

When I used to compete in hackathons I would spend most of my time discovering a problem and understanding it. Solutions usually came after that almost without thinking. All my other time (not counting actually coding the hackathon project) would go into finding a unique approach, novel technology, or delightful interaction. Sometimes this meant writing code for drones to follow a construction crane to give better visibility to the crane handler, building an RPG inspired mobile app for study planning, or mobile hospital app with indoor positioning with beautiful UI. In other words, aiming for MLP. Often it brought the main prize.

An MLP does not mean cutting corners. It means ruthlessly cutting scope, while preserving the delight. It means identifying the absolute smallest surface area that communicates your product’s value — and then making sure that piece feels magical. The MLP should give your user a small, delightful win.

Ask yourself:

• What is the smallest thing I can build that still solves the problem?
• What makes this feel personal, intentional, or unique?
• What can I polish just enough that someone says “wow, I didn’t expect that”?

You’re not building a castle. You’re building a tiny hut, but one with charm. Something your user wants to return to, not because it has everything, but because what it does, it does well.

Conclusion

At the start, building an app can feel overwhelming, especially when you don’t even know what to build. But the truth is, you don’t need a groundbreaking idea. You just need a real problem, a focused solution, and the willingness to listen and adapt along the way. When you talk to people, narrow in on what matters, and build something small but thoughtful, things start clicking. You get that feeling of momentum. Suddenly, you’re not just hacking on an app — you’re building something that could actually matter to someone.

Shipaton gives you two months and a big stage. That’s more than enough time to go from zero to something you’re genuinely proud of. Don’t wait for the perfect idea or the perfect plan. Start small, stay lean, and let your users guide what you build. The best apps don’t come from perfect strategy — they come from people who are curious, willing to listen, and stubborn enough to keep going.