Designed and built the Drop-in iOS app

App design

Role
Product designer
Timeline
2 weeks
Team
4 people
The Drop-in home screen, with Book a desk and the activity tabs

Overview

Drop-in is an independent work club and coffee house with three sites in London: Clapton, Richmond and Wandsworth. Members rent desks, phone booths and meeting rooms by the hour.

Members working beneath a wall of framed prints at Drop-in Clapton
The coffee counter at Drop-in Clapton
The lounge and mezzanine at Drop-in Wandsworth
Phone booths at Drop-in Clapton
Phone booths at Drop-in Richmond
Desks at Drop-in Wandsworth
A dog under the desks at Drop-in Clapton
Plant-lined desks at Drop-in Richmond

What did I do?

  • Product strategy and the pitch to build in-house
  • User research
  • UI design in Figma
  • Building the iOS app in SwiftUI with Claude Code

Project timeline

Two weeks, six phases. We started by running a survey with users and understanding the problems with the current app. The main issues were getting through the door and the annoying payment pop-up that appeared every time they opened the app. Then, I made the case for building our own app and why we couldn’t fix these issues within the current one. Design came next. The early iterations were reviewed with our founder, not with members: we went through the flows together in Figma and changed them screen by screen. The build was done in SwiftUI on top of the existing Optix API. Members first saw it in a limited release on TestFlight, and that is where I learned the most.

  1. Ran a survey with users

    Week 1

  2. Pitch to build in-house

    Week 1

  3. Design iterations with the founder

    Weeks 1 to 2

  4. Build the app using SwiftUI and the Optix API

    Weeks 1 to 2

  5. Limited release to members on TestFlight

    Week 2

  6. Ship

    Week 2

Problems with the app we had

    Valentina

    • Books a desk most weeks at Clapton
    • Uses the gates several times a day
    • Opens the app on a Tuesday morning to book a desk before heading in
  1. A payment method, before anything else
    Every time I open it there's a pop-up before I can do anything. I only came to book a desk.
  2. The old app's home screen
  3. Two listings, both called Wandsworth Full Day
    I never know which one to pick. The names don't tell you whether it's a desk or a room.
  4. One time slot available, eight until seven
  5. The booking, as a record with invitees and a payment account

    Valentina

    • Books a desk most weeks at Clapton
    • Uses the gates several times a day
    • Gets to the club and opens the app to let herself in
  1. The same payment sheet, on opening the app again
  2. Home again, with Unlock doors as one tile among several
  3. All locks, listed by name, each one a tap further in
    That's a lot of steps just to open a door. Ohh, I have to do these every time I want to get in.

The main blocker

We couldn't change things in the app easily, because it was built using a third-party software called Optix.

Main decision

Since there was so little we could change in the app we had, the real question was whether to build our own. We put both options side by side and wrote out the pros and cons: keep asking Optix for changes, or build a new front end on the same data.

Deciding factors

API call limits
Time
Maintenance cost
Testing
The blockers sheet: each thing we wanted, whether it could be built on Optix, what could be built and what couldn't

The plan I pitched

Before writing any code, I wrote the founder a plan: keep Optix doing the heavy lifting underneath, and build a better front end on top of it.

  • Three paths side by side: leave the Optix app alone, embed our own screens inside it, or build a full custom app.
  • Two goals to test first: do members actually want it, and can Optix’s API support it, rate limits included.
  • How we’d make the call, a short plan, and the risks, like maintaining a second app forever.

The rate-limit question was the one to answer first, so I took it straight to Optix.

The plan shared with the founder: where we are, what I'm proposing, and the three paths compared in a table

What Optix told us

Before deciding, I asked Optix whether our app could run through one shared API token. Their reply settled it:

  • One shared token is capped at 60 requests a minute, for the whole club.
  • They won’t raise the cap for a setup like that.
  • Instead, each member signs in and gets their own token, the way Optix’s own apps work.

So the app signs every member in with their own token, and the limit never becomes a club-wide bottleneck.

The reply from Optix support on shared tokens, the 60 requests a minute limit and per-member access tokens

Why not Apple Wallet?

Tapping an iPhone at the gate needs a Kisi Apple Wallet pass, so I asked Kisi whether members could get one.

  • New Kisi users need an organisation email, and our members are customers, not staff.
  • The Wallet pass is a one-time setup inside the Kisi app.
  • Every member would have to install a second app just to open the door.

So entry stays inside the Drop-in app, one tap away from the Home Screen.

The email to Kisi asking how members could get door access, ideally a Kisi Apple Wallet pass, without an organisation email

Design iterations

Design decisions

The design went through three rounds, each one reviewed with our founder in Figma. The first round was a list of desks, a time grid and a home screen full of shortcuts and banners. Everything was there, but nothing stood out. In the second round I gave home one main action, a single Book a desk button at the top, with your next booking, perks and membership plan below it. I also added a quick rating after each visit, so we could hear from members without sending another survey. The third round swapped the desk list for a 3D floor, so members pick a seat by seeing where it is rather than reading its name. The rule across all three stayed the same: put what members came to do first, and let everything else wait underneath.

Redesigned the homescreen

The old app put a payment method in front of you before it let you do anything. Added a clear Book a desk button, as this is the main action members take.

Redesigned the homescreen

Clear resource type

A desk, a phonebooth, a meeting room, shot in the actual space, so you recognise what you are booking before you read a word.

Clear resource type

Booking a desk in 3D

  1. 01

    A free desk is already picked

    Taken desks have someone sitting at them. Tap any free one to switch.

  2. 02

    See what’s at the desk

    The info button shows the monitor, the chair and photos of that spot.

  3. 03

    Pick an hour and book

    Choose a slot, or set your own start and end time, then confirm.

After booking

  1. 01

    Booking confirmation

    A sheet comes up with the resource type, the date, the hours and the address of the club you booked.

  2. 02

    Access the space CTA

    Once a booking is live, Book a desk turns into Access the space.

Getting in

  1. 01

    Open Doors widget

    Added once from the widget gallery: hold the Home Screen, tap Edit, then Add Widget, and search for Drop-in Club.

  2. 02

    One tap to the gate

    Tapping the widget opens the app straight on your doors, skipping Home and the menus. One more tap unlocks the gate.

Edge cases

  • No connection: Please check your internet connection
  • Fully booked today: the 3D desk hall with someone at every desk, and every desk crossed out
  • Closed: the Drop-in Wandsworth entrance in 3D, a red CLOSED banner on the shut doors
  • Events: No events available

Illustration library

Built with the Magnific MCP: Larry, the Drop-in mascot, in ten poses, plus spot illustrations for empty states, access and perks, all in the brand purple.

  • Larry waving
  • Larry working at a desk
  • Larry celebrating
  • Larry with a coffee
  • Larry dozing
  • Larry with friends
  • A door unlocking
  • An empty desk
  • A cloud with an unplugged cable
  • An empty calendar
  • A coffee cup with a discount tag
  • A gift box and coins

Asking the testers

Every TestFlight tester got a short form, to fill in only after they had actually been into a club with the app.

It asked three things: could you book a desk, could you get through the door, and how did the app feel. It also said what was still in progress, so nobody reported a missing feature as a bug.

The Google Form for testers: New Drop In app, with the intro text and the first questions

What the survey showed

  • Survey chart: Which club were you using?
  • Survey chart: How much have you used the app so far?
  • Survey chart: Were you able to book a desk?
  • Survey chart: How easy was booking a desk?
  • Survey chart: If booking did not work, what happened?
  • Survey chart: Were you able to open the door with the app?
  • Survey chart: If the door did not open, what did you see?
  • Survey chart: How confident did you feel walking up to the door?
  • Survey chart: How much did you like the look and feel?
  • Survey chart: Compared with the current Drop In app
  • Survey chart: How likely are you to recommend this app?
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen
Drop-in app screen

Building it with AI

This was the first time I built an iOS app by myself. I never really liked coding, but with agentic AI tools like Claude Code and Codex, it has become much easier to build apps when you have the right guardrails in place.

While I was building it, my biggest concern was the API call limits of the Optix API. I wanted to make sure the app would continue to work as we scaled, so I had several meetings with the Optix team. We eventually used the per-member API to solve this problem.

This project also taught me a lot about how AI can make mistakes if you don’t prompt it well or give it the right guardrails. I ended up creating a framework for consistently getting the output I wanted from Claude by using different MCPs, including Mobbin, LottieFiles, Magnific, and Figma. These helped give Claude the context it needed to produce better results.

VS Code with the app's scripts open and Claude Code working in the side panel
The MCP servers Claude could reach: Figma, LottieFiles, Magnific, Mobbin, Framer and others

Reviewed before TestFlight

Before the build went to members, I ran the whole app through a code review prompt that makes Claude review like a staff iOS engineer: looking for the things that bite a team three months later, not style.

Every finding gets a severity

BlockerShould-fixConsiderNitQuestion

Ten areas, security always

Memory, concurrency, architecture, Swift correctness, SwiftUI, performance, networking, testing and API design, plus a mandatory security pass that traces every outside input, every token and every trust boundary, such as the app and the backend, deep links and the door widget.

The review prompt in a dark code editor: role, severity tags, the ten-area checklist and the vulnerability hunt protocol

What could have been better

  1. 01

    More design iterations

    The design could have gone through more rounds, with different variations of each screen to compare before choosing one.

  2. 02

    Function came first

    Most of the effort went into making it work: the Optix API, rate limits and scaling. That left less room for the experience.

  3. 03

    Baristas were left out

    Baristas use the app too, but they have a separate user type on Optix and could not get into the new app. This was the biggest issue flagged.

Thanks for reading.