FNTECH conference platform

From OpenStack to FNTECH

I joined Tipit, a software factory in Buenos Aires, in February 2014. For my first two years I also worked for other clients — CrowdTangle, a social-post aggregator, and Realty512, a real-estate site in Austin — alongside the OpenStack Foundation, which ended up as Tipit’s only client.

The conference system started inside openstack-org, the SilverStripe monolith that ran the foundation’s whole site; I have around 1,600 commits there. As the Summits grew it was split into services: a teammate built the backend, summit-api in Laravel, and I built the frontend apps on top of it.

Around 2021, FNTECH took the platform over. Until then they had handled the physical side of events: equipment, furniture, staff, catering. Now they fund the platform, keep it open source and sell it to clients like Roblox, Facebook and OCP, the largest. I still work for Tipit, part-time, and FNTECH is now its only client, the way OpenStack was; for years it ran in parallel with my job at Firstleaf.

The life of an event

Each stage is its own app, all on the same API and data model. An event goes through:

• Setup: venue, rooms, track categories and activity types, breaks included.
• A call for presentations, on its own microsite.
• Selection by track chairs — in the OpenStack years, with public voting too.
• The schedule.
• Badges, access badges, and signage: a screen per room showing its schedule, working offline.
• Registration and ticket sales, with a widget for attendees to manage their orders.
• A marketplace where sponsors buy services for their booths.
• Booking for the meeting rooms at the venue.
• Emails throughout, scheduled and triggered.
• On site: iPad kiosks that check people in and print the badge on the spot, and mobile apps for iOS and Android that scan badges, for sponsors capturing leads and for access control.
• A native attendee app for iOS and Android: schedule, tickets, networking and chat.
• The event site — during the pandemic, with live and recorded streams and chat.

The back office

summit-admin is the React and Redux app organizers use to set all of that up and run it. The repo was created in November 2017, my first commit is from the next day, and I have been its main contributor since. It is mostly dense tables, deep forms and approval flows that last months, from the first CFP submission to the final schedule.

Around it I built most of the frontend apps: call for presentations, track chairs, sponsor services, the schedule and search widgets, the pandemic-era widgets (live event, chat, speakers, feedback), and the survey API with its analytics. I am also the second contributor to openstack-uicore-foundation, the UI library they all share.

The data model came from the SilverStripe days and I designed it together with a teammate, who owns it today along with the API.

Reports, and GraphQL in hindsight

Organizers kept asking for reports on speakers, sessions, attendees and sponsors, so I built summit-reports-api end to end — Python, Django and Graphene — plus the screens in summit-admin that use it.

I picked GraphQL because the reports looked like simple reads over a few tables: the client asks for the columns it wants and gets them. The filters outgrew that. I ended up generating SQL and injecting it into Graphene and django-filters to get queries GraphQL was never going to express. If I started today, I would build it as a plain REST API.

9,000 people in one hour

OCP’s summit has about 15,000 attendees, and around 60% of them check in during the first hour of the first day. That is roughly 9,000 people across 10 stations: scan the QR code, print the badge, next.

The flow was load-tested before the event. On the day, there were no incidents.

Themes and widgets, in hindsight

To serve several clients from one codebase, the event sites were built with Gatsby themes: one shared theme, a thin site per client on top. The widgets — schedule, search, speakers — were meant to be embedded in the clients’ own websites.

Neither aged well. The widgets were never embedded anywhere; they only ever ran on our own sites. And with AI, keeping a separate site per client is cheap enough that the theme layer is more indirection than it is worth. We are migrating the event site to Astro, without themes.

What we are working on now

The most recent work is with coding agents. Since March 2026 the team keeps a shared knowledge base, an Obsidian vault of Markdown files that every session starts from, human or AI: the platform architecture and service map, design patterns, rules per stack for agents (Laravel, Django, React, Gatsby), how we write design specs, the AI-assisted pull-request workflow and its review gates, design specs for new features, tribal knowledge and event postmortems.

I add to it from my side of the platform: the form patterns in summit-admin, rules for the React apps, and the design for FNstream, a new standalone app to run an event’s live streams.