����ɫ��Ƭ

It was a spring day in Tallinn, Estonia, and I had been at ����ɫ��Ƭ for just over a month.

I kept looking around at this team of smart, thoughtful people and wondering why they hadn’t done a hackathon yet. I’d run plenty of them before, in all kinds of formats, and I’d seen what they could do: shake people out of their usual routines, get ideas moving fast, and give teams a different way to think about the product.

After talking with people across the company, I felt pretty sure a hackathon would work at ����ɫ��Ƭ too. The interest and curiosity were there. What we needed was a way to make it happen at the right time, with the right shape, so people could actually get behind it.

The pitch

I reached out to the product team and leadership with a simple idea: define a theme, give the team a couple of days, let them pick their own projects, and execute.

From the very first exchanges I understood that the team was ready. People engaged fast and went straight into the details. The product team just wanted to make sure we weren’t disrupting planned work, and I completely agreed that this had to land outside our core work.

From past hackathons, I’ve seen that it works best when you show the direction we’re moving toward and allow teams to own what they think should be built to get there. When folks choose what to build, they start thinking more like product people.

The strong support I got made it easy to move forward and work out a plan that would fit the team.

What I really loved about this process was what it said about the company. Someone can join, share their ideas and perspective, and if there’s real depth there, people are ready to hear it and act on it.

‍

Designing the theme

The idea was to keep the bar approachable: take a vision you have for ����ɫ��Ƭ and bring it to life as a simple proof of concept. Keep it lightweight, but make sure the value and potential come through. The goal was to get as many ideas in the air as possible so we would have a bank to explore in the year ahead. We were not looking for finished products, we were looking for sparks, and so the theme was born: the first spark.

We gave teams a few sparks to get them thinking:

• Saving customers time—automate repetitive tasks, reduce complexity. Can we make five clicks into one?
• Improving resource management—anything that can make resource management faster, easier, and more accurate.
• Saving us time—improve internal processes, simplify over-engineered code.
• Adding delight—the highest level of UX. It’s what separates us from the competition.
• Anything else that qualifies as a first spark.

Kickoff from 30,000 feet

As we planned the hackathon to take place at the start of our annual ����ɫ��Ƭ meetup, it meant dealing with some pretty complex logistics. When people are flying in from all parts of the world, timing gets tricky. So we did what we do best and kicked things off online and async.

I set everything up from my laptop at Abu Dhabi airport, scheduled the kickoff announcement to go out in Slack, and jumped on my flight to Australia. While I was crossing the ocean, probably asleep, the kickoff landed, and by the time I touched down most of the projects were already announced and being built.

What happened next surprised even me. Marketing showed up, and instead of just watching from the sidelines, they too started building one project after another. In a hackathon I expected to be engineering-dominated, 26% of all submissions came from the marketing team. That wasn’t something I saw coming, but I loved it.

The team dove into bold problems, sometimes too bold for a two-day window, but that’s part of it. You aim high and see how far you get. In two days, we had 20 projects on the table, and over a quarter of them involved some form of AI.

From spark to value

Not every hackathon project makes it past the finish line, and sometimes those can be the most valuable ones. But several projects from the first spark are already out in the wild delivering real value.

One team built new display options for the Projects page, including a column picker and margin mode selector inspired by existing UX patterns used elsewhere in the app. It filled a clear gap in the experience and went live before the hackathon was even over. Shipping something to production in two days is rare, and customers benefited from it right away.

The marketing team built a ChatGPT-powered bot that learns from voice and vision. It helped with a real bottleneck, how to scale one of our most limited resources, our CEO’s time. The team still uses it daily for inspiration. As a bonus, building the bot led to a second tool: a website copy scraper built in Lovable that exports any page’s content in both text and HTML.

Then there was the Planning Copilot, a conversational AI agent that drafts projects with phases, milestones, and allocations while you sit back with your coffee. It was built to explore what’s possible with MCP and agent frameworks, and it’s a good example of the kind of spark we were after, a proof of concept that opens the door to something bigger.

Another team built a demo app showing real-time sync between ����ɫ��Ƭ and external tools using webhooks. When people were created or removed in ����ɫ��Ƭ, the changes appeared instantly in the connected app. They built it on top of our existing live update infrastructure, showing that webhook support could be a natural extension.

These were just four of the twenty projects submitted. The remaining sixteen ranged from data visualizations to internal workflow tools, each one a spark in its own right.

‍

The numbers tell the story

Here is what two days and the freedom to build produced:

• 20 projects submitted
• 26% of them built by the marketing team
• 26% included some form of AI tooling
• 1 project shipped to production during the hackathon itself
• 3 tools entered internal daily use
• 9 proof of concepts gave us ideas we can build on.

We ran a feedback survey after the event and the results were clear. On a scale of 1 to 5, motivation scored 4.70, the hackathon helping generate new ideas scored 4.60, learning something new scored 4.30, and the likelihood to participate again was highest at 4.89. When almost everyone on the team wants to do it again, you know it’s worth repeating.

Notes for next time

The feedback we received will make the next hackathon better, which is the whole point.

Two days was too short. Teams needed more time to gather ideas, form groups, plan, and then actually build something. Several people suggested releasing the theme a day earlier to give more room for ideation and team formation. Next time we’ll plan for more runway.

The voting process was where we struggled most. Having twenty projects was a great problem to have, but it meant voters had to review all of them before deciding, and with a packed meetup schedule that was a lot to ask. For the next round we need bigger teams, fewer projects, and a simpler way to pick a winner.

‍

The next spark

When I first pitched the hackathon there was some hesitation around whether it would deliver enough value. Twenty projects and a 4.89 out of 5 “would do it again” score settled that.

The next challenge now is finding the right focus and letting the team run with it.

The next hackathon is already in the works and we want your input. If you use ����ɫ��Ƭ and have an idea that would make your day easier, send it our way. It might end up being something a team picks up and builds.

And if reading this made you think “I want to be part of this,” keep an eye on our . We’re always looking for people who want to build things that matter.