Errors to Avoid in a Hackathon

The most common mistake is not writing a bad prompt, but rather sending commands too soon, before clearly defining what you want to build. The platform's speed can trick participants into skipping the thinking stage, leading them to have to fix what a single, well-structured prompt could have achieved.

At the other extreme: dedicating half the hackathon to documentation. Here, we are not looking for a complete or complex software product with extensive documentation. A functional product, however minimal, is what allows you to face reality: test, validate, and demonstrate. Without something on screen, there is no learning.

It's tempting to write a giant instruction that describes every page, feature, and interaction at the same time. But massive prompts overwhelm the model, which ends up guessing unspecified details. The result is a product that is halfway done in many aspects, requiring more time to correct than to advance.

It is much more effective to build piece by piece, like Lego blocks.

A common mistake is to start modifying colors, fonts, and shadows right after generating the initial structure. Since subsequent development phases —adding logic, databases, or forms— will change the layout, premature design work is often lost.

The main rule: first the skeleton, then the function, finally the polish.

Many participants are too cautious and delay deciding if their prompt is correct before sending it. This slows them down considerably. The tool has a history as a safety net: if the result goes wrong, you can revert the project to the last functional version with a couple of clicks. Try, observe, adjust.

Using the wrong mode for a task is one of the main reasons why credits are unnecessarily depleted. It's good to be clear about all three:

• Plan mode to think and structure before building.
• Build mode to build.
• Visual Edit for small visual tweaks without spending tokens on major changes.

Technically, it is very common to add login systems (authentication) but omit row-level security policies (Row-Level Security). Authentication without RLS is like having the main door closed but all the rooms inside wide open: any user can view or delete other users' data.

Trying to achieve perfection in a limited-time event, instead of releasing a functional version, is a common trap. An application that works —even if it has details to polish— impresses much more than a perfect design that never gets a live URL.

A 3 to 4-hour hackathon is much shorter than the traditional 54-hour one that starts on a Friday and ends on a Sunday. For this reason, beyond good vibes and sharing experiences, it is important for people to make progress to materialize their project. Conversation is valuable; code on screen is too.