The first is design. Screens look right in isolation and fall apart the moment someone is actually using the thing — one-handed, outdoors, deciding what to do next.

The second is the last 10% that takes 50% of the time. The app works, the team has been using it for weeks, and it has been sitting there for a month, because everything between a working build and a public listing is a different job from the one that got you here — signing certificates, provisioning profiles, privacy manifests, data-safety declarations, screenshots at six device sizes, an age rating, and a reviewer who rejects you for a reason nobody on the team can decode.

I work at both ends. I design the app, build it, and get it live on the App Store and Google Play.

I designed and built Ari, a cross-platform AI travel app — an OpenAI assistant custom-trained on loyalty program logic, Duffel flight and hotel booking, Award Wallet points syncing, push notifications, and a web admin panel for the founder's team.

Then I shipped it. Ari went through submission on both stores, is live and downloadable today, and launched to five-star reviews. Full source code and project files transferred to the client on completion.

I design around the decision, not the screen. The question is always what the person is trying to decide in that moment, and what the one view that answers it looks like. Everything else is secondary.

Users arrive in two modes. Some want to be told what's next; some would rather browse. For 4.0 Quests I built a guided path and an open archive side by side instead of forcing everyone through one door. Any app with real content inside it has that problem on day one, and picking one mode loses you half your users.

Density is the hard part. A map, a directory or a library needs clustering or filtering that works with a thumb, plus a list view for the people who'd rather scan than pan. That's a design decision, not a developer's problem to solve later.

The handoff is part of the design. You get a component library, real states — empty, loading, error, too much data — and specs a developer can build from. Or I build it myself.

I audit before I promise a date. The first pass is a readiness check against what actually gets apps rejected — permissions you request but never explain, a privacy policy that doesn't match what the app collects, placeholder assets, an account you can't delete from inside the app. I'd rather find those in week one than in a rejection notice.

Rejections are normal and I handle them. Most apps get rejected at least once. What matters is reading what the reviewer actually said, fixing the real thing, and resubmitting fast, instead of arguing or guessing.

You own everything at the end. The developer accounts stay yours. Signing keys, certificates, store credentials and a written release runbook all transfer, so your next update doesn't require me.

I don't do marketing — ASO copy, paid installs and launch PR are someone else's job. I won't publish your app under my own developer account. And I'm not taking over a build I can't see the code for.

A finished build that only needs to get through review starts at $4,000 and runs about three weeks. Design and build through to launch is a four-to-six-week project and gets a real number once we've scoped the screens. Either way, the code, the accounts and the keys are yours.