The Zero-Dollar Conference: How We Ran Chicago Code Camp on Static Rails and Blind CFPs
Between 2010 and 2012, Chicago Code Camp was one of the largest free technical community events in the Midwest. Every year, over 500 software engineers gathered on a Saturday morning for six concurrent tracks covering everything from Ruby and the JVM to mobile architecture and agile testing.
We had no full-time staff, no venture backing, and zero budget for commercial event management software.
As a co-organizer and the web lead, I was responsible for designing and building the official event platform: the speaker call-for-proposals (CFP) engine, the community review system, and the day-of-event schedule matrix.
Looking back at our archived event snapshots from 2010 to 2012, running a high-concurrency grassroots conference on a zero-dollar software budget taught me lessons about product constraints and resilient web architecture that still apply to enterprise systems today.
1. Eliminating Bias with Blind CFP Selection
One of the biggest failure modes of technical conferences is the “speaker clique” problem: well-known industry figures get accepted automatically, while exciting, high-quality talks from first-time or local engineers get buried.
To keep Chicago Code Camp community-focused and merit-based, we built an Anonymized Blind Review Engine:
[ Speaker Submits Talk ] ──► System Strips Names, Bio, & Company Affiliations
│
▼
[ Community Reviewers ] ──► Rate Proposal purely on Abstract & Technical Depth
│
▼
[ Organizer Committee ] ──► De-anonymize ONLY after final scoring threshold met
By separating the evaluation of the technical topic from the speaker’s public profile, we elevated dozens of first-time local speakers who went on to become prominent conference keynoters and open-source leaders.
2. The Deterministic Schedule Matrix
Scheduling a conference with 40+ sessions across 6 physical rooms and 8 time blocks is a complex constraint-satisfaction problem:
- Speakers who submit multiple talks cannot be scheduled against themselves.
- High-demand tracks (like Ruby on Rails or mobile development) needed larger lecture halls.
- Rooms required buffer time between talks to allow attendees to cross the venue.
Instead of trying to solve this manually on a whiteboard or paying for expensive conference software, we built an interactive scheduling grid that validated room capacities, speaker availability, and time slot conflicts in real time.
3. Static Generation for Spotty Venue Wi-Fi
On the morning of the conference, 500 developers with laptops and smartphones descended on a university campus, immediately overwhelming the local Wi-Fi network.
If our event schedule had relied on a heavy client-side single-page app or dynamic database queries on every page load, the site would have crashed at 8:45 AM when attendees checked where to go for the keynote.
We designed the site to be 100% statically pre-rendered:
- The complete schedule grid, speaker bios, room maps, and sponsor listings were compiled into lean, static HTML and CSS files.
- Assets were cached aggressively with local storage fallbacks.
- When an attendee pulled out their phone between sessions, the schedule loaded instantaneously, even with one bar of 3G cellular service.
💡 What Community Tooling Teaches Us About Software Craft
Running Chicago Code Camp proved that constraints breed architectural clarity:
- Lightweight beats complex: When resources are constrained, static pre-rendering and clean HTML will outperform over-engineered dynamic microservices every time.
- Process integrity matters: Automated blind evaluation removes human bias and builds trust in community platforms.
- Software exists to serve human connection: The purpose of the technology was not to keep people staring at screens, it was to get attendees into rooms where they could learn from peers and build lasting professional relationships.
In Part 3 of this series, we will dive into the oral history of the era: exploring deep conversations with Dan North, Sandro Mancuso, and the founders of the Software Craftsmanship movement.