All Articles

The rolling hackathon

Contrary to popular belief, Europe does not suffer from a capital shortage for funding technology startups. There’s ample early-stage money available—both in VC funds and angel networks. Instead, Europe’s core challenge is a shortage of ambitious, execution-driven founders paired with zero-to-one talent. Europe lacks environments where talented people can rapidly iterate, experiment hands-on with technology, learn the culture of collaboration, and form robust founding teams. Torsten Reil, co-founder of Helsing, recently argued along the same lines.

I’m writing this from Warsaw, where the problem is particularly pronounced: we have strong specialist talent but very little product and technology business experience paired with the right mindset (ambition). How do we change that?

My current best idea is a rolling hackathon: a recurring, 10-day event.

Why a 10-day event? If the goal is to nurture talent, agency and teach people how to form high-quality teams, 48-hour, Red Bull-fueled sprints are not the answer.

A weekend hackathon can teach you how to build fast. A 10-day hackathon teaches you how to work in a team, iterate on an idea, and solve real roadblocks. The extra days give people time to hit obstacles, struggle, and actually push through—something that doesn’t happen in 48 hours. This is especially critical in an ecosystem that doesn’t (yet) have strong rapid prototyping experience.

The current state

To have a thriving ecosystem of startups that later have a chance to graduate into larger companies, you need two things: ambitious and competent founders, and zero-to-one talent—engineers, designers, early sales, and other doers. Some argue that capital is also essential, but capital finds appealing opportunities rather quickly.

The weaknesses I see at the moment are that technical founders in Europe (and Poland, by extension) are too slow, overly theoretical, and lack product skills (e.g., narrative writing).

There are few good ways to find serious, skilled co-founders. You either meet them at school or work—but in CEE, where strong product/tech outposts are scarce, this isn’t enough. There are very few “third spaces” for cofounder matching and zero-to-one talent growth.

On the VC side, I find local VCs lacking necessary technology exposure to ask founders the right questions. This is especially pronounced in emerging areas. I see this a lot in AI I do know well: most of the content VCs put out clearly lacks contact with reality, and I think the underlying reason is that European VCs aren’t exposed enough to people building real things and seeing what actually works, and what doesn’t.

If Europe’s problem isn’t capital, but a lack of high-speed execution and founder matching, how do we fix that?

Rolling hackathons as zero-to-one seedbed

I get the skepticism—hackathons often feel like a gimmick. Most don’t lead to lasting projects or companies, and many feel more like shallow hangout events than serious building opportunities. But that’s exactly why this format is different.

The rolling, 10-day hackathon would address two main traditional weaknesses of hackathons:

  • They’re too short for building anything substantial; this is especially pronounced in the ecosystem that doesn’t (yet) have rapid prototyping experience
  • One-off hackathons don’t shift the culture — they merely ride the existing one

In other words, if you already have top-tier tech talent and culture like the Bay Area does, weekend hackathons are okay. However, if hackathons are supposed to be an agent of change, we need a different approach. Hence, rolling 10-day hackathons that:

  • are long enough to build something substantial, figure out team dynamics, etc.
  • are recurring which means they can constantly push people up, and establish a community
  • encourage cross-pollination of knowledge with friendly co-competition (more on this below)

I’d argue that community is the medium of cultural shift. If you don’t have community, you have no change.

Right now, Poland has great engineers, but no strong founder network to accelerate them. This hackathon should be that missing piece—an ongoing space where talent naturally gathers, levels up, and finds co-builders.

To illustrate exactly how this could look in practice, let’s dive into a concrete example format.

The focus

I believe the final outcome of a series of hackathons should be a community of highly skilled doers and thinkers (to echo Steve Jobs’ famous quote, these are the same people). Hackathons should be a place to meet other high-agency people, kick around ideas, and develop skills. Some of these people might go on and become founders, others might join startups. The focus should be on teaching a basic lesson: competition is good, and hard work combined with ingenuity pays off with a prize beyond audience applause.

To achieve this, I think a few core principles would be helpful:

  • Cyclical, Not One-Off: The hackathon is held every two months, ensuring an ongoing talent pipeline and community building.
  • Avoiding the “Pitch Deck Warriors” Problem: The event is explicitly designed to filter out those who are great at talking but weak at building. Live demos are required—no slides, only working prototypes.
  • Team Formation & Refinement: Individuals can reshuffle between events, enabling better matching over time. Perhaps there could even be a way to reshuffle mid-week.
  • Serious Prizes for Serious Work: ~$15K prize per event ensures strong participation and effort.
  • No Strings Attached: Open to all (including indie hackers), no equity or ownership claims, and no corporate recruiter access.
  • Existing Teams Welcome: teams pre-strong PMF — with less than $300k ARR — are welcome. If one of the goals is to learn from peers, folks later in their journey are invaluable.
  • Friendly co-competition: Teams should be encouraged to help each other with common challenges while competing. When everyone struggles with the same problem (e.g., how to scrape some data) and makes little progress, the quality of final demos suffers—everybody loses.
  • English-only from day one: to counter Europe’s Achilles’ heel: tech fragmentation
  • Highly experiential execution: test out ideas from first principles in practice instead of merely copying best-practices with hackathons (those should be studied too!). Europe is prone to overintellectualizing; instead of having a grand plan, have an experimentation playbook.

The format

How would the 10-day format work in practice? I think it should look roughly like this:

  • Weekend 1 (Kickoff & Build): Teams form and start hacking.
  • Midweek (Check-ins & Technical Mentorship): Tuesday/Wednesday in-person check-ins with mentors and peer sharing. These check-ins should focus on unblocking stuck teams, ensuring they don’t fizzle out midweek.
  • Weekend 2 (Demos & Prizes): Final demo presentations, judged purely on execution and product quality.

The first weekend is for the kickoff, then people can hack every evening during the week with a midweek check-in to sustain momentum. In-person finishing happens on Saturday, with demos and prizes on Sunday.

This setup would allow people with day responsibilities (jobs, school) to participate and, given the 10-day span, build something substantial. In particular, the longer timeframe would let teams clear the basic demo, hit a wall, and actually overcome it.

The prize should be big enough to justify 10 days of intense work. It’s easier to tell your partner, “I need to lock down for 10 days” when there’s a real prize on the line—not just audience applause.

Organizing team should include technical people

I’d like to float one more idea: some people on the organizing team should be technical—specifically, they should know how to code. Why? Two reasons come to mind:

  1. Only technical people can prep templates, starter guides, etc. This material is essential so the teams can get going quickly with differentiated value (the idea they work on), instead of spending time on non-differentiated discussions of the tech stack.
  2. Technical people can build tooling for the participation. E.g. imagine a slackbot used for logging the time when someone was particularly helpful for solving some problem. This kind of karma should be recorded and rewarded (e.g. with community prize?), but to do this well you need some custom software.

The budget

If the hackathon happens every two months (perhaps with the first two editions spaced six weeks apart to iterate faster on the format), we’re looking at seven editions per year. Prize money would total 7 * $15K = $105K.

We should assume at least one non-technical person working full time on this project and one technical person (a software engineer). This kind of operation can’t rely on volunteers’ effort alone—I might be stating the obvious, but you’ll get what you pay for. Volunteer-run hackathons tend to deliver more of the same events people are skeptical of as agents of change for tech ecosystems. I agree that a median-quality hackathon will have little impact.

I don’t have experience with venues or logistics, so I’ll offer informed guesstimates. Let’s assume salaries, venue, and light branding work would cost another $120K.

It looks like the rolling hackathon as a project could be done with $230K per year. A $100K budget would be enough to test the format for 6 months and see if it works.

Of course, these estimates are preliminary and could vary significantly by venue and scale.

As for the source of capital, VC firms are the natural fit. Even if this specific idea fails, as a potential founder, I’d hold the VC firms involved in much higher esteem. They’d actually have an answer to the now-famous question: “What have you done this week?” Because “I stuffed my pipeline with LinkedIn’s Sales Navigator” ain’t it.

Closing thoughts

For people potentially interested in seriously considering this idea, let me offer a closing thought. One-off hackathons often suffer from what I’d call the “summit syndrome” - lots of energy and ideas that dissipate quickly because there’s no supporting infrastructure or ongoing relationships to sustain them.

The real impact will come with a slow on-ramp. You have to be mentally prepared that the first three to six editions will feel like pushing a rock uphill: the demos won’t be that great, ideas will be too generic, and teams will struggle to work together. All these are fixable.

The rolling hackathon is a social product—it needs relentless iteration on trust, participation incentives, and social dynamics to succeed. But done right, it can nudge the culture toward faster execution, raise the skill bar, and improve founder matchmaking—a change Europe needed yesterday.

If you find the idea intriguing and would like to contribute to making it happen, reach me at greg@gkk.dev.

Additional resources and ideas

Thanks to Max Salomonowicz, Maciek Małysz, Artur Wala, Kacper Zambrzycki, Jim Lee, Agnieszka Podsiadło, Filip Stachura, Jacek Migdał, Jakub Neander and Michał Prządka for reading drafts of this post.

Published

Deep Learning ∩ Applications. A recent pivot from a 'promising career' in systems programming (core team behind the Scala programming language). Pastime: Ambient Computing. Grzegorz Kossakowski on Twitter