Founding designer & design engineer · 2025–2026

Gofer: a social wishlist that learns what you and your friends love.

I ran design for wealth at BNY. I left to be the founding designer on a consumer app, and the job turned out to be building the whole thing.

Role
Founding designer. I also wrote the iOS app, the backend, and the marketing site.
Before this
Head of Design for Wealth at BNY. Six designers, regulated software, four years.
Shipped
An iOS app, shipped through TestFlight beta to the App Store, with real users. Plus a live marketing site.
Built with
SwiftUI · Python and FastAPI · PostHog · AI coding agents, reviewed on device.

Gofer is a consumer iOS app. You save products you want, you see what the people you trust are into, and it gets sharper about your taste the more you use it.

I built it. The iOS app, a Python backend, a SwiftUI design system, and the marketing site are all work I shipped, most of it by directing AI coding agents and checking every change myself.

The problem and the bet

People find products everywhere. Instagram, a store window, a friend's text, a screenshot they will never see again. Two things are broken at once: saving is a mess, and trust is thin. Most recommendations come from an algorithm or a paid influencer, not from the people you actually believe.

That was the bet: a save button you trust, made social, that learns.

Three lessons, one direction

The product went through three shapes before it found the right one. From the outside it can read like three pivots. Up close it was three lessons pointing the same way.

Start: social discovery

Show people the products their friends love. They liked seeing it. Then they kept trying to save it. The real signal was not "show me more," it was "let me keep this."

Then: a social wishlist

Save and organize what you find, and see your friends' lists too. Closer. But a bare list of products did not feel like mine. One person in testing said the quiet part out loud.

A wishlist nobody else can see is annoying, and a wishlist that does not know you is just a spreadsheet.

Now: taste at the core, wishlist on top

The app learns what you like first, and the social wishlist sits on that foundation. The first time we read a taste profile back to someone in testing, a person we had never met said, "that's me." That was the moment the product worked.

The constant under all three: help people find things they will love, through their own taste and the people they trust.

Where design and engineering were the same job

Three pieces of the work where the design decisions and the code were one task, done by one person.

The Taste Tab

A short quiz that builds a taste profile and feeds recommendations. I designed the flow and the interface, then wrote it across the iOS app, a Python and FastAPI backend, and a 490-item product catalog the recommendations pull from.

The choice underneath it: an explicit quiz, or infer taste from what people save. Inferring is what most taste products reach for, and it is lower friction because you never ask the user for anything. But it needs weeks of behavior before it can say anything true, and a wishlist with nothing in it is a dead app on day one. So I traded cold-start friction for a profile that works on first launch.

Screen recording · coming soon The quiz building a real taste profile, start to finish.

DigUI, a design system in SwiftUI

Cards, buttons, badges, loading states, built from scratch. Before it, color values were scattered across 30 files. I pulled them into one shared set the whole app reads from.

In 2019 I designed design system components for someone else to build. In 2026 I built this one myself, in SwiftUI.

Component sheet · coming soon The DigUI set, and the color tokens before and after.

Onboarding and analytics

I rebuilt the first run from 11 steps to 8 and added passwordless email sign-in. To see where people fell off, I set up a PostHog funnel with privacy-safe session replay.

How I worked: judgment, not keystrokes

I delivered features across three codebases (iOS, backend, web) by directing AI coding agents, often more than one at a time, then reviewing and testing every change on a real device. I decide what to build and why, I give the agent the context it needs, and I own whether the result is right.

One "clean" release taught me the edge of that. A code review passed two bugs that only showed up once you actually lived in the product. Reading code and using the thing are different skills. After that I stopped trusting a green checkmark and started asking for the root cause.

What shipped, honestly

What is built and running: an iOS app shipped through TestFlight beta to the App Store, in real users' hands, with the Taste Tab, the DigUI design system, and the rebuilt onboarding. Next to it, a live marketing site with custom illustrations, two A/B-tested landing pages, analytics, cookie consent, and a waitlist.

The honest part: this is an early product, not a finished success story.

The strongest evidence so far is qualitative. The taste profile lands. People reach for the save before we ask them to.

What I took from it

I stopped trusting a green checkmark. That is the smallest way I know to say what changed: I used to hand work over and trust the review, and now I use the thing myself before I believe it works. It made me slower on the day and faster over a month.