In April, during a company offsite, Hugo pitched an idea that would improve how Swarmia links work across tools. Knowing whether a pull request is related to a particular issue can be tricky, and the more time passes, the higher the chance that you no longer remember what it was related to — unless you search using the exact keywords used in the issue.
Hugo’s solution was semantic analysis using AI — to understand what the PR is actually about, and matching it to a related task on the board. He had two days to build it.
Come Friday afternoon demo time, he had a working prototype. A few weeks later, customers were using it in production. Even though I watched it happen in real time, it still surprised me how quickly we went from idea to running it in production.
When most hear “hackathon,” they picture developers hunched over laptops at 3am, fueled by energy drinks and determination: a sprint where you sacrifice sleep to ship something that’ll probably never see production.
We’ve taken a different approach. Our hackathons happen at our bi-annual company offsites, when the entire team gets together. And everyone gets to participate, not just engineers — product managers, designers, customer success, legal, marketing. If you work at Swarmia, you’re joining a hackathon team.
Anyone can pitch an idea. We hear all pitches in one session, which easily takes an hour. Then we vote with our feet on what to build. People form teams around the ideas that get traction, often working with colleagues they don’t normally collaborate with.
There’s no pressure to ship production-ready code — that’s not the point. A good hackathon is measured by the number of experiments you run, not the number of features shipped. Some projects become customer features, some become internal tools that save us hours every week, and some teach us something valuable even if we never use the actual output.
Hugo’s AI work linking tool is just one example. Other customer-facing features born in hackathons include annotations, sprint analytics, and countless other small improvements that make the Swarmia product experience better.
Then there’s the more… left-of-field hackathon projects. One of Swarmia’s features, work log, helps teams identify activity patterns over a longer time. Essentially it’s a heatmap where projects are rows, and each cell is a week, showing one year of work in a single view. It answers questions such as: are we completing work before starting something new? Are there anomalies in how long projects take? A healthy-looking pattern looks like a staircase, and a more chaotic one… we thought it looked like one of those beginner piano tutorials.
So here comes the high-level work log piano mode. Click the 🎹, and you’ll hear your team’s engineering activity turned into music — commits become notes, pull requests become chords, different types of work create different sounds. Now you can know what great team work sounds like 🎶
We’ve also built plenty of internal tools that save us hours every week: a legal assistant that reads contracts, improved performance testing, better onboarding dashboards. Plus experiments that taught us valuable lessons, like our only half-serious attempt at creating “one metric to measure developer productivity” — which failed perfectly, reinforcing why there’s no single number that captures the complexity of software development.
The biggest barrier isn’t technical for most companies, but cultural. Many companies say they want innovation, then make it nearly impossible.
“We can’t stop regular work for two days.”
But you’re already losing time to context switching and unproductive meetings. Two focused days twice a year is cheaper than several months building something nobody wants.
“It’s just one more thing to organize.”
Yes, but when you give people dedicated time to experiment, experiments actually happen. When you don’t, they don’t.
The deeper issue is control. Leadership wants ideas to go through proper channels — product validates, engineering estimates, everyone aligns on priorities. The process becomes the bottleneck.
We aim to skip most of this, and get straight to building. People pitch directly to the whole company, form their own teams, and tackle problems they actually care about solving.
What makes our hackathons work are the same things that power our feature collaboration day to day, and that also enable our vibe-coders to be effective.
Everyone at Swarmia has a GitHub account, and we make sure everyone is comfortable making small contributions — even if it means just updating a tooltip or moving a button two pixels up. We make it easy for everyone to set up their local development environment and test concepts with real data. We generate preview builds for each pull request, making testing easy and shortening the feedback loop. Features can be tested in a sandbox environment or enabled only for specific customers
We also invest in component libraries, a design system, and documentation, going as far as having a linter that enforces every color in the app uses a design system variable — helping to stay on-brand even without having designers involved.
All this also makes threshold low even for ‘non-technical’ people to contribute. Product managers can vibe-code end-to-end product features. Customer success can build internal tools. Marketing folks work on data analysis.
You end up understanding other parts of the company and building relationships that matter when you need to collaborate later. Plus, fresh perspectives lead to solutions nobody would have thought of working in their usual silos.
The obvious benefit is shipping faster. But there are less obvious ones too.
We don’t treat hackathons as separate events — they’re built into SwarmUp. This makes planning and budgeting straightforward. We fly the entire US team to Finland for SwarmUp twice a year, everyone gathers to discuss strategy, share learnings, and run a hackathon.
We indeed do some prep work beforehand — looking at customer feedback, identifying pain points, making sure the development environment is ready for the influx of vibe coded PRs. But we’re careful not to over-structure things. The ideas still need to come from the teams.
Demos happen on Friday, with no pressure to present something that didn’t work out. Some projects ship immediately. Others join the backlog as proper epics. Some stay as prototypes that inform future decisions. And some become inside jokes we reference for months.
The lack of pressure is crucial. Most projects shouldn’t ship immediately, and that’s fine. The goal is experimentation, and you can’t experiment when failure has consequences.
It’s worth noting that hackathons aren’t the only time people can experiment at Swarmia. We reserve time for exploration in regular times, and nobody needs permission to experiment with new concepts. Our processes are set up for experimentation, for example, by using feature flags make it safe to test early ideas with real users.
One example of a ‘what if…’ moment that turned into a feature our customers use daily is search in Swarmia. You can hit ⌘K and find any work item (pull request, issue, story, you name it) or go to any Swarmia page within seconds. Super handy for those “I know Jim worked on something to do with xyz, but I can’t remember when or where the issue is” moments.
Often times, there’s a big gap between “I have an idea” and “this is working”, with rounds of meetings and planning cycles in between. We aim to compress that gap to days or even hours, which changes what people are willing to try.
Most companies accidentally make innovation difficult. They create systems designed to prevent exactly the kind of rapid experimentation that produces real progress. Then they wonder why nothing interesting happens.
The solution is often simpler than it seems: give people time, trust them to identify important problems, and let them try out new things.
Next SwarmUp is in a few months time. Someone will pitch an idea that sounds impossible. By Friday, they’ll demo something that works. And a few weeks later, our customers will be using it.
Sometimes creating the right environment is all it takes.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
