A 48-hour hackathon example for engineering teams… exactly how we ran ours

The AI landscape is moving so quickly that the gap between acquiring a new tool and actually mastering its implementation is wider than ever. While most engineering teams are eager to bridge this gap, the reality of the standard product roadmap often leaves zero room for the deep, focused experimentation required to do it right. 

When learning gets squeezed into the margins between tickets and meetings, progress stays fragmented and shallow. What teams really need is a clear container: focused time to explore how new tools can save time, reduce effort, and actually make their work better.

To create space for this kind of focused learning and experimentation, our engineering team ran a 48-hour AI hackathon. The goal wasn’t to fix bugs or clear the backlog; it was to try new tools and use cases that aligned with the team’s learning goals. Here’s how we structured the sprint and what came out of it.

Summary: An R&D-focused hackathon example

• The core goal: Learning. This was the first hackathon in a multi-part series designed to give the team a chance to explore the technology on their own terms.
• The hackathon challenge: Devs were challenged to build a functional feature that moves beyond simple string-in/string-out interactions by mastering the engineering behind structured, repeatable, and reliable LLM outputs.
• The approach: The engineering team chose the hackathon focus areas together so the sprint was meaningful and valuable for everyone involved. By hosting the challenge on our private internal hackathon platform, they were able to centralize documentation and keep the entire company updated on their progress in real time.
• The result: Projects were shared company-wide, and within days, other teams had looked into stress-testing a feature for our platform. Projects had real potential across the company—from new features on our platform to an MCP (Model Context Protocol) setup to help our marketing team. 

The hackathon’s technical focus 

While many focus on the “magic” of LLMs, this session was about mastering the engineering behind the curtain. The hackathon challenge pushed our developers to prioritize raw API implementations over simple, free-form text inputs. The goal was to produce structured, repeatable, and reliable interactions with LLMs.

To do this, the hackathon challenge was centered on core orchestration: specifically, how we manage prompt versions and enforce structured data formats.

• Prompt management: Moving prompts into structured templates or logic-driven builders. This allows for better version control and the ability to change between versions without a full redeploy.
• Output parsing: Forcing the LLM to return data in formats (like JSON) and building the internal logic to handle malformed responses. This ensures the app stays stable, even when an LLM becomes unpredictable.

The approach: Two tracks for experimentation 

We’ve found that the best hackathons strike a balance between clear goals and creative freedom. While parameters are necessary for focus, developers also need enough flexibility to dive into the specific tools or use cases they want to master. If you’re researching how to run a hackathon for your own team, this balance is key to high engagement.

The dev team followed this advice and provided two different paths:

• Path A: Building directly into the application to test real-world integration.
• Path B: Developing a tool/product from scratch (i.e., a greenfield system) to evaluate the tools without constraints.

This approach ensured that every developer could work on a project that best suited their personal learning objectives. 

{{callout-1}}

Technical retro to share the real story 

After two days of focused experimentation, the team wrapped the hackathon with a technical retro to share what they learned. This was less about polished presentations and more about the real story of their builds, giving each dev a chance to walk the team through their projects while highlighting the experiments that worked and the challenges they uncovered. 

Since project details were already accessible on the Devpost for Teams platform, the retro didn't need to be a formal presentation—it became an open forum for honest feedback and shared learning.

The impact of focused R&D 

This hackathon example shows how a multi-part series can have an impact within days:

• High engagement: Every participating developer submitted a functional project within the 48-hour window.
• Immediate value: Since the project documentation was easily accessible on our platform, other teams were able to almost immediately begin stress-testing one of the hackathon features for our platform. 
• Future-proofing: The team had the headspace to tackle the challenges they found most compelling, leading to a deeper, more personal mastery of the tools.

When a talented team is given the structured space to experiment, the result isn't just new features—it’s a long-term toolkit for the team to draw from for more robust and sophisticated AI integration.

{{callout-2}}

Empower your team to build the future 

We all know the value of professional development, but it’s hard for teams to make it happen during a busy sprint. We’ve found that the structured environment of a learning hackathon is one of the most effective ways to bridge that gap. It’s been a rewarding process for our team, and it’s a framework we’ve seen other engineering organizations find just as valuable.

Want to learn more about planning an internal learning hackathon? Check out our Devpost for Teams platform or talk to our team to get started.