iPhone-first isn't a limitation

I get this question in every product conversation: "When are you adding Android?"

The answer is: not in the near term. By design.

BoardSnap is iPhone-first. That means the app exists for iPhone. It means every design decision optimizes for iPhone. It means when Apple ships a new iOS capability, I can use it immediately. It means I'm not building to a lowest common denominator or maintaining two native codebases.

This is a bet. Here's why I made it.

### The camera is the product

BoardSnap's primary input is a camera. Not a keyboard, not a form, not a file upload — a camera. The quality of the camera and the quality of the software that uses it are the core of what makes BoardSnap work.

The iPhone's camera system — hardware and software together — is the best mobile camera platform for this use case. VisionKit runs on the iPhone and integrates with the Neural Engine. The perspective correction that makes BoardSnap snaps reliable happens on-device, in real time, using Apple's computer vision stack.

Building cross-platform means either using a cross-platform scanning library (which isn't as good as VisionKit) or maintaining two native implementations. The first option compromises the product quality. The second option doubles the engineering surface area for a solo builder.

### Focus is a real product advantage

When you design for one platform, every pixel of your design is optimized for that platform. There are no compromises for platform compatibility. There are no edge cases that exist only because of how another platform handles a specific interaction.

In BoardSnap, every gesture, every animation, every interaction is designed for iOS. The scanner modal is the native VNDocumentCameraViewController, which Apple has been optimizing for years across hundreds of millions of iPhones. The share sheet is the native iOS share sheet, which users already know how to use. The notifications are local iOS notifications, which respect Do Not Disturb and Focus modes natively.

None of this would work on Android. Or rather — it would work differently, at a significant rebuild cost, with different behavior that would require re-testing.

### The iPhone user is the right early customer

Product teams, founders, and consultants — the primary audience for BoardSnap — are heavily iPhone. This isn't universal, but it's true at the adoption rates that matter for an early-stage product. The people who are going to use a new tool, evaluate it critically, give real feedback, and pay for it are disproportionately on iPhone.

If 80% of my target early customers are on iPhone, building for Android to capture the other 20% means doubling my engineering surface area for a 25% increase in addressable customers. That math doesn't work when you're one person trying to ship a quality product.

### What iPhone-first enables

• Live Activities for tracking analysis progress on the Dynamic Island and Lock Screen
• VisionKit for on-device document detection
• Core Data with CloudKit for seamless sync across the user's Apple devices
• App Clips for try-before-download flows
• Siri Shortcuts for voice-triggered snaps
• Widgets for quick access to recent boards

I haven't shipped all of these in v1. But the architecture supports them, and I can add them without any consideration for cross-platform compatibility.

### When I'll revisit this

When the iPhone-side of the product is genuinely complete — all the features that make it a great iPhone app are shipped and stable — I'll look at what expansion means. That might be an Android app. It might be a web companion for desktop viewing. It might be something else.

But I'll make that decision from a position of strength on one platform, not from splitting effort across multiple platforms from the beginning.

Being iPhone-first is a commitment to quality over coverage. I'll take that trade every time.