11. Mar 2026

Scaling Beyond the MVP: Guide to SwiftUI technical debt

This session is for CTOs, Lead Developers, and Product Owners who want to build mobile apps that survive the first release without requiring a total rewrite.

Miroslav GajanMarketing

Stop the SwiftUI Chaos: Scaling Beyond the MVP

Let’s build it fast; we’ll refactor later.

We’ve all heard it. We’ve all said it. But in the world of mobile development, these are often the famous last words that lead to "spaghetti" state management, irreproducible bugs, and a development pace that crawls to a halt after just six months.

SwiftUI is a superpower for speed, but that speed comes with an invisible tax.

Why Join This Session?
We aren’t here for a basic tutorial. We’re going under the hood of real-world SwiftUI production projects to pinpoint exactly where the chaos starts.

This event is for CTOs, Lead Developers, and Product Owners who want to build mobile apps that survive the first release without requiring a total rewrite.

Event will be held in slovak language.

What you’ll learn

The 6-Month Stall

We’ll explain why the "lightning-fast" initial development of SwiftUI often hits a wall where new features suddenly cost 3x more and take 2x longer to ship.

Real-world code breakdowns

We will show you exactly which "minor" trade-offs in the MVP phase create the hidden technical debt that eventually drains your budget and freezes your roadmap.

Scaling dynamics

We’ll demonstrate why an "MVP-first" architecture, while great for speed, often lacks the structural integrity to support high-user traffic and complex feature roadmaps without a total rewrite.

Lessons learned

We’re opening our internal "fail log" to show you the specific strategic decisions that cost us time and money, and how we’ve redesigned our process to avoid them.

Speaker:

Filip Šašala

iOS Developer

A pragmatic developer focused on SwiftUI and clean architecture. Having shipped dozens of projects, he knows that the true value of code isn’t proven at launch, but six months into production. He believes that every technical decision must make business sense—otherwise, it’s just an expensive hobby.