CAPSTONE 3 · END-TO-END APP

Exclusive doesn't have to be inaccessible

Interactive. Invisible. In your hand. Drop In to an exploration of how to re-establish connections by leveraging the hypnotic slab you use to upset yourself every day. Eyes, up, drop incoming.

ROLE — RESEARCH · DESIGN · BUILD · TEST (SOLO) TIMELINE — 24 DAYS · JUL 11 – AUG 3 2026 STACK — FIGMA · CLAUDE · CLOUDFLARE · SUPABASE · NFC TESTED — 54 SESSIONS · 3 ROUNDS · REAL TELEMETRY STATUS — SHIPPING. REAL EVENTS, REAL TAPS.
01

Problem definition

Orbital Drop started in conversations with my friends. I'm a DJ; so are they. Everyone wants to play shows because shows are fun, nobody wants to play an empty room, and everyone is broke — a cheeseburger combo runs twelve dollars now, so every luxury purchase has to justify itself. The obvious fix is free shows, and free shows fail: somewhere in the subconscious, "free" reads as "nothing lost if missed," and only your direct friends turn up. The model I'd seen actually work is the opposite — exclusive and free. Music is hype, and it should be treated that way.

So this app is for the people whose presence and time is the only thing they have left to give — and the door itself became the product. Acquisition is physical only, and all earned standing comes from presence. I wanted an event to feel like membership in something so far beyond expectation that it disarms you, instead of getting written off like a generic Instagram flyer.

One rule, set on day one, governs the design — a rule that can be proven wrong: the phone is a key, not a destination. Every core interaction at an event must fit inside ten seconds of screen time. A thesis with a number attached can be tested. The sections below test it.

Pre-project concept note
FIG.01 — PRE-PROJECT CONCEPT NOTE · WHERE THE IDEA STOOD BEFORE THE SPRINT
02

Research

The plan said five in-person interviews. Scheduling killed that — a compromise I resented but had learned to expect from previous projects, so the pivot was ready: remote interviews plus a twelve-question survey through the community's Discord, mentor notified. I had built a custom survey page and threw it out for a plain Google Form. It was hard to read, it stretched the web design system outside its scope, and it cost effort the schedule didn't have.

Honestly, the synthesis didn't surprise me — and I'd rather say that than manufacture a revelation. Five responses confirmed the instincts the concept was built on and sharpened their edges. Synthesis produced a five-cluster affinity map; forum mining added four themes: discovery is fragile, phone norms are contested, exclusivity has two faces, and attendees want to participate, not only attend. The pressure tests I pre-committed to came back workable: access-based rewards dodge the loyalty-card objection, and physical-only acquisition reads as culture fit when the door forgives dead phones.

[ LIMITS, ON THE RECORD ]n=5 is directional, not definitive. My mentor agreed it was enough to move on — the testing program carries the evidential weight.
Affinity map: five clusters from survey synthesis
FIG.02 — AFFINITY MAP · FIVE CLUSTERS FROM SURVEY SYNTHESIS · 2026-07-22
03

Definition & prioritization

The roadmap held twenty features across six themes. I couldn't recite all twenty for you now, and that's the tell: one loop was so obviously the product that cutting the rest never hurt. Scan in, check in, watch standing grow, unlock access. One gesture, two payoffs — a personal count that never decreases, and a collective meter the whole room fills together. The economy uses two instruments and a forgiveness mechanic modeled on Duolingo's streak-freeze. A banned-words list governs the whole interface: streak, lost, points, credit, discount. I never want this to read like another corporate loyalty program. It should feel like someone real made it.

The decision that shaped everything else: build the real thing. I've hit the wall between a finished design file and reality before, and I'd already decided to fill those production gaps myself. I had the materials and the means, so I just tried it — I didn't code the check-in system so much as hook together what my AI collaborator got working — and it recorded its first live tap on July 12, day two of the sprint. The results section cites real behavior, not simulated clicks.

Personas Mara and Devon, built from survey evidence
FIG.03 — PERSONAS · MARA, THE PLUGGED-IN REGULAR & DEVON, THE RATIONED REGULAR · 2026-07-23
04

Information architecture

The important screens in this app are not navigated to. They are landed on, as the destination of a physical tap. The architecture is therefore a two-layer context map: off-app entry surfaces, in-room screens with zero navigation and a ten-second budget, and a small between-events home. A conventional home/explore/profile tree would spend the entire budget on wayfinding, which the thesis rules out.

My first sitemap drifted into journey-map territory: it drew entry points and system logic as if they were screens. The real inventory was six screens. The corrected figure is state-routed, and an automated linter now blocks that error class. The correction cost one day and produced a reusable diagram discipline.

The three-lane notation the flows use — physical, screen, system — isn't an invention. My working logic is that most problems are already solved; you just have to know where to look and what to ask for. I built a reusable flowcharting skill around that and used the research to pin down which context a user is standing in at each step. The width of the screen lane shows how little of each journey happens on glass. The diagram format itself argues the thesis.

Corrected sitemap: six screens, state-routed
FIG.04 — SITEMAP, CORRECTED · SIX SCREENS, STATE-ROUTED · 2026-07-24, CORR. 07-25
User flow The Loop: check-in to reward
FIG.05 — USER FLOWS, "THE LOOP" · CHECK-IN TO REWARD; NOTE HOW BRIEFLY THE JOURNEY TOUCHES THE SCREEN LANE · 2026-07-24
05

UI & design systems

The brand's web design system matured during this project, and I trusted it too far: I imported its tokens into the app, and the app got worse. Rules that are correct for reading a website are wrong for a dark, glanceable, arm's-length screen. I fixed the contamination twice as if it were a series of bugs. The third time I stopped pretending — it looked like shit, and the problem was structural. Two products, two contexts, two systems.

The divorce is formal: the app system ratified as its own entity, with its own typefaces and its own rules for accent-color use, and a governance charter separating the brand's five registries. That formality, on a solo project, is for me. I have weirdly high standards — if I can't use and enjoy my own app, why would anyone else? This page and the app screenshots inside it follow different systems, on purpose.

UI kit: the app system, post-divorce
FIG.06 — UI KIT · THE APP SYSTEM, POST-DIVORCE · 2026-08-01
Brand style tile: the web system it divorced
FIG.07 — BRAND STYLE TILE · THE WEB SYSTEM IT DIVORCED · 2026-07-23
06

Testing & iteration

6.8s
median check-in · thesis ≤10s · PROVEN
82%
of check-ins beat the budget
−65%
dead taps, Round 1 → Round 2 (4.9 → 1.7)
54
instrumented sessions across 3 rounds
4/5
plan objectives met

I built the test rig myself — hosted prototype, ingest worker, isolated telemetry — because I despise Maze, and no off-the-shelf click-tester could include a real NFC tap or measure actual screen time. The thesis was a number, and opinions can't test a number. Three rounds ran: Round 1 lo-fi (25 sessions), an interim mid-fi round (11 sessions), and Round 2 hi-fi (31 opened, 18 engaged).

The night it felt real: the basement room at Hooked on Colfax, watching a friend test it — seeing her start to understand how the thing works, reading her timings live, glancing over to catch what hung her up. That is exactly what the rig was built for. Four of five objectives were met. The check-in loop beat the budget: 82% of check-ins finished under ten seconds, with a median of 6.8. Dead taps fell 65%, which says the accent-only-on-interactive grammar earned trust. Asked to name their rank, participants said "Level" unprompted — the mid-fidelity change confirmed.

The misses I half-expected. I'd blitzed through the reward tasks so fast myself that I suspected the arrival moment was too quiet, and the numbers confirmed it: 75% completion and 5.27 ease against targets of 80% and 5.5. One participant named the cause — the confirmation screen returns home after three seconds. Results were satisfactory against the frozen plan, so the product shipped. Every miss became a numbered iteration: strengthen the reward arrival, pace the confirmation beat inside the budget, fix the last styled-but-dead control.

[ UNPLANNED FINDING ]Two participants pressed SHARE before checking in. I'd wanted a product that makes people show each other instead of telling each other — and here it was, unprompted. The flow now handles the case; the product rule is scoped for Round 3.
[ DESIGNLAB MENTOR · USER TESTING APPROVAL · 2026-07-30 ]"Positive results here, Luke, because the users are for the idea, and there's nothing major for you to change."
Iteration: Home V2 to the consolidated final version
FIG.08 — ITERATION · HOME V2 TO THE CONSOLIDATED FINAL VERSION · PER 07-30 RULINGS
Test harness comprehension tier
FIG.09 — TEST HARNESS, COMPREHENSION TIER · R2, HI-FI V4
07

AI collaboration

The tidy version of this section would say "the AI proposes, the designer ratifies." That's not how it actually worked. I proposed — I used the research to decide which patterns we'd build on, and modified them when the research didn't fit this context — and I delegated production: synthesis drafts, documentation, code, instrumentation. The principle is simple: delegate production, keep judgment.

Delegation at this scale requires governance, because the AI is fast and often flat-out wrong. It drifted from instructions, twice wrote interface copy implying mechanics the product does not have, and sometimes lost the ratifications I had asked it to hold. So every failure got fixed as process — a rule, a protocol, a charter — not patched and forgotten: nothing canon-adjacent ships unreviewed, and generation runs receive curated inputs only, because attached spec documents measurably caused visual drift.

The collaboration is reliable because of the rules, not the model. That's also my warning to other designers: the speed is real, and so is the supervision.

DropApp map screen
THE SHIPPED APP · MAP SCREEN, DENVER
08

Reflection & next steps

Almost every plan on this page broke — the interviews, the sitemap, the rank system, the shared design system — and every correction produced a stronger result than the original. The headline number is 6.8 seconds, measured on real phones against a thesis set on day one. The limits are on the record: a five-response survey and small comprehension-probe counts, named rather than smoothed.

Next steps are concrete. The Round 3 iteration list is scoped. The production build is specified: a web app, tiered NFC hardware, anonymous-first accounts. Events are on the calendar. I'm building what I wish existed, and using what other people told me to make it work for them — something cool, different, and interactive. The point is to inject a little magic back into reality.

The profit is identity. The design makes showing up feel like exactly what it is: the whole game.