Contact

Mexico City, Mexico
Available for remote and on-site projects.

Professional networks

LinkedIn · GitHub · Email
Applied engineering, measurable results.

Tips for your first hackathon (from someone who just went to theirs)

· 4 min read · Samuel Torres

Spirograph figure (hypotrochoid)
x(t) = (R - r)cos t + d cos((R - r)t / r)

In short

  • Arrive with your setup ready: repo, libraries and a server deploy template.
  • Build something that works end to end in the first hour.
  • Measure time per task from the start.
  • Use Git from minute one and test against what you do not know.
  • Talk to people: it moves you forward more than anything.

If you are going to your first hackathon, the most important things are these: arrive with your setup ready, decide early what you will deliver, measure time from the first hour and talk to people. I learned this at Frontier CDMX 26, where I took part on my own and did not win. Here is what I would do before, during and after, my mistakes and a printable checklist.

What should I do before the hackathon?

  • Apply even if you have doubts. At Frontier it was 8 open questions in English and nobody got in on their CV. I applied doubting and was approved in two days.
  • Set up your environment the day before. Repo created, language installed, libraries tested, GitHub access. I lost the first half hour on that.
  • Have a template ready to deploy to a server. If the evaluation calls an API, you will need a service, HTTPS and logs. Having it solved buys you time.
  • Decide whether you go solo or in a pair. Solo you learn a ton, but everything is on you.
  • Sleep. It sounds obvious. It is not at 4 in the afternoon.

What should I do during the hackathon?

  • Read the challenge twice and look for traps. Mine had a screen repaint every second, clicks ignored if shorter than 100 ms and text that concatenated.
  • Build something that works end to end in the first hour. Ugly but complete. Improve it afterwards.
  • Measure time from the start. My agent kept running out of time: a 4:24 median against a 5:00 limit. Had I measured it from the first hour, I would have designed differently.
  • Use Git from minute one. An accidental restart exposed a real bug; with Git I could roll back without fear.
  • Test against what you do not know. 5/5 in practice guaranteed nothing in evaluation (1/34).
  • Use AI with method. I used Claude Code for much of the code, but the architecture, rules and priorities were mine.
  • Talk. The doubts I cleared up with other participants moved me forward more than any search.

What should I do after?

  • Write your log the same day. What worked, what failed and why. By the next day the details are gone.
  • Publish your code and tell the story. Mine is on GitHub and the story is on the Frontier page.
  • Revoke the event's keys and tokens. Temporary credentials leak too.
  • Write to the people you met. Friends I met there took 1st and 2nd place.

What mistakes did I make?

MistakeWhat happenedWhat I would do
Unprepared setupThe first half hour went to installing.Bring it ready from home.
Speed at the endA 4:24 median of 5:00.Measure time per task from the first hour.
Testing on the familiar5/5 in practice, 1/34 in evaluation.Test on new screens.
Trusting a "success"The agent reported 25 where there were 45.Verify every result against the screen.

I go into more detail in what I learned finishing last.

Is there a printable checklist?

  • Application sent, even with doubts.
  • Repo created and GitHub access working.
  • Language, libraries and tools installed and tested.
  • Server deploy template (service, HTTPS, logs).
  • Decided: solo or pair.
  • Challenge read twice and traps noted.
  • Something working end to end in the first hour.
  • Time per task measured from the start.
  • Git from minute one.
  • Tests against what I do not know.
  • Log written the same day.
  • Event keys and tokens revoked.

You can print this page: the list is ready to tick off.

Where can I read more?

These guides helped me organize what I learned. I recommend them as further reading:

And the full story of my day is in my first hackathon. If you want to see how I bring this to real projects, take a look at GARAGE.

FAQ

Can I go to a hackathon solo?
Yes. I went solo to Frontier CDMX 26. You learn a ton, but everything is on you; in a pair you can split agent, tests and server.
What should I prepare before arriving?
Repo, language and libraries tested, GitHub access and a template to deploy to a server with HTTPS and logs.
Is it OK to use AI at a hackathon?
If the rules allow it, yes. Use it with method: you define the architecture and rules, review and deploy.
Samuel Torres Pichardo

Samuel Torres Pichardo
Software and cloud engineer in Mexico City, with about 3 years of professional experience. I built the Conqr website I write about here.
LinkedIn · GitHub · Contact

Professional contact:

Mexico City, Mexico

Available for remote and on-site projects.
B.Eng. in Computing and Telecommunications Technologies

© 2026 Eng. Samuel Torres. Applied Engineering.