𝗜 𝘄𝗲𝗻𝘁 𝘁𝗼 𝗖𝗮𝗿𝗻𝗶𝘃𝗮𝗹 𝘁𝗼 𝗽𝗮𝗿𝘁𝘆, 𝗯𝘂𝘁 𝗜 𝗰𝗮𝗺𝗲 𝗯𝗮𝗰𝗸 𝘄𝗶𝘁𝗵 𝗮 𝗦𝘁𝗮𝘁𝗲 𝗠𝗮𝗰𝗵𝗶𝗻𝗲.

Carnival broke our assumptions about software.
We almost built Loopa wrong.
Not because of code, but because of assumptions.

Initially, Loopa was designed as a general circular fashion platform. But we saw a unique window to launch during Carnival, where identity shifts fast, trust is contextual, and timing is everything.

The shift from “General Circular Fashion” to “Carnival Circular Fashion Mode” wasn’t a UI change. It was an architectural validation.
Because we chose structure over speed before scale existed, our system didn’t blink.

Clothing exchanges aren’t just “status” columns.
They’re modeled as state machines, not simple CRUD flows. Each transaction moves through explicit states, with rules enforced in the service layer, never in the UI, never directly in the database.

Supabase is fully abstracted behind repositories.
Business logic lives in services.
Side effects, real-time updates and cache invalidation, run through an internal event bus.

Components don’t talk to the database. Ever.
It might look heavy for something that started with Carnival.
But when people reinvent themselves overnight, systems can’t afford to be vague.

The real MVP decision wasn’t the stack.
It was choosing structure over speed before scale existed.
Carnival is chaotic by design. Software shouldn’t be.

When have your architectural choices been the “hero” of a business pivot?