Designed and built in code: how we shipped the BeWell festival app

Back in February, Sakis and Christina came to us with a simple ask: build an app for the BeWell ecosystem. Start with the festival. See where technology takes it from there.

BeWell Festival is Europe's biggest wellness festival. Two days at OAKA in Athens, June 6–7. More than 31,000 people and over 400 sessions across zones, coaches, sponsors and partners. People needed a way to explore all of it, build their own agenda, and actually show up to the right sessions at the right time.

BeWell had never had an app. For all its reach, the ecosystem wasn't mobile-friendly — and that was the gap. So the target was clear: something on brand, but also modern, fresh, and built mobile-first. Not a website squeezed onto a phone. Their first real app, and it had to feel like it belonged to them.

That was the app. And the way we built it is the story: designer and engineer, both inside the code, start to finish.

We skipped the brief

The classic agency process is weeks of briefing documents before anyone touches a screen. We didn't have weeks. So we wrote a one-pager — a quick alignment on what phase one is and what this app means for BeWell.

First meeting, we got to know each other. Second meeting, we showed up with a working Figma Make prototype in BeWell's brand colors.

One-pager. Prototype. Approval. Build. That was the whole ramp.

Designed in code — not vibe coded

We also skipped the classic design → evaluate → build → ship pipeline. Almost everything happened directly in code.

Figma still did real work up front — we drafted the onboarding and everything else we needed there before building it. But it stayed a drafting and alignment tool, focused on critical screens and the ones where UI carried the most weight. Everything else — the motion, the shapes, the transitions, the feel — was designed where it would live: in the codebase.

There's a difference between vibe coding and designing in code. Vibe coding is accepting whatever the model gives you. Designing in code means the interface idea that used to take days on a canvas now gets crafted once at high fidelity, then translated directly into production — the prototype, the motion, the shape of it, all at once.

And it wasn't a handoff. There was no designer throwing a file over a wall to an engineer. We were both in the same repo — me shaping the experience and the interface in code, Spyros holding the architecture and the integration. Two crafts, one codebase.

Actual code started in April. Net time designing and building in code — app reviews included — was roughly a month and a half. That's the whole build.

The stack: React Native with Expo. I was building in Cursor with Claude Opus 4.6, pushing code to GitHub. Spyros, our mobile lead, was reviewing, fixing, and pushing the integration work across frontend and backend. A tight loop — I push, he corrects, we ship.

My designer toolkit stopped being a canvas. It became: build in Cursor, preview in Expo to see how components sit inside each other, then build to a real iPhone and Android device to check the interaction for real. Some things you can't judge in a simulator. Liquid glass on iOS is one of them — to get it truly interactive, we had to run builds on actual phones and feel it in the hand. Design, build, feel, adjust — on device.

The details nobody asked for

With AI handling the labor, we invested every hour it gave back into quality. That's where the app stopped being a schedule viewer and started feeling alive.

Squircles, everywhere. Custom squircles — not just on buttons and inputs, but on entire pages. The main interface opens as a squircle card and, on scroll, animates to fill the screen and become a full scrollable view that reveals more as you go. Only Apple really does squircles natively. Everyone else ships rectangles or circles. We didn't.

The session modal follows the same idea. It opens floating — cover, title, description in a squircle card. Scroll, and it grabs the whole page, expanding to full width and height. One continuous gesture from glance to detail.

Haptics on everything. Most below-average apps forget haptics entirely. Haptics make an app feel alive even when people can't name why. Expo made this easy, and we used it relentlessly.

Small joys. Tap your saved sessions count in your profile and hearts float over the interface. Tap the days remaining until the festival and an hourglass flips. Nobody needed these. That's exactly why they matter.

Then the fundamentals: interest-based onboarding that feeds session suggestions, time-of-day filters (morning, afternoon, evening), all-day sessions pinned at the top of the agenda, a search that finds anything — sessions, coaches, sponsors — and a home page built for exploration through tappable card layouts that pull you one level deeper into the zones.

Obsessing over details most users will never consciously notice — while nailing the UX they will. That's the work.

One codebase, two products

An app like this isn't just an app. Behind it sits a CMS and a Conduit-powered backend that powers every piece of content — and we built both in a single monorepo: the Next.js CMS and the React Native app living together, with shared types keeping both sides aligned.

That let us work on separate feature branches without stepping on each other. It also meant I could understand the full architecture — files, rules, skills — and pollute the code far less than I would have otherwise.

The CMS went deep. The BeWell team could change the onboarding image, feed live content from YouTube, point people to Instagram, manage featured and suggested session sections on the home page — all without touching code.

The honest part

Here's a thing people miss: React Native is a completely different beast than React. It looks close on paper, but it isn't the web. Fewer resources, fewer battle-tested patterns, and a much smaller training footprint — which means most AI tools are noticeably weaker at it than they are at React or Next. They'll happily write you fluent web code all day. Ask them for native gestures, platform-specific behavior, or the animation and haptics layer, and the confidence stays high while the accuracy drops. You have to know when the model is bluffing.

That's exactly why the setup mattered. AI-generated code isn't free. I broke things. Hardcoded color values where tokens should be. Drift from the design system markdown we'd set up. Spyros spent real time keeping up with AI-generated code — sometimes using AI to fix what AI broke.

This works because of the setup, not despite it. A developer sets up the environment. Rules, skills and templates keep the project on rails. I know what I don't know. Two decades of product context is the difference between building with AI and producing slop with it.

The last mile

Then there's the red elephant in the room: App Store review. Anyone who ships to the App Store knows — reviews can be brutal, they take days, and days were critical for our launch timeline. We ended up requesting an expedited review to hold the date. If you're shipping an event app, bake review time into your plan from day one.

We took a hit here too. Apple cut a feature we'd planned — contacts. And that's the tip: be proactive about permissions, and be ready to explain, clearly, why you need contacts access, location access, any of it. We always try to tackle this early, and we still got caught. It only gets stricter, and a lot of it depends on which reviewer you land on. Assume scrutiny, justify every permission, and have a fallback for the ones you can't defend.

The last two weeks were day and night with the BeWell team. What carried us through was responsiveness — bugs surfaced on the CMS and on the phone, and we fixed them fast, together. Wiring Firebase analytics — something we'd planned from the start, so we'd understand exactly how people use the app. Shipping CMS features we had no idea we'd need, like automated uploads to make content entry dramatically faster.

Two lessons from that stretch:

• You can't nail everything on the first try.
• And you only learn if you're shipping the right thing when real people use it and tell you.

The technical deep dives

Short sections on how specific interactions were built — each with a mini clip showing the interaction in motion.

Liquid glass bottom navigation

Liquid glass, no fakery. The bottom tab bar uses Expo Router's NativeTabs — Apple's native UITabBar on iOS, which renders the system liquid glass material. We didn't stack BlurViews or shaders in JavaScript. On Android, the same API renders Material bottom navigation — an honest platform difference, not a compromised clone. Tab switches fire selectionAsync haptics.

The page scroll animation

One gesture, full screen. Main tab screens and detail modals share a scroll-driven morph: the interface opens as an inset squircle card and, over the first 60 pixels of scroll, interpolates radius, scale, and safe-area offset until it fills the viewport. Built with Reanimated worklets on the UI thread — not a shared-element transition. ModalCard layers pan-to-dismiss and hero parallax on top. The hard part was the math: making the card feel anchored while it grows, and getting it right on a real phone.

Haptics patterns with expo-haptics

Feedback by intent, not volume. Light impact on almost every tap — baked into Button, wired through cards and list rows. Medium impact for heavier confirmations like saving a session. selectionAsync for discrete changes: tab switches, filters, chips. No custom hook — but a StaggeredEntrance animation wrapper optionally fires haptics per item as they animate in. Selection for navigation, impact for action.

Building true squircles in React Native

Not rounded rectangles. We use iOS borderCurve: 'continuous' exposed through NativeWind as a .squircle utility — real continuous corners, not oversized borderRadius. For borders, a SquircleBorder wrapper simulates a 1px edge without breaking the curve (iOS ignores borderCurve when borderWidth > 0). No SVG path library. On Android the prop is a no-op — graceful fallback to standard rounded corners. Squircles on buttons, cards, inputs, skeletons, and the morphing page shells themselves.

Component architecture — NativeWind + our component system

Three layers: tokens, primitives, features. NativeWind v4 + Tailwind v3. Design tokens live in CSS variables and flow into tailwind.config.js; React Navigation reads a JS mirror in theme.ts. UI primitives follow the React Native Reusables pattern with cva variants. Feature components compose primitives — SessionCard is Pressable → SquircleBorder → Card, not a hand-rolled View with inline styles. When AI-generated UI code drifted to hardcoded colors, Cursor skills and PR review pulled it back to semantic tokens.

Monorepo setup: CMS + mobile in one codebase

One repo, two products, shared contracts. pnpm workspaces + Lerna: Next.js CMS, Expo mobile app, shared conduit-types package, and a Conduit custom service for push notifications. The CMS and app never disagreed on what a Session or Zone looks like. We worked on separate feature branches in the same repo — designer on experience, engineer on integration — with Cursor rules and skills keeping generated code on the design system rails.

What this proves

We built a production app for a 31,000-person festival in a fraction of the classic timeline — without cutting quality, and in most places, raising it.

Not because AI replaced the craft. Because it gave us the time to invest in it.

Designer and engineer, both in the code. We designed in code, we shipped the details, we stayed close to the people using it. Under the hood: shared types across CMS and mobile, Conduit for live content without app updates, and one scroll-morph system (ScreenCard / ModalCard) reused across major screens.

That's the work.

‍