This is not your typical hackathon, this is ReleaseBeforeReady

While a conventional hackathon exists because a company decides to organize an event to attract developers and gain users for their products, RbR doesn't have that dynamic. There are no judges evaluating what you create. There are no prizes as rewards. It almost seems like there's no reason to attend.

The true reason to participate in an RbR is very unique: meeting with talented developers to build technology for the pure joy of creating. This is how each event fills up, and we all eagerly await the next one. This happens because our objectives are different.

The goal is to generate a community that builds using technology, that shares how they create, and where we all learn from each other. The event is just an excuse to gather and fulfill these objectives. From this, we've begun to build a community that transcends the digital space and remains active in a WhatsApp channel with people from various cities.

At the last event we held in Bogotá, one of the phrases I remember most was René's when he explained the dynamics. René belongs to the 500 Latam team and was the main organizer of RbR Bogotá. At the beginning of the event, while we were explaining the dynamics to first-time attendees, René clarified that at RbR he comes to build as just another participant. That if they wanted to pitch to him, they should do it next week in the context of Colombia Tech Week, where he also organized an event called 500 Tintico Pitch Day specifically designed for that.

At RbR one thing is very clear: we all come to create something. There are no tourists.

We've tried having mentors, but everyone is so focused on building that sometimes they don't approach them. Or when they need help, they end up asking other event attendees. The mentor role seems to be covered by everyone, and maybe that's the answer: at RbR we're all mentors and learners at the same time. (Though if you have ideas on how to improve the mentor role or how you would do it, contact me and let's talk).

You might wonder how we arrived at this particular dynamic. How we came up with the idea of doing an event like this. The reality is that Santiago, René and I have spent many years participating in programming events and communities.

Around October 2008, Santiago and César brought an event called Super Happy Dev House from Silicon Valley. The first one brought together 8 people at our house. Then we organized it many times, eventually having up to 250 people at an event where Google lent us their offices.

Later I helped them organize it in Mexico City. At that event, the goal was to gather for 12 hours to create for fun. SHDH had the pillars of being productive, fun and inclusive. At the end of the event we presented what we built in 5-minute lightning talks. We learned a lot from this event; today we continue to put into practice what we learned from SHDH.

The last events in DF (at that time it was still called Distrito Federal) always had more than 150 attendees. We all grew a lot. The room filled with energy. At SHDH Mexico City 10, the event creators came from Silicon Valley, including Jeff Lindsay, who gave us a lightning talk about the apps he created in 4 hours. We were able to work alongside people who created startups there and realize that we could all be good developers if we dedicated the right time to it. What was missing were places to share and learn faster.

Today these events continue in Silicon Valley, but we prefer to do a slightly different format. We also learned that events with 150 or more attendees require larger spaces and are much more complicated to manage. The next day you end up so tired that you don't want to know about the event for a while.

René and Santiago organized many Startup Weekends. They also met while organizing one in Mérida. René joined the 500 team after this, and today René and Santiago have been working together for a long time. I participated in many, some as a participant, others as a mentor, though I didn't organize any.

Around those dates, I was organizing an event called ChelaJS with Jeduan. That event came from tropicalizing BeerJS from Silicon Valley. We took the idea of getting together to drink beer and chat with other developers, added talks so conversations would be much more directed toward talking about programming. Many of the event talks came from conversations we had at the after-parties of previous events.

Santiago has participated in an indie gaming game jam called Ludum Dare, where many developers gather to program new games based on what the community votes for. They have several days to create and at the end they're evaluated by the developers who participated. At Ludum Dare there are no physical prizes; participants take home a lot of street cred from the community and the rights to what they created. Galcon, which we really like, was created at that event.

Today the ecosystem is much more mature than in those times: there's much more investment and startups. After the pandemic, we were missing an event that we felt was the style we liked, and we decided to create it by combining much of what we learned. As you can see, we've been very inspired by these events to create Release before Ready and VibeRacing.

At RbR, the only currency the community has is what you build and what you teach. Participants have a lot of freedom to work on what they consider valuable and thus take home a unique experience at the end of the day. Each person will choose their canvas, choose their style and be able to deliver something unique.

That, along with the fact that we live in a very accelerated moment in tech where new tools come out every day, creates a perfect combination. Being able to see how someone creates something with these new tools, being able to approach anyone at the event and ask them to teach you what they're doing and how to do it is very gratifying.

Both for the person who receives the knowledge, but more interesting still, for the person who teaches it. Putting into words something you're just learning makes you see it differently, allows you to understand it much better. Especially when someone asks something you haven't tried, the answer is always "I don't know, but let's see what happens," and between the two participants in this conversation, incredible things happen.

The last few days I've been rereading "Zen and the Art of Motorcycle Maintenance" and thinking a lot about removing the wrong incentives in RbR.

It's curious how RbR always fills up. Tickets sell out, people leave happy, and all this without prizes, without judges, without any of what supposedly makes a hackathon attractive (though our swag is starting to look pretty good). This paradox has made me reflect on what really motivates people to create.

At events that have prizes, usually someone from marketing or business sought to create something for the good of the company, so people go to attack that objective. It generates a pretty weird dynamic, almost like going to work on Saturday.

What I really like about how Pirsig in the book explores the difference between classical Quality and romantic Quality is that it perfectly captures what happens at RbR.

For Pirsig, Quality is that intuitive recognition of when something is "right"—you can't define it beforehand, but you recognize it immediately when you find it. It's like knowing when a motorcycle is perfectly tuned without needing gauges. The problem arises when you try to define Quality externally: as soon as you establish fixed criteria, it's no longer true Quality—it becomes mere compliance with specifications.

When there are judges and prizes, everyone pursues the same external definition of quality: metrics, features, what they think the judges want to see. But when you remove those external incentives, something interesting happens: people start looking for their own definition of Quality, the one you recognize when you see it but that remains undefined until you create it.

This lack of definition isn't a problem—it's precisely what allows intrinsic motivation to emerge. Without imposed external objectives, each person must find their own internal compass of what's worth creating. At the end of the day, removing prizes and judges allows what matters to be what each person considers right. Each participant becomes their own motorcycle mechanic, feeling when something is well-tuned, when code flows, when the solution is elegant not because someone else says so, but because you feel it.

Simply thinking about what I would build in a 12-hour period where no one gives me instructions is a challenging problem at first. It's facing that blank page without a maintenance manual. But after a while, curious people go from 0 to 10 ideas they want to build. They discover that when there's no imposed destination, the journey itself becomes the point—and that journey is full of possibilities.

One of the beautiful things about the event is that we won't know what's coming. We know that very good things come when you bring the right people together.

We don't worry about short-term objectives. We don't measure success by the number of startups that emerge or by the hires that are made. Those things happen, but they're side effects of something more fundamental: creating a space where curiosity and creativity meet technology.

The magic is in the unexpected conversations, in the moment when someone shows you a way of creating that you didn't know, in the satisfaction of finishing something you didn't know you could do. It's in that developer who had never used AI and leaves the event having created their first chatbot. It's in that photographer who documents the event and discovers they can automate their editing workflow with code.

During the presentations, "I didn't know I could create this" always resonates. Many attendees end up happy to show the result of what they built and 12 hours before probably didn't think it was possible. In CDMX this happened with Elisa Rodríguez's demo, where she presented a reservation site that had Stripe's sandbox and saved to Google Spreadsheets. Simple, functional, and created in an afternoon by someone who didn't consider themselves "technical."

I'm filled with pride that today René is our Replit expert, after discovering and mastering it at one of our events.

As our manifesto says: "Something extraordinary happens when we gather frequently with the intention of giving more to the community than it gives us. We can't predict exactly what opportunities will arise, but we know that participating with an open heart, good vibes and desire to share always bears fruit."

We'll have 3 RbRs in the next 45 days:

• Palo Alto - September 13th
• Guadalajara - September 20th
• Mexico City - October 18th

If this dynamic of creating and sharing resonated with you, we're waiting for you at these events to learn together. You don't need to be an experienced developer. You don't need to have a revolutionary idea. You just need curiosity and desire to create.

As we say at every event: "Done is better than perfect". And as we learned from Ludum Dare and all the events that inspired us: the best projects are born when there are no judges watching, just creators sharing.

See you at the next RbR. Bring your laptop, your curiosity and your desire to create something that didn't exist this morning.