Three Days, No Blockers: How We Hack at Lunar

Once or twice a year, Lunar does something that looks slightly irresponsible on paper.

We empty out the offices, pack cars with laptops, garden pavilions, sound systems, cables, snacks, and whatever else someone has decided is essential. Then we drive a good chunk of the company to a camp somewhere green, give everyone three days, and remove most of the rules that usually shape how software gets made.

The question is simple: what would you build if the usual blockers were gone?

That is a Lunar hackathon. No roadmap. No refinement meeting. No waiting for a quarterly planning slot. There is one real constraint: whatever you build should matter to Lunar in some way. After that, it is mostly up to the people in the room.

The format is deliberately loose

We do have categories and prizes, but they are there to nudge people, not box them in.

WTF -> WOW is for the thing that makes you mutter at your screen every week, turned into something simple.

That shouldn't be your job is for the manual task that somehow became someone's recurring responsibility.

We never got round to it is the drawer full of ideas people keep saying would be useful "when we have time".

The mechanics are low ceremony. At kickoff, anyone with an idea gets around 15 to 30 seconds to pitch it. People walk around, ask questions, find the thing they want to work on, and form teams. Three to five people is a good size, but nobody stands there with a clipboard.

Then we hack.

There is one important rule: the work happens during the event. You can research, install tools, and prepare your machine beforehand, but you do not start building early. If your hack builds on existing work, you are expected to be clear about what was already there and what you actually made in those three days.

On the final morning, every team demos. The timer is real. Depending on the number of teams, each group gets somewhere between two and a half and five minutes. One year we had 25 demos, so there was no room for long preambles. You show what you built, explain why it matters, and hope the room gets it quickly.

Voting happens straight from the Lunar app. Winners get a modest per-person budget to do something together afterwards: dinner, drinks, laser tag, whatever the team wants. The prize is nice, but nobody comes for the prize.

What makes a good hackathon idea

The best ideas are usually not the biggest ones.

That was a little unintuitive to me at first. When you give people three days without the usual blockers, it is tempting to think the winning idea should be a moonshot. Sometimes it is. But the ideas that travel best through a hackathon tend to have a much sharper shape.

They start with a sentence everyone understands.

"Customers call us because they missed this notification."

"This manual task keeps landing with support, even though nobody thinks it should be support's job."

"We ask business customers to type the same payment information again and again."

That kind of idea is easy to rally around because the pain is visible. The team does not spend the first day debating whether the problem exists. They can spend it making the first useful version.

The second trait is that a good hackathon idea has a narrow first slice. Not the full system. Not the perfect product. Just enough of the experience to prove that it feels right. For account automations, that meant showing money arrive, a rule trigger, and funds move. The demo did not need to answer every edge case around limits, rollback, audit trails, or customer communication. It needed to make the underlying idea concrete enough that people could react to it.

That is also where the three-day constraint helps. It forces teams to decide what the actual point is. If the idea only works after six weeks of foundation work, it might be a real project, but it is probably not a great hackathon project. If the idea can be demonstrated with a thin slice and a few honest caveats, it has a chance.

The third trait is ownership. Not permanent ownership, necessarily, but someone has to care enough to keep explaining the problem when the team gets distracted by implementation details. The idea-owner role matters because it stops a hack from turning into "what can we build quickly?" and keeps it closer to "what problem are we trying to make less painful?"

The setting matters more than I expected

We could run this in a meeting room. For the summer hackathons, we deliberately do not.

One year we were at Fjeldholmlejren near Grenaa. Another year we went to an outdoor centre near Ry. The exact place changes, but the pattern is the same. The people building prototypes at midnight are also the people carrying groceries, filling water tubs, moving tables, and cleaning up before the bus leaves.

That sounds like logistics, but it changes the event.

In the office, people naturally sit with their squad. At camp, the seating chart falls apart. A support specialist ends up next to an engineer. A product manager joins a group they normally would not work with. Someone from a business-facing team explains a customer problem in the same room as the person who can build the first version of a fix.

That is where a lot of the best ideas start. Not in the pitch round, but in the half-hour between lunch and hacking, or while someone is looking for a charger, or when a team is stuck and someone from another table wanders over.

The off-hours are not a side quest. They are part of the format. There are runs where all levels are welcome and at least one person still treats it like a race. There are lake swims, bodyweight workouts on the lawn, beer tastings, quizzes, snacks by the fire, and at least one overcommitted food plan.

Sometimes the food plan is a whole roast pig. Sometimes the most important infrastructure is a row of hot tubs and a pile of towels.

It can look like chaos from the outside. In practice, it is how people get enough shared context and trust to build something useful very quickly.

The year AI changed the event

In April 2026, we tried a different version: a Hack-AI-Thon in the Aarhus office.

The summer hackathons are broad and off-site. This one was agent-first. The brief was not "ship the most polished product". It was to use AI actively throughout the process and notice what changed.

That mattered because Claude had just been rolled out across Lunar. The event became a practical on-ramp for the whole company. There were setup sessions, experiments with AI personas, and a live session with people from Anthropic. One of them joined the demos to see what people had built.

The energy was different. Less campfire, more "what happens if we point this at a real workflow and keep pushing?". Some teams went for big, agent-native ideas. Others built small, weird, useful things.

One team made an occupancy sensor for the bathroom near their squad. It came with a very serious privacy note: the cheap radar sensor could not identify you, only that someone was in the room. That is exactly the kind of hackathon project I like. Slightly silly, genuinely useful, and specific enough that everyone understands the problem in two seconds.

What worked about the Hack-AI-Thon was not a single winning demo. It was watching a lot of people pick up the same new tool at the same time, compare notes, and figure out where it was actually useful in their own work.

Some of it really ships

We should be honest here: a lot of hackathon output is throwaway fun. That is fine. Not every idea needs to become a roadmap item.

But some of it does turn into real product work.

The clearest example is account automations. The first version appeared as a hackathon project in 2024: a rule engine that could automatically move a percentage of incoming money from one account to another. In three days, the team had an end-to-end version working across app, Android, and web. Money came in, a rule fired, funds moved. The project came second.

It did not disappear afterwards. In 2025, the idea came back as new automation savings rules, this time with a more thought-through design and prototype. By 2026, account automations with dynamic rules was one of the winning projects.

That three-year arc is probably the best argument for why we keep doing this. A rough demo can be enough to make an idea visible. Once it is visible, people can react to it, improve it, and decide whether it deserves proper product attention.

The important word there is "decide".

We do not ship a hackathon project just because it got applause on demo day. That would be the wrong lesson to take from the event. A prototype can show that an idea has energy, but production still has to answer boring and important questions.

Who owns it after Friday? What happens when it fails? Does it need customer support material? Is there a compliance angle? Is there an audit trail? Does it create a new operational responsibility for another team? Can the design survive real customers doing real customer things?

In a regulated product, those questions are not paperwork. They are part of the product. The hackathon is allowed to skip them for three days because skipping them is what creates speed. But the follow-up cannot skip them. That is the trade-off we have to be honest about.

What the hackathon gives us is not a finished feature. It gives us evidence. Evidence that the problem is understood. Evidence that someone can imagine using the solution. Evidence that a team had enough energy around the idea to make something real under pressure.

Sometimes that evidence is enough to start a proper product conversation. Sometimes it is enough to say "fun demo, not worth the cost". Both outcomes are useful.

The 2026 summer event also changed in another important way: we opened the hackathon beyond the tech org.

That brought in a different kind of idea. Support teams arrived with problems they hear from customers every day. Business-facing teams brought internal friction that engineers do not always see. Because those people were in the room, teams could build against real examples instead of guessing from a distance.

Some of the ideas were small and sharp: make critical in-app notifications harder to miss, so customers stop calling about something the app already tried to tell them. Add a view-only role to business accounts, so an accountant can see data without being able to move money. Let Swedish customers save payment recipients instead of typing the same invoice details again and again. Automatically apply a promised discount when a business application is approved, so the first email has the right price.

None of those are abstract innovation theatre. They are the kind of work that makes a product feel less annoying.

Why opening it up changed the quality

Opening the event beyond tech made the hackathon less tidy, in a good way.

When a room is mostly engineers, the ideas often start from systems: workflows, internal tools, technical debt, clever automation, better developer experience. Those are valuable. Some of them save a lot of time. But they are still filtered through what engineers notice.

When support, operations, product, commercial, and other teams join, the idea pool changes. The starting point becomes more direct. A customer asks the same question for the tenth time. A colleague copies data between tools because the right integration does not exist. A business owner cannot give their accountant access without giving too much power. These are not abstract "opportunities". They are small repeated frustrations with names attached.

That changes the way engineers behave too. It is harder to disappear into a neat technical solution when the person who feels the problem is sitting next to you. You get corrected earlier. You hear the exact wording customers use. You learn which part of the problem is annoying and which part is just how the process works.

It also makes demos better. A team can stand up and say, "this is the thing our customers call about every week", and the room immediately understands the stakes. The story is already there. The demo just has to make the improvement visible.

I think that is a healthier version of autonomy. Autonomy is not everyone quietly building whatever they personally find interesting. It is the ability to act on good context. The wider the room, the better that context gets.

What I think we are really testing

A hackathon is not only a way to find feature ideas. It is a way to test whether we still know how to move quickly together.

Can someone with a painful customer problem find someone who can build? Can a team make a good enough version without waiting for the perfect design? Can we tell the difference between a fun demo and something worth pursuing? Can we make space for work that matters but never quite fits into the normal planning process?

The answer is not always yes. Some projects are too broad. Some demos only make sense to the people who built them. Some ideas should stay as jokes. And three days can hide a lot of hard questions around reliability, compliance, ownership, and maintenance. We are still a bank. The shortcut ends when the hackathon ends.

But that is also the point. The hackathon is not production. It is a fast way to learn what might be worth the slower, more careful work afterwards.

The best projects leave camp with more than a demo. They leave with a story people remember, a real problem attached to them, and enough evidence that someone is willing to ask, "should we actually do this?"

That is why we keep packing the cars.