The Problem

Every time a client calls, most people open 3 apps. One to find the contact. One to check the project. One to find the notes from the last conversation. None of those apps know about each other, and none of them were built for professionals whose day moves constantly between people and projects.

That’s the gap Clients was built to fill.

Insights

Apple’s Notes, Contacts, and Reminders work well when your life naturally compartmentalizes. If most of your day lives inside one of those apps and the others are occasional, the separation creates no friction.

But for the professional whose work depends on all 3 knowing about each other, that model breaks down fast. The contact without project history is just a name. The project without conversation notes is missing context. You become the glue between 3 apps that don’t talk to each other.

This was an opportunity to rethink the model. Apple’s apps work well in isolation, but for independent professionals the real problem isn’t missing functionality. It’s that the system has no shared context.

Clients solves that integration problem. Not 3 apps bolted together, but one system where the person is always at the center and everything else, projects, milestones, issues, conversations, notes, and follow-ups, lives alongside them.

Testing

Before I built Clients, I ran a quick test. Over a weekend I put together a rough app called Sharpen, a standalone project management app with contacts attached.

It wasn’t polished, and it wasn’t meant to be. It was a test of 2 questions: whether I could build a native Mac app at all, and whether combining contacts with project management would feel useful or just cluttered.

Both questions got answered quickly. The Mac build worked. And the combination felt immediately right. That weekend gave me enough confidence to commit to building the real product.

Key Decisions

Flexibility over imposed structure

The product needed a structure that could adapt to different mental models without losing clarity. That meant resisting a rigid workflow and building flexible organization into the system from the start. A designer, a real estate agent, and a contractor do not categorize their clients the same way. Teams and Tags handle that without forcing anyone to adapt to the app’s logic. The structure follows the user.

That flexibility also revealed something important. The original audience was independent professionals, but the underlying need turned out to be broader: managing a list of people alongside work attached to those people. An HOA president tracking 80 homeowners has the same structural problem. So does a student managing relationships with professors and advisors. The audience widened because the system exposed how common the need really is.

Reading feedback before acting on it

During TestFlight, a user asked for due dates on issues. My first instinct was to add them. Then I checked the form. The field already existed, but it was buried too low for most users to encounter at the right moment.

Moving it higher resolved the feedback without adding a single feature. It was a reminder that when users ask for something that already exists, the problem is usually information hierarchy, not missing functionality.

Development

The process started with hand-drawn sketches in Apple Freeform, working through user flows before making visual decisions. Only after the experience was clear did I move into Figma to build a full component system.

The final app is native SwiftUI on both iOS and Mac, sharing a single codebase, designed and built entirely by one person from initial concept through App Store submission.

Brand System

I created the full identity for Clients alongside the product itself, including the name, logo, color palette, and visual language. The brand needed to feel personal, practical, and professional, more like a well-made tool than a piece of SaaS software. That meant building a system that felt warm and tactile, with the confidence of a native app rather than the complexity of enterprise software.

Lessons Learned

Building Clients changed the way I think about design leadership. Strong product decisions are not opinions defended in a meeting. They’re hypotheses tested against real behavior, then refined until the product becomes clearer. That process made me a better design leader because I stopped having opinions about product decisions and started having evidence.

Building Clients made me a better design leader because I stopped having opinions about product decisions and started having evidence.