Out-of-the-Box Tools for Outside-the-Box Thinking
Elements of a successful hackathon event
Hackathons are one of the best ways to get more developers acquainted with a tool or product!
I learned a lot from my participation in ETHBoston, a three-day event that encouraged developers to try something new. At Cardstack, we will utilize these lessons to provide a great experience for new developers at future hackathons that we plan to host or sponsor ourselves. In this article, I will also present some general tips for hackathon sponsors, which will help them get the most out of their sponsorship and provide excellent support to the event’s attendees.
Why did I participate in the ETHBoston hackathon?
My main goal was to get a firsthand experience of the issues developers face when trying to build a dApp (decentralized app) quickly. This research is essential for Cardstack’s future participation in hackathons as a host or sponsor, but it is also a good way to investigate the different aspects of new-user onboarding in general.
I was on the lookout for answers to the following questions:
- What are the participant outcomes?
- What kinds of usability roadblocks do developers hit when integrating sponsors’ products?
- Which sponsors’ products receive the highest interest? Why?
- What are some active ways in which sponsors could help developers succeed?
- What are the Cardstack-specific takeaways from the hackathon?
- How do these lessons tie into the Cardstack product?
Event format
To put these lessons into context, it’s helpful to know a little bit about the event itself. The hackathon was fairly free-form in regards to the coding challenges. The 400 attendees were responsible for forming their own teams; some people already knew each other, while others, like my team, were strangers. The hackathon had very few rules aside from the team size (a maximum of four people per team) and the time limits (no coding was allowed until the official start of the event).
While the coding challenges were free-form, the overall schedule and experience of the event had a solid structure. The organizers had well-thought-out plans for keeping the attendees fed, judging their projects, and providing educational opportunities.
The event was held at Harvard University. Most of the work was done in a large room lined with sponsors’ tables and little classrooms, where half-hour-long workshops were held. Many of the sponsors offered bounties (aka prizes) for teams that integrated their products.
At the end of the event, the teams pitched their projects to two panels of judges and to the sponsors.
Participant outcomes
55 projects were submitted, but the event had 400+ attendees. Since every team had a maximum of four team members, it turns out that only 220 people (at most) completed the hackathon. This raises the question: Where did everyone else go? What got in the way of their success? My own experience uncovered some of the challenges developers may have hit.
First of all, this hackathon had to cater to two audiences with very different needs. Efforts had to be split between engaging experienced dApp developers and people who are new to the space.
Therefore, the event as a whole offered two tracks of workshops — one that provided introductions to sponsor product integrations and a beginner series that taught the basics of wallets and Web3. I attended a few of the sponsor product integration workshops. And as I looked through the sponsors’ websites and documentation, I noticed that, while some sponsors succeeded in serving this split audience, others seemed to struggle with this task.
Usability roadblocks
These are some of the challenges developers faced while trying to build a dApp using regular (non-Cardstack) tools:
- Time is a scarce resource, but much of it was burned on generic app scaffolding (auth, data persistence, forms, deployment).
- There was no quickstart documentation for the integrations.
- It was difficult to find complete teaching examples.
- Library source code was missing or difficult to locate.
- Examples were dependent on specific JavaScript frameworks.
- Debugging an unfamiliar tool is challenging.
- Many sponsors went home early in the evening and weren’t available when teams really needed help.
- Some product documentation assumed knowledge of Web3 request patterns and other prior implicit learning about the ecosystem.
Since I work at Cardstack, I came in with quite a bit of prior knowledge. I know about the ethos and goals of decentralized apps. I know how to use a wallet, what a contract is, what it means to deploy a contract, and what a blockchain can do as a data source. If I didn’t already have some experience with these concepts, I would have been very lost. Since some of my team members were even more experienced than me, however, we covered all the pain points above by working together.
Capturing feedback
Collecting user feedback from developers is vital for sponsors who are looking to sharpen their products, which is why some companies sought it out proactively. At least one of them had a UX specialist on-site who conducted and recorded user interviews. I doubt it’s a coincidence that this was one of the companies that received the most submissions for its product.
Helping participants succeed
These are some ways in which sponsors can help participants succeed and make the most out of their investment in the event.
Sponsors should stay late — in person, ideally until 1 or 2 a.m. Companies should have people cover their tables in shifts. Hackathon participants spend most of the first full day doing generic app scaffolding like auth, a mock environment, and basic front-end. Therefore, it’s late in the evening when they try to put the pieces together. Those final hours make or break a project submission. Debugging help via chat is better than nothing, but not as useful as in-person support. Especially if a company is hoping to win over the participants as its champions or early customers, this personal support is essential.
Tutorials and documentation should be well-tested prior to the event — by people who are not the company’s own employees. This is a great way to catch unexpected problems in advance.
Learning resources should be easy to find. The easiest way to do this is a prominent Web page with links to hackathon-helpful descriptions, guides, example projects, and source code. The elevator pitch for the product could be presented on a business card that includes the link to these resources. Ideally, there’s a developer launch kit or starter app that helps people get going quickly, similar to the Card SDK’s project template. For example, almost every team needs some kind of system for identification/login and a way to tie data into the front end. If a company provides these features in an out-of-the-box kit, developers can spend more time working on the pieces that are special to the product or their business use case.
Enthusiasm and ideas should be shared with attendees. It feels great when sponsors actively try to understand what you have built, help you iterate on the idea, and express genuine interest in your experience. As a company representative, regardless of your personality or your level of enthusiasm after a very long weekend, you can follow a simple formula: One of the easiest ways to make a connection with participants is to ask them questions and build on their responses with an encouraging “Yes, and…” reaction.
Additional takeaways for Cardstack
- Some out-of-the-box development kits are sorely needed in this industry, which Cardstack is in a good position to offer.
- Both hackathon participants and the general developer audience need well-paved pathways to hosting their work and paying for services.
- It is critical for sponsors to have a plan for collecting and recording user experience feedback. In the haze of a long weekend with little sleep, one can’t rely on memory as a substitute.
- It takes a lot of preparation to appeal to hackathon attendees and support them, but the work is worthwhile.
Overall, being a hackathon sponsor or host will be incredibly valuable UX research for Cardstack.
Connecting the pieces
A hackathon environment is like a microcosm that enables developers to learn about Web 3.0 development as a whole. Interestingly, some of the themes that tend to emerge are already present in Cardstack’s products.
Nearly all software products require some kind of login system, a full stack for collecting and displaying data, a hosting solution, and a way to pay for that hosting. Some apps may have a more traditional SaaS (software as a service) approach, where a portion of data is private, in order to serve common business needs. Other apps may be public and decentralized; but even they will likely need to choose a hosting provider at some point.
Cardstack makes it as easy as possible to set up the full stack using the Card SDK. Cardstack provides a way to pay for hosting as well as on-chain fees, using the CARD Protocol. And Cardstack establishes a central place from which to instantiate and serve projects. Our upcoming libraries, like githereum, create ties to the Ethereum and IPFS ecosystem and invite participation from people who are already active in this space.
We look forward to participating in hackathons as sponsors, hosts, and mentors in the future! Stay tuned to hear more about our upcoming plans.
To get all our latest updates, sign up for our newsletter on cardstack.com, star Cardstack on GitHub, and join our Discord channel or our Telegram group and announcement channel.
