From Vibe-Coded Wreck to Production Platform
How do you build a production platform as a side project when demand grows faster than the evenings and weekends available to ship it, the event date cannot move, and success creates more work than you can absorb?
What it's about
How do you build a production platform as a side project when demand grows faster than the evenings and weekends available to ship it, the event date cannot move, and success creates more work than you can absorb?
The ZurichJS platform was developed largely outside working hours, with limited time, attention, and capacity for maintenance.
Our first attempt was the ZurichJS meetup website. Vibe coding turned the idea into working software quickly, but the codebase gradually became a wreck.
The ZurichJS Conf platform was our second attempt, with higher stakes and the same limited hours. In under a year, it processed over six figures in transaction value and generated over six figures in impressions, almost entirely through organic growth.
This technical case study compares both iterations through the role of human judgment. We will examine what could be delegated to AI, what required technical review or product taste, and where loosely structured experimentation was the pragmatic choice.
With no engineering organization prescribing a process, we created a minimally viable software development lifecycle: enough planning, testing, observability, security, and release discipline to protect users and payments without burying a side project in process.
The hardest decisions involved where to cut. Some shortcuts preserved momentum, such as leaving low-risk operations manual or delaying abstractions. Others created hidden costs, weakened reliability, and forced us to revisit work at the worst possible time. Several security incidents, none resulting in a data breach, put those decisions to the test.
Go-to-market execution added another source of technical pressure. Performance, search visibility, analytics, content, and conversion continuously influenced what we built next and which technical work needed our limited time.
What you'll leave with
- Decide which work can be delegated to AI and which requires human judgment, technical review, or product taste.
- Build a minimally viable development lifecycle that protects real users and payments without adding unnecessary process.
- Evaluate shortcuts through reversibility, failure impact, operational cost, and the time required to undo them.
- Use acquisition, conversion, and usage data to prioritize technical work instead of relying on assumptions.
- Keep a growing side project reliable and manageable without sacrificing every evening and weekend to operations.
Who it's for
All Builders
More talks
Want a talk like this at your event?
Tell me about your audience and I'll adapt this talk (or build something new) to fit your room. I reply within two days.