The Invisible Architecture of Great UX: 

How I Built a Game That Thinks

June 2, 2026

11 min read

Why the best user experiences aren't just what you see on screen, they're the systems, intelligence, and operational leverage that make the product feel alive.

You can feel the difference between a product that was designed and a product that was engineered. One responds to how you use it. The other anticipates what you'll do, learns from it, and morphs in real time. The first is a tool. The second feels less like an app and more like it has taste.

I spent the last few months building that second thing. Not because I had a bigger team, but because I deliberately inverted how I thought about the architecture. Instead of building a beautiful surface and bolting on "smart" systems as an afterthought, I built the invisible systems first, and designed the UI around them.

This is what that taught me.

Nkeko is an AI-powered social games app. Fourteen card games for couples, friends, and adult gatherings. It lives in the moments—in living rooms, on dates, at bars—where a game that doesn't adapt feels stale in minutes. Building this alone meant I couldn't afford to be slow or generalist. I had to be both fast and strategic. That forced precision: I couldn't waste cycles on work that didn't compound. 

Every system I built had to earn its place in one of two ways:

• Make gameplay better. Give players a reason to come back. Or

• Make me faster. Reduce the friction between idea and shipped feature.

The Core Belief: UX Is Not Just Surface

Most product thinking splits the world into two camps:

• Design: the interface, the pixels, the delight

• Engineering: the systems, the data flow, the plumbing

This split is wrong. Or more precisely, it's incomplete. Great UX is the entire system that users experience, from what they see to how their data flows through the app to how the backend learns from their behavior. It's:

• The visible moment when you play a card and it reveals something that feels written for you

• The invisible moment when the app analyzed your last session, clustered your preferences, and decided which game to recommend

• The operational moment when you, as a builder, can look at aggregate group data and say "Ah, people keep skipping this card" and fix it in 5 minutes

Nkeko forced me to think in this integrated way. And it taught me that the most delightful products aren't built by separating these concerns. They're built by architecting the invisible systems as a form of UX. 

User-Facing Experiences

Game Mechanics & Personalization

The foundation of Nkeko is fourteen distinct games, each with its own scoring, escalation, and rhythm. Don't Get Drunk escalates in intensity over a session. Concentration unlocks special Lightning Rounds. Pure Cruise limits your passes and forces tough choices. Each mechanic is a system that shapes how play unfolds.

But mechanics alone don't create delight. Delight comes when the game understands your group. I built a Game Master feature that sits at the intersection of AI, behavioral analysis, and real-time personalization. This Game Master has:

• Vibe Check: The AI watches the weather outside, asks how you're feeling (mood, group size, if you're drinking), and recommends the perfect game. Not generically, but with a concrete play style suggestion. "Start with Intimate Actions at deep intensity. A stormy night calls for vulnerability." It's specific. It's earned.

• Dynamic Dare: You set up your group profile (relationship type, vibe level, inside jokes) and the AI uses that context (not just your names, but who you are) to generate dares that land because they're culturally informed and personally resonant. And then it learns: you rate each dare, and the next round adapts.

• Mood Master: Same personalization applied to card generation. "You're a couple, you usually escalate slowly, you loved the humor last time". All of that feeds into which cards surface, how they're phrased, what category they lean into.

The UX on screen is clean: a few button taps, an animated AI orb that reads the room. But what you're actually experiencing is a behavioral closed loop — your actions feed the system, the system learns, the next experience is smarter.

More examples of how architecture became UX:

• Player Name Integration: Instead of generic prompts ("Player 1, would you rather...?"), every prompt is personalized at render time. "Alex, would you rather...?" It's a small change that massively shifts the feeling; from reading a template to being directly addressed.

• Escalation & Intensity: Couples games have cards tagged gentle, deep, and intimate. The app tracks where you are in a session and prioritizes the next intensity level. You never have to consciously ask for escalation. It just happens, naturally. Architecture → UX.

• Saved Moments Vault: Every AI-generated dare or prompt has a bookmark button. The app keeps a vault of everything you loved, with one-tap share to social media stories. This serves two purposes:

•  User-facing: You have a memory of the night

• Operational: Those bookmarks feed back into the personalization system to refine what's working

Developer-Facing Systems (Or: How I Scaled Alone)

Here's the hard truth about solo building: you can't move fast unless you build tools that make you move fast. And those tools are UX, too. They are just aimed at you, the builder. I built an in-app mobile developer dashboard that gave me real-time visibility and control. It contained:

Rollup: Game analytics at a glance. Sessions this week, average duration, cards per session, group size, top 5 games, full funnel conversion (app open → game select → game start → session recap → explore → real-world action). Period selector lets me zoom to 7/14/30 days. There's a button to email myself the entire rollup as a formatted Word doc. This single screen replaced dozens of manual queries and Slack-to-self reminders.

Groups: Every group that's played is listed with their session history. I can see "this duo played 8 times, they always pick With Love, they quit during Date Convos." I can identify returning groups (badged green) and spot churn immediately. This isn't just analytics, it's narrative. I can see the shape of how people are using the product.

Experiments: A/B test assignments. For every experiment I run, I can see which variant each user got, how many times they were exposed, what their conversion rate was. All of this is pulled from a deterministic assignment system that hashes the user ID + experiment ID, so assignments are stable and reproducible.

Cards: Quality scoring for every card. Completion rate, skip rate, dwell time, interaction count. Cards below 50% are flagged red. Sort by weakest and strongest. This gave me the signal I needed to deprecate bad cards, double down on keepers, and spot which games had weak decks.

AI Health: Monitors my AI services endpoints on a predetermined rotated basis for availability or uptime. Flags availability, non-availability and usage with color-coded status indicators. This helps with debugging AI powered services in that I can, at a glance, determine if outages are caused by usage and or availability. 

I also have systems that I use for varying experience design events ranging from analysis to to Labs. Without this dashboard and more tooling like it, I would've been blind. I'd've shipped a game, hoped it was good, and gotten maybe one piece of user feedback every few weeks. With it, I could see exactly where play was breaking down, which groups were having fun, which card categories were underperforming. More. A lot more. 

More importantly: I could iterate at the speed of taste, not at the speed of external feedback. Every session generated data. Every piece of data was available to me on a single screen. The cost of a decision went from "let me check my analytics tool" to "let me open Settings." This dashboard is a form of UX. It's just not for end users, it's for me the product builder. And it enabled me to ship with velocity that would've been impossible otherwise.

The Intelligence Infrastructure

The Game Master isn't magic. It's three layers of coordinated systems:

Layer 1: The Personalization Engine (RTB-Style Ranking). I built an adtech-inspired behavioral personalization layer. It works like this:

Every user action is an event:

• Like a card → +0.30 to your interest profile

• Share a card → +0.25

• Complete a game → +0.15

• Skip a card → −0.20

Every 5 events, the system rebuilds your interest profile: a vector that encodes your taste across game types, card categories, intensity levels, and more. The profile has both short-term (30 min) and long-term signals with exponential decay. Recency matters.

When the app needs to rank candidates (which cards to show, which games to recommend, which events are "Picked For Your Vibe"), it uses a composite score:

• 40% profile match (how well does this fit your taste?)

• 25% context match (is this the right moment?)

• 20% novelty (haven't you seen enough of this?)

• 15% engagement lift (will this increase dwell time?)

All of this runs on device, in under 200ms, even with 200+ candidates. It's local-first. Your data never leaves the app. This is a system I stole from adtech, but repurposed for human delight. The same algorithms that made ad targeting effective became the skeleton of a personalization layer that makes Nkeko feel less like an app and more like it knows you.

One more step: intelligence that's only on the backend is intelligence you can't debug, iterate on, or learn from. I built a content sync system that works bidirectionally:

• Mobile → Backend: Every generated card, every rating, every session interaction

• Backend → Mobile: Analytics rollups, personalization scores, admin controls

This means:

• I can generate 100 cards with AI, manually curate the best 40, and sync them back as seed data

• I can experience these AI-generated cards, determine their utility, and edit or delete them at will, and trigger regeneration

• I can tag cards with metadata (tone, intensity, cultural reference) and feed that back into the personalization model

• I can A/B test different generation prompts and see which produces higher engagement

The content pipeline is a feedback loop, not a one-way street.

What This Says About My Work

If you're reading this, here's what you should know I can do:

I think in systems. I don't ship an interface and hope the backend works out. I design the backend as a form of UX. The data flow, the event logging, the personalization algorithm, these aren't implementation details. They're product decisions. They shape what's possible on screen.

I understand both sides. I've shipped features end-to-end: product concept → UX design → API contract → backend implementation → performance optimization → operational monitoring. I'm not a specialist who hands off to someone else. I hold the whole system in mind. I build leverage. Every system I build has to earn its place: for the user (does it make the product better?), or for me (does it make the next feature faster to ship?). The dashboard. The event logging. The content sync. These aren't nice-to-haves. They're how solo building at scale becomes possible.

I care about delight, but I ship real products. I'm not precious about pixels. I optimize for motion and engagement. But I also care that every decision is grounded in data: card completion rates, session duration, group return rates. Intuition is how you start. Data is how you iterate. I design for the product's constraints and leverage them. Nkeko is a mobile game. I could've built it like a web app ported to mobile. Instead, I leaned into what mobile makes possible: offline-first data, local personalization, haptic feedback, push notifications, location awareness. The constraints shaped the product's DNA.

Building Nkeko taught me something I didn't expect: the difference between a solo builder and a team isn't the vision. It's the infrastructure. A team can ship without great internal tools because each person specializes and hands off. A solo builder has to be every role at once—product, design, engineering, analytics, operations. That's unsustainable unless the product itself becomes a tool that gives you leverage.

The best decision I made wasn't in design or engineering. It was architectural. I decided early that every system I built would serve two masters: the end user and me, the builder. The personalization engine delights players and gives me signal about what's working. The event logger captures user behavior and fuels the dashboard. The content sync lets me iterate and keeps data flowing bidirectionally.

This philosophy—building the invisible systems as a form of UX—is why I could ship a product this polished alone. And it's the philosophy I bring to all my work.

The most interesting problems aren't about making things prettier. They're about making systems that are simultaneously delightful for users, empowering for builders, and intelligent enough to adapt in real time. Nkeko showed me how to do that. I'm excited to do it again. This time in the first professional home I ever knew.