Closing the Loop: Why I'm Building the iOS Client for ClickNBack
Last week I wrote about something that crystallized over months of building: that 1+ years in the backend didn’t make me a backend engineer. It made me a better iOS engineer. That realization didn’t arrive as a disappointment. It arrived as clarity. And it prompted a decision I’ve been sitting with long enough that I need to stop avoiding it.
The backend is production-quality. The API is documented and running at clicknback.com/docs. Every domain boundary, wallet constraint, and audit trail is baked into a system I understand from first principles. I write about the engineering decisions every week. And yet — from a user’s perspective — the product ends at the documentation page. No one uses it. Nothing touches a screen.
A backend, no matter how solid, is an incomplete product. A backend + iOS client is a complete product loop. And I’m the person who understands both sides of that loop completely. Not because I’m trying to be full-stack. Because I’m trying to own the thing end-to-end.
The Side I Already Knew
A few years before this sabbatical, I spent twelve months as the iOS developer at a cashback startup. I built what users touched: the app, the purchase flow, the wallet screen, the history list. I owned the experience side completely. And every day, the backend team on the other side of that API boundary was doing work I was curious about but never had to do — wallets that balanced to the cent, reconciliation jobs running overnight, idempotent payout logic designed for the bank changing its mind. I could see the effects of their decisions in the data I received. I didn’t know how they made them.
ClickNBack has been my answer to that curiosity. I’ve spent two months building the backend I watched from the client side — and now I know exactly how those decisions get made, because I’ve made them. But there’s something quietly telling about the fact that I spent a year building precisely what ClickNBack is still missing: the thing users actually see.
So I’m building the iOS client.
Why This Isn’t Full-Stack, It’s Product Engineering
Over the past month, I’ve been thinking out loud about where to position myself. The market’s stratifying in ways it hasn’t before. Depth alone is suddenly vulnerable—AI learns technical domains faster than any specialist can stay ahead. But judgment about where to go deep is rare and valuable. What I realized through this thinking is that owning a complete loop amplifies your credibility in a way that fragmented expertise never does.
I’m not building the iOS client to be “full-stack.” Full-stack is a statement of coverage: I can work on both layers. That’s a commodity now, and honestly, I was never going to compete with dedicated backend specialists on backend alone. What I’m actually doing is something different.
The software industry has a name for this way of working: product engineering. Lee Robinson, VP of Developer Education at Cursor, describes the product engineer as someone who “works backwards from the desired product experience” to the technologies that serve it (1). PostHog’s entire handbook on the topic emphasizes: product engineers “care more about outcomes and impact than the exact implementation, or the tools used to solve the problem.” (2) This isn’t a skill set. It’s a starting position. User first, technology second.
When I started this sabbatical, I thought the move was: become a backend engineer. Broaden beyond iOS. The logic was conventional—specialize deeper if you want to stay relevant. But that logic was built for a world where AI wasn’t learning your domain faster than you could, and where full-stack was genuinely unusual.
What I’ve actually discovered is that a senior iOS engineer with hands-on production backend experience, DevOps knowledge, and the ability to reason about entire product loops is far more valuable than a junior backend specialist. This isn’t a lateral move. It’s a reposition. I’m not going back to iOS at the same level I left it. I’m coming back as a product engineer who understands the complete system beneath the user experience.
What Comes Next
The technical deep dives continue. Client interfaces, API design, the message broker pattern, background jobs — the ClickNBack architecture is rich enough to earn several more substantial posts, and I’ll write them. But something about the frame has shifted fundamentally. I’m not building a backend to demonstrate backend skills. I’m building a complete product to demonstrate product judgment.
The iOS client isn’t a return to iOS engineering the way I left it. It’s the realization that I can’t think about great product experience anymore without understanding what it costs to build. Every screen layout I design, I’ll be thinking about the query patterns it creates. Every interaction I ship, I’ll understand the reconciliation jobs running overnight that make it possible. Every animation I craft, I’ll know the actual infrastructure costs in terms of latency and data consistency.
That’s not expertise acquired separately—backend expertise plus iOS expertise stacked on top. That’s integration. That’s what changes when you own the complete loop. The iOS client, from the perspective of a junior iOS engineer, might look like I’m going backward. From the perspective of someone who’s held the entire system in their head at once, it looks like finally being able to ship the product I’ve understood from both sides.
The next series documents the client build in the way everything has been documented: decisions, trade-offs, moments where six years of Swift experience intersects with a domain now understood from both sides. What gets built. How it shapes. And why owning the loop completely changes what you’re actually capable of shipping.
(1) https://leerob.com/product-engineers
(2) https://posthog.com/product-engineer/what-is-a-product-engineer