Mistakes to Avoid in a Hackathon

The most common mistake isn't writing a bad prompt, but rather submitting commands too early, 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.

On the other end: dedicating half the hackathon to documentation. Here, we're not looking for a complete, complex software product with extensive documentation. A functional product, even a minimal one, is what allows you to face reality: test, validate, and showcase. Without something on screen, there's no learning.

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

It's 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 submitting 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 on 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's very common to add login systems (authentication) but omit row-level security policies (Row-Level Security). Authentication without RLS is like having the front door locked but all interior rooms wide open: any user can view or delete other users' data.

Trying to achieve perfection in a time-limited event, instead of publishing 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. Therefore, beyond good vibes and sharing experiences, it's important for people to make progress to materialize their project. Conversation is valuable; code on screen is too.