Hack Fast, Learn Faster — Inside a 36h Hackathon

Over one weekend, we took part in Start Hack, an event organized by Start Global that brings together more than 600 participants. The premise is simple: build something from scratch in 36 hours.

I had participated in hackathons before, but this one felt different. The pace was still intense, but the way we worked had changed. AI tools are now part of the process, accelerating everything from ideation to implementation. As a result, the challenge is no longer purely technical. It is more about how a team organizes itself and makes decisions under time pressure.

The Project: Risk It for the Biscuit

We started with a broad question:

How can we help people who are hesitant about investing take their first step?

Many people do not invest, not because they lack access, but because it feels complex, risky, and difficult to approach. Their perception is often shaped by extreme examples rather than everyday reality.Cinema and mainstream financial news often emphasize extremes: overnight millionaires, spectacular fraud, and major crashes. Most real-world investing is slower, diversified, and built around long-term trade-offs.

From this, we developed the idea of Risk It for the Biscuit, a game designed to let users experience investing rather than learn it through theory. Instead of focusing on abstract explanations, the player takes on different investor profiles, each with their own constraints and objectives. A cautious investor does not behave like a risk-taker, and a young professional approaches decisions differently than someone close to retirement.

Throughout the game, decisions interact with a simplified simulation of market behavior and personal life events. The objective is not to maximize returns in an optimal way, but to understand how choices, timing, and context influence outcomes. By switching between profiles, the player gradually builds an intuition for different approaches to risk.

Start to build

Once the concept was defined, we had to implement it within the constraints of the hackathon. We chose to build a mobile application using Flutter.Flutter was a pragmatic choice for a hackathon: one codebase for multiple platforms, fast UI iteration, and low setup overhead. It let us ship quickly despite limited prior team experience with the stack. This option allowed us to move quickly and target a platform that made sense for the product. Only one member of the team was familiar with the technology, which added an extra layer of complexity.

Very quickly, the main difficulty shifted away from writing code. Each team member was using different tools and workflows, often relying on AI assistants such as Cursor, Codex, Claude, or Lovable. While this enabled rapid progress at an individual level, it also introduced inconsistencies. Components were developed in parallel, sometimes based on different assumptions, which made integration more challenging than expected.

Step by step

The first five hours were spent aligning on the problem and the structure of the solution. This included defining what the user experience should feel like, how complex the simulation needed to be, and what level of abstraction was acceptable. Once this foundation was in place, the work could be divided more effectively.

From that point on, development progressed in parallel. The game design evolved through rapid iterations, often supported by AI-generated variations. The interface was built and refined simultaneously, while the simulation logic translated financial concepts into simplified mechanics. In parallel, the underlying technical foundation ensured that game logic, scoring, and persistence remained consistent.

As the deadline approached, priorities shifted. The focus moved away from adding features toward stabilizing what had already been built. We spent more time testing the game, adjusting parameters, and ensuring that the experience remained understandable and functional. At the same time, preparing the presentation became essential, as the ability to clearly explain the project is part of the final evaluation.

After 36 hours, we had a working prototype: a playable mobile game with multiple investor profiles and dynamic events influencing decision-making. While incomplete in many aspects, it was sufficient to demonstrate the core idea and the intended experience.

What to retain ?

In this new environment—where AI can generate a component in seconds, everyone on the team becomes an orchestrator by necessity. The challenge wasn't just to make the code work, but to ensure that the logic I was building for the event simulation didn't collide with the state management of a UI generated in a parallel workflow.

The hackathon is a masterclass in experimentation, but it also highlights what we sacrifice for speed: the time to fully deconstruct a technology, to understand its nuances, and to build with total intentionality.