InPacto 2026

InPacto is a two-day youth conference run by a church youth ministry ("Mocidade"). For the 2026 edition, themed "Saturados" ("Saturated" — a play on being full/satisfied vs. numbed by constant stimulation), I designed and built the official companion app: a gamified, real-time hub where attendees check the live agenda, follow what's happening on stage, take notes, complete "missions" tied to the conference's talks, climb a leaderboard, and buy merch — all from a phone, with zero app-store friction.

I owned the project from the first conversation about what the app needed to do, through defining the product, designing the interaction model, building the full stack, load-testing it for a live crowd, and shipping it to production before doors opened. Claude Cowork and Claude Code were the two halves of that process: Cowork for thinking — structuring the discovery, shaping the content model, making decisions — and Code for building, testing, and operating the real system.

Youth conferences like InPacto run on paper schedules, word-of-mouth, and a WhatsApp group that gets unusable within an hour. The organizing team wanted something better: a single place for the agenda, live updates when a session goes on stage, and a way to keep 1,000+ attendees engaged across two full days without it turning into "another app nobody opens."

The harder constraint was thematic, not technical: the conference's central message was about *digital saturation* — phones, dopamine loops, distraction — and I was building a phone app for it. That tension became the actual design problem: how do you build something people open often, without becoming the exact thing the conference is asking them to put down?

Discovery here didn't start with formal user interviews — it started with briefings and brainstorms with the organizing team, and with the conference's own content: the talk lineup, the speakers, and the specific themes each session would cover (distraction and dopamine, connection across churches and cities, discomfort and escapism, presence at worship). I used Claude Cowork to work through that raw material — schedules, talk descriptions, the organizing team's goals — and turn it into a structured product brief: who uses this app, in what moments, and what job it needs to do at each one. I built and tested solo, but the organizing team stayed in the loop at every checkpoint that mattered: shaping the brief up front, and stress-testing the missions and flows before they shipped.

That process surfaced the core insight the rest of the product is built on: the app shouldn't compete with the conference's message, it should carry it. Instead of generic gamification (points for opening the app), every mission was written to mirror a specific talk.

Cowork was also where I mapped the full information architecture before writing a line of code: 16 screens, the data each one needed, and how they'd connect — turning a loose brief into something buildable.

Those goals directly shaped three decisions I'd flag as the design core of this project:

The app is a single-page React application with 16 screens behind a lightweight Zustand store (with persistence, so state survives a refresh or a dead connection), organized into four flows: Onboarding (splash, login/signup, email verification, profile setup), Core hub (home, agenda, live session, ranking, store), Personal (profile, notes, wishlist) and Operations (role-gated admin).

This is the part of the process I most want to highlight, because it's the actual differentiator of working as a Design Engineer with Claude: the design and the implementation were never two separate phases done by two separate tools. Cowork handled the thinking-heavy, ambiguous work — structuring discovery, defining the mission taxonomy, writing the achievement conditions, shaping the data model conceptually before it became SQL. Claude Code took that structure and made it real: React components, Supabase schema and migrations, Row Level Security policies, real-time subscriptions, and the operational scripts that run the event.

With 1,000+ people expected at the event, I load-tested for exactly that number. Two days before doors opened, I ran a full load test against the production Supabase backend using k6, simulating 1,000 concurrent virtual users hitting the API at the same instant — a deliberately worst-case scenario, well past what a real crowd generates at any single moment — across three real usage scenarios: pure reads, authenticated mission completion, and unauthenticated feed writes.

The test wasn't just a performance check — it was a security validation. The scenarios designed to fail *did* fail, because Row Level Security correctly rejected writes without a valid session. That's the result I was looking for as much as the throughput numbers.

The test also surfaced a real constraint: Supabase's free-tier Postgres connection pool (roughly 60–100 concurrent connections) becomes the bottleneck well before the app logic does. Reads held up at 98.4% success even at ~334 truly simultaneous users — comfortably above what 1,000+ people spread across two days actually generate at any single instant — but I documented the ceiling anyway: enabling PgBouncer, indexing `feed_posts` and `ranking` for the hot paths, and edge-caching static data like the schedule.

Deployment was scripted end to end (`deploy.sh`): git init, push to GitHub, deploy to Vercel, with Supabase running the backend in production. No manual deploy steps, no "works on my machine" — by the time the event started, the whole pipeline from `git push` to a live URL was a single command.

The backend held up on load-test numbers, but the number that matters more is what attendees said after using it for two real days. The organizing team ran a post-event survey — 93 responses, 8 categories rated, 71 open comments, 44 improvement suggestions — and the app came out as one of the highest-rated parts of the whole conference: 4.69/5, with 95% of ratings between 4 and 5 — ahead of the food court, the marketplace, and the workshops, for a piece of software built solo in a few weeks, sitting next to a stage, a sound system, and a catering operation.

It also showed up in 10 of the 44 open improvement suggestions — enough to matter, not enough to be a top pain point (space and seating logistics led that list). The open comments are where the real signal is:

"The photos and names feature in the app was great, but the time was so short... I'd do something like each badge having a colored dot and you'd have to find someone with that color, to pray together"— the connection/profile feature landed well enough that people proposed their own mechanic on top

"I couldn't use the app on my phone, it gave an install error... But the experience looked great from what I saw of everyone using it!"— a real install failure on some Android devices, alongside a positive read on the product itself

"Didn't even know there was an app :/"— the most useful kind of negative feedback: not a product problem, a distribution one

The organizing team turned all 93 responses into a formal action plan for the next edition. The app's team — labeled "Experiência" — walked away with a prioritized backlog: publish to the Play Store / App Store (directly answering the install-error reports), add opt-in matchmaking by city/church/interest, add a personal feed view inside the app, and surface missions and prizes more visibly before each talk. Every item traces back to a specific, counted piece of feedback.

The most interesting design constraint on this project was that the product and its message could easily have worked against each other — a gamified app, for a conference about the cost of constant engagement. The resolution wasn't a clever UI trick; it was making the content itself the mechanic, so every "hook" in the app was also a genuine invitation into the conference's message. That's the kind of decision that only shows up when discovery and execution are done by the same person with the same context the whole way through — which is exactly what building with Cowork and Code end-to-end made possible: no handoff, no lossy brief, no gap between what was designed and what shipped.

The post-event data confirmed the core bet (a 4.69/5 app score, ahead of most of the physical event) but it also surfaced the two honest gaps a first build like this always has: distribution ("nem sabia que tinha um app") and platform compatibility (the Android PWA install failures). Neither is a design failure so much as the natural edge of shipping a PWA instead of a native app under a tight timeline — and both are now concrete, prioritized items in next year's plan rather than vague lessons learned. That loop — build, measure with a real load test *and* a real post-event survey, then translate both into a scoped backlog — is the same end-to-end ownership that defined the rest of the project.