On July 11th, my team and I attended BloomKnights hosted by Knight Hacks at the University of Central Florida. I went with Tomas Torrado, Mahinur Mahi, and Ian Lopez, representing GDG and SHPE USF.
Eight hours later, we walked out with second place overall.
One-day hackathons are very different from the usual weekend-long ones. There is barely enough time to build, test, debug, make a presentation, and somehow turn everything into a demo that works when someone is actually watching.
You cannot spend three hours debating architecture. You cannot restart halfway through because you found a better idea.
The question becomes pretty simple: what can we actually build today?
What we built
We built a low-cost Braille translation system designed to make digital text more accessible for blind and deafblind users.
The hardware side was a physical 8-dot Braille display controlled by an ESP32. On the software side, we built a desktop application that could send translated text to the device in real time using WebSockets.
The idea was to create a system where text entered digitally could be translated and represented physically through Braille cells. Rather than treating the hardware and software as two separate pieces, we wanted the interaction to feel immediate. Enter something on the computer, send it to the ESP32, and have the physical display respond.
Getting that full path working was the real challenge.
Hardware changes everything
Most of the hackathons I had done before were heavily software focused. This project was a reminder that adding hardware gives you an entirely new category of things that can go wrong.
A function returning the wrong value is usually straightforward to debug. A physical device not responding could mean the code is wrong, the communication is broken, a connection is loose, the ESP32 is behaving unexpectedly, or the hardware itself is not doing what you think it is doing.
And you still have the same deadline.
We spent a lot of time moving between the desktop application, the WebSocket connection, the ESP32, and the physical display trying to figure out exactly where something had stopped working.
When the complete chain finally worked, it was much more satisfying than getting another API endpoint to return 200.
Build the demo, not the perfect system
One of the most useful things about a short hackathon is that it forces you to decide what actually matters.
There were plenty of features we could have added, but every additional feature was also another thing that could break before judging.
So we focused on the core path:
- Text goes in.
- The application translates it.
- The data gets sent to the ESP32.
- The Braille display responds.
Once that worked reliably, everything else became secondary.
It is tempting during a hackathon to build the project you would want after a month of development. In eight hours, that usually means ending up with five half-finished features and no convincing demo.
A smaller system that works from beginning to end is a lot more useful.
The two-minute test
Hackathons also teach you very quickly that building the project is only half of the job.
You can spend the entire day working on something technically difficult, but the judges still need to understand why it matters in a few minutes.
For us, having physical hardware helped. Instead of describing what the system could theoretically do, we could type something into the application and show the Braille display responding.
That made the project easy to understand.
It also meant there was nowhere to hide if the demo failed.
Fortunately, it worked.
Worth the day
We ended up placing second overall.
Winning something is always nice, but what I remember more is how much we managed to get working in such a short amount of time. We started the morning with an idea and ended the day with a desktop application communicating in real time with an ESP32 and driving a physical Braille display.
Given a month, we probably would have built something much more complicated.
Given eight hours, we built the part that mattered.
Thanks to Knight Hacks for putting BloomKnights together, and to Tomas, Mahinur, and Ian for a very fun day of building, debugging, and hoping the hardware would cooperate when the judges walked over.