How to Win Before You Write Any Code: The 4 T’s of Hackathon Prep

Fifty developers. Ten teams. A sprint from LA to Las Vegas with nothing but laptops, caffeine and a mission: build something bold on the road!

This year, AWS  is launching the Road to re:Invent hackathon - a live, mobile hackathon where there’s no rehearsals or second chances, just collaborative building under pressure.

So, how do you prepare for something as wild as this? I asked the builders who will be on the buses about their top tip for hackathon prep, and I found a neat pattern in the responses - everything boiled down nicely to these 4 core themes:

These are the 4 T’s of Hackathon Prep, straight from AWS Heroes  and Community Builders  who know what it takes to ship under pressure.

Here’s what they told me...

"In a hackathon collaboration is as important as execution," says Andres Moreno . "You've got to identify the strengths of your team to be able to collaborate and distribute the work effectively." No one’s building and deploying a full-stack AI agent from a moving vehicle in 5 hours alone. If your team is stepping on each others toes, arguing over tools, or hiding blockers, you’re already behind. So, figuring out who does what before the clock starts is a good move.

Ryan Williams  puts it simply: “Meet with your team early to determine what your strengths are ahead of time.” That way, when the bus leaves, you’re not doing intros - you’re already moving!

And don’t just assume you know how someone works. Harpreet Siddhu  says to “start connecting early to see how well you can work together as a team.” Because a team that communicates well “can easily outpace one with advanced coders who lack effective communication.”

Roles help too. Jeremy Redmond  breaks it down: have a builder (writes the code), an integrator (makes it all work together), and a storyteller (explains it clearly). It doesn’t matter if you don’t use those exact titles, just make sure the work is covered without too much overlap.

You’re not all the same. Fernando Pena  reminds us: “You must be prepared to work in a team with people who have different skills.” And that’s a feature not a bug. Or, as Michael Walmsley  puts it: “It's a team sport and everyone one counts, so don't be precious about your code.”

Once things kick off, keep the flow going. Jones Zachariah Noel  keeps it short: “Collaboration is the key! Share progress and blockers wth the team.” So don’t suffer in silence, and if you’re stuck - say it!

At the end of the day, Chris Gonzalez  nails it: “Lean on the strengths of your teammates so you can divide and conquer.” You’re not there to prove you have the BIGGEST BRAIN - you’re there to ship something cool together!

Let’s be real - time is always the enemy in hackathons. But on a moving bus, it adds a whole new level!

Jordan González Bustamante  cuts straight to it: “One of the main things to check is how long the hackathon will go for... realistically define what will you be able to accomplish. ” You might have the most 10X Developer idea ever, but if you can’t ship it before Vegas, it might as well be vaporware.

Smart time management isn’t just about coding faster, it’s about staying human. Matt Martz’ s 4 word wisdom? “Sleep! (and then coffee).” Veronica Rivera  and Shaoyi Li  are on the same wavelength here. Get a good night’s sleep, and don’t forget the snacks! As Shaoyi  points out: “pack some bananas, chocolate, nuts, or candy for quick energy boosts.” Because let’s face it, no one writes good quality code when they’re hangry.

Structure helps too. Jeremy Redmond  gives some great tips for breaking down the day: “timebox the day with a kickoff, a mid-course check, and a one hour freeze before judging.” This is a bit counter intuitive, because people often want to build right up until the last minute, but it’s smart to set aside time for polishing your presentation.

And because Murphy’s Law is real (especially on road trips), Rini Susan V S  reminds us to “expect the unexpected.” Their practical tip? “Have charged portable power banks.” Because nothing kills momentum like a dead laptop halfway through Death Valley.

The secret sauce here isn’t working faster, it’s working smarter. Jordan González Bustamante  nails this with their prioritization advice: “Given the time, you will have to prioritize to know what NOT to do to reach an MVP.” This tracks - sometimes the best choices in building are the things you chose not to build.

Bottom line: The bus is a deadline! The contestants can’t pull an all nighter, or ask for an extension. The finish line is where the bus stops at Midday Madness , so time box ruthlessly, keep your team fed and caffeinated, and remember what Joanne Skiles  says: “The magic usually happens in the messy middle, when you stop trying to make it perfect and just build.”

And if you're new to hackathons? Mike Graff  calls it like it is: "This will be my first ever hackathon, so I'm not sure I have lots of good advice to provide. My plan is to approach the event with an open mind and positive attitude, and try to figure out as quickly as possible where my skill set will complement the capabilities of my teammates." Sometimes the best prep is just showing up and being ready to learn with your team.

When you’re coding on a moving bus, the last thing you want is to fight with your tools. Jordan González Bustamante  puts it bluntly: “Don't try new tools which you have never touched before... stay in a comfort zone where it is possible.” This isn't time to learn rust from scratch, or experiment with that shiny new framework you saw on Hacker News yesterday.

Instead, Shitij Mathur  suggests getting your environment dialed in ahead of time: “I make sure my IDE is fully configured and I usually have an EC2  server running as well as boilerplate API code ready.” This is a smart move - you want to spend your precious hours building cool things, not debugging your dev setup.

For AWS-specific prep, Robert Berger  keeps it practical: “I'm planning to go through AWS hands-on workshops related to the realms of the hackathon.” And Harpreet Siddhu  has some solid advice on service selection: “Leverage managed AWS services like Lambda , DynamoDB , and API Gateway  to move fast and stay serverless.”

Speaking of moving fast - Infrastructure as Code isn’t just for production. Shaoyi Li  recommends preparing “key Infrastructure-as-Code (IaC) templates” beforehand, and building security controls right into them. Speaking from experience, nothing derails a smooth demo like hitting a permissions wall you didn’t see coming, so this is a good tip!

And since we’re in 2025, AI is your friend here! Michael Walmsley  reminds us to “Choose your AI companion and know how to make them work for you!” Whether it’s Kiro , Bedrock , or other AI tools, get comforatable with them before the clock starts ticking. When it comes to working with Kiro , Jason Wadsworth  has a practical approach: "I like to make sure I have steering documents in place. Anything I know in advance I get into the documents. If I'm not sure, I create variations so I can pick the best one when it's time to go." This kind of prep work can save precious minutes when you're trying to get consistent results from AI tools under pressure.

Some builders are taking their prep even further. Nadtakan Futhoem  is planning to "live-stream or create a video... covering all the tools and knowledge related to AI. In this case, it would be Kiro , and Bedrock ." Nothing forces clarity like having to eexplain something on camera - trust me, I know this firsthand.

Jones Zachariah Noel  makes a key point about AWS service selection: “It's not about overloading with different AWS services but rather choosing what's really best for your architecture.” In other words, don't try to cram every service from the AWS console just to look clever. Pick the right tool for the job, and make sure it works.

The theme here is clear: preparation beats improvisation. As Jeremy Redmond  suggests, “brush up on the likely tech stack, if it is AWS, skim core services like IAM , Lambda , API Gateway , S3 , and CloudWatch .” Because when you’re coding from the highway, you don’t want to be googling basics, you want your tools to feel familiar, reliable, and ready.

The best hackathon projects usually start with curiosity, not code. Bansi Delwadia  puts it perfectly: “Take some time to truly understand the problem before you start building; that’s where most great solutions begin.” This isn’t just good advice for a hackathon, it’s good advice for engineering in general.

But, you can’t overthink things either. Joanne Skiles  has a good take on this: "Don’t stress. Seriously. Hackathons are meant to be fun, and scrappy, not perfection."

This balance between thoughtful planning and scrappy building is key. Bhuvaneswari Subramani  pushes us to: “Go beyond surface fixes. Ensure your solution is comprehensive: dig deeply into the existing pain points.” But, Danielle Heberling  reminds us to keep perspective: “No need to prepare ahead of time, just show up and have fun! It's more about the idea and how you sell it.”

So how do you actually get into that creative headspace? Fernando Pena  swears by low-tech prep: “In the days leading up to the event, I recommend doing exercises that stimulate your creativity, such as brainstorming, mind-mapping, and free writing.” They even suggest stepping away from the screen: “Activities like hiking, walking, and spending time in nature will help clear your mind.” Which is solid advice in general, but especially useful if you’re about to spend several hours debugging on a moving bus.

And if you’re the type who likes to walk in with a plan, Shitij Mathur  has a smart twist: “Combine prep with a learning goal... I always try to pick one new technology... I'm guaranteed to walk away with a valuable new skill, regardless of the results.” This is a nice mindset shift from “Did we win?” to “What did I walk away with?”

For AWS builders, Harpreet Siddhu  suggests grounding your thinking in something bigger: “Align everything with Amazon’s Leadership Principles - Customer Obsession, Bias for Action, Ownership...” But don’t feel like you need to sound super corporate, it’s more about staying focused on the problems and moving fast, not checking boxes.

The point here is that your mindset is part of your stack. Whether you’re team “just show up and hack” like Danielle Heberling  or prefer Shitij Mathur ‘s structured prep, there’s no one right way. Stay curious, stay flexible, and remember - sometimes the best ideas don’t come from the whiteboard, but from the middle of a half-broken prototype and a shared bag of sour worms.

The beauty of these tips is how they re:Inforce each other. A well prepared team manages their time better. Comfortable tech choices let you focus on creative thinking. And when your thinking is clear, your team communication flows better. It’s a virtuous cycle.

But here’s what really stands out from all these builders’ advice: hackathons aren’t about perfection. They’re about possibility. Whether you’re Jeremy  debugging with a Lego minifig, or Michael  fueling their team with snack-driven development, or Shitij  turning prep into a personal learning sprint. The goal is to build something cool, and have fun doing it.

I’ll be following the Road to re:Invent  with Farrah Campbell  and AM Grobelny  as we livestream the whole adventure. Will Shitij’s  pre-configured environment save them time? Will someone forget Rini Susan V S ’s advice and run out of laptop power in the desert? Or will Danielle ’s “just show up and vibe” philosophy lead to a breakout hit?

There’s only one way to find out! Keep an eye out on AWS social channels for stream details, and maybe grab some of Shaoyi ’s recommended snacks for the show.

I won’t give out any spoilers yet, but I will say this: tune in! You’ve now heard a little bit from the builders who will be competing, so ask yourself: whose approach feels like yours? The meticulous planner with templates ready? The team-first collaborator? The collaborative optimists? Find your champion and cheer for them in the Road to re:Invent Hackathon!

See you on the stream, and at re:Invent! 

- Brooke