The Best App I've Built Has Exactly One User
Every developer I know has the same graveyard: side projects that died the moment they became products.
You start building something for fun. Then somewhere around week three, a voice creeps in. Could this be a SaaS? Should I add auth? What about onboarding? Pricing tiers? And just like that, the fun project becomes a second job with zero salary. The graveyard gets one more headstone.
Earlier this year I tried the opposite experiment. I built an iOS app that will never have a second user. On purpose.
Everyone wants a JARVIS
The itch was simple. My personal data lives in a dozen places - finance here, health there, my DevOps and self-hosted infrastructure somewhere else entirely. Every app I used was someone else's idea of what I needed, padded with features I didn't want and missing the three things I actually did.
What I wanted was what Tony Stark has: one assistant that knows my stuff. Not a general-purpose app dressed up for millions of users. Something built around exactly one person's life.
So I built it. Finance and health first, more modules folding in as life demands them. Naming it was easy once I stopped overthinking: JARVIS is personal to Tony - copying the name would've missed the point. So I carved three letters out of my own name. JIB. One syllable, fits on an icon, unmistakably mine.
Two brains, both local
The interesting engineering decision in JIB is that no query ever leaves hardware I own. It runs on two AI brains, split by weight class.
The first is Apple Foundation Models - the on-device model Apple ships with Apple Intelligence. It handles the fast, always-available layer: parsing what I said, structuring my data, quick summaries, the small intelligence an assistant needs a hundred times a day. It costs nothing, works offline, and the latency is effectively zero because the model is already sitting on the phone.
The second brain is Gemma 4 12B, running in LM Studio on my MacBook and exposed to the phone through a Cloudflare Tunnel. When JIB needs actual reasoning - "look at three months of my spending and tell me what changed" - the request rides the tunnel to the laptop. Gemma 4 12B is a fascinating model for this job: it's Google's encoder-free multimodal release, small enough to run comfortably in unified memory on Apple Silicon but with reasoning that punches well above its size. My "AI server" is a laptop I already owned.
Would I ship this architecture to a client? Never. Does it work beautifully when one person controls both ends? Absolutely. That's the freedom of an audience of one: the only stakeholder meeting is the one in your head, and it always ends in agreement.
UI that builds itself
The other thing I wanted to escape was the chat bubble.
Every AI app today is a text thread wearing a different coat. But when I ask JIB about my monthly spending, I don't want a paragraph describing a chart - I want the chart. So JIB's interface is generative: the model doesn't return prose, it returns a structured description of the screen, and the app renders it as native SwiftUI on the fly.
Ask a finance question, get a breakdown with the numbers laid out as cards. Ask about health trends, get a trend view. Ask something that needs a follow-up, and the model can put actual controls on screen instead of asking me to type. The AI isn't a feature bolted onto a fixed UI - the UI is the AI's output format.
This flips a habit I didn't know I had. For a decade I've designed screens first and wired data into them. Here the model decides what the screen is, and my job shifts to designing the vocabulary of components it's allowed to speak. It's the most genuinely new UI work I've done in years, and I'd never have tried it on a project where a product owner needed pixel-perfect mocks up front.
(There was still room for old-fashioned craft, of course - I'll just admit that the app icon, a binary dot matrix spelling out j-i-b, received more evenings than any icon reasonably should. Some tickets only exist on personal projects.)

The graveyard test
Here's the insight I keep coming back to: most side projects don't die from lack of time. They die from an imaginary audience.
The moment you start building for hypothetical users, you inherit their hypothetical demands - and hypothetical users are the worst clients in the world. They demand everything and pay nothing. Real projects with real users are worth that weight. Fake ones aren't.
JIB carries none of it. No launch to fumble, no growth to chase, no metric to disappoint. It just has to be useful to me tomorrow morning. Some weeks that means a new module. Some weeks it means nothing, and the app doesn't churn.
And the skills compound anyway. On-device foundation models, generative UI, tunneling a local LLM to a phone - all of it walked straight back into my professional work. The playground funded the day job, not the other way around.
So this is my case: build something with exactly one user. Not as a stepping stone to a product. As an instrument - the way a carpenter builds their own workbench.
Nobody else will ever see my best app. That's what makes it my best app.