Let's Work Together — heyjaycodes.com

I’m a senior iOS developer who can also ship the backend, and I’m looking for my next project. I’m open to a few kinds of work:

A full-time role on a team building an app
A contract to build a new app from the start
A one-time job, like a feature or a bug fix you need someone to pick up

If any of those sound like what you need, hire me on Toptal or email me.

What you get

A senior iOS developer who can also ship the backend

I’ve been shipping iOS apps in Swift for seven years, and I write TypeScript on the frontend and the backend. Most apps need a server for something, and when yours does, I don’t have to stop and wait for someone else to build it. I can build the screen and the server it talks to, so a feature doesn’t stall at a handoff between two people.

I’ve done that on a team, and I’ve done it alone.

On a team, it was Matter. The app started with almost no backend, so when it needed somewhere to keep users’ photos, there wasn’t a backend developer to hand it to. I built Hippo to spec myself, writing both the iOS client that sends the photos and the Swift server on AWS Lambda that stores them. Later, the person who handled our AWS infrastructure left, and because I’d built the server side of Hippo, I was the one who could take it over. Working on both sides meant the photo feature didn’t wait on a server developer, and the infrastructure didn’t go unowned when someone left.

Alone, it’s Tobi, my home maintenance app, where I built the iOS app and the backend by myself. The backend runs serverless on Firebase, so it can look small until you hit something like sharing a house, where one person’s subscription has to unlock the house for everyone who shares it. In the app, I built the invites, the members list, and the paywall. On the server, I wrote the Cloud Function that turns an invite into a membership, the security rules that keep each household’s data visible only to its members, and the RevenueCat webhook that unlocks every household a person owns when they subscribe. That feature needed both halves, and I built both.

That’s what you get on your app: someone who can take a feature from the screen to the server and ship the whole thing.

Someone who knows when to follow Apple’s guidelines and when to bend them

I think apps should feel like they belong on the platform they run on, so an iOS app should feel like it belongs on an iPhone. The best way to get there is to follow Apple’s Human Interface Guidelines, since people already know how iOS apps work and an app that follows them feels familiar from the first launch.

At Matter, following the guidelines is how I kept the app feeling like an iOS app. I worked with our designers in Figma, and when a design didn’t feel like it belonged on an iPhone, or broke a guideline without a good reason, I pushed back on it.

“Without a good reason” matters, because sometimes there is one. The guidelines say the tab bar is for navigation, not actions. But adding a memory was the main thing people did in Matter, and plenty of content apps already put their main action in the tab bar, so people would already know what the button did. That was a good reason, so I suggested an add button in the tab bar, and it shipped with the app. Bending the rule didn’t make Matter feel less like an iOS app, because the button worked the way people expected.

That’s the call I’ll make with your designers too: follow the guidelines by default, and bend them when there’s a reason.

Database design, relational or not

I’ve designed data for relational databases and for NoSQL databases like Firestore and DynamoDB. They reward different designs, so I shape the data for the database it lives in. Matter and Tobi show both sides.

Matter runs on Postgres, so I designed its data around how Postgres works. Postgres is built for data that relates, so the design starts from the user and connects everything back to them, using three main tables: users, memories (the journal entries), and events.

Everything points back to one user. Matter identified people by their iCloud ID, not a login. The users table held each person’s iCloud ID and any other identifiers, and memories, events, and every other table pointed to it with a foreign key, so everything in the database mapped to the right person.
Anything that happens is an event. Things that happened in the app, or came in from a webhook like a RevenueCat subscription change, were recorded as rows in the events table. That gave the rest of the backend one record of what each user had done, so when we needed something new to happen, we could build it on the events we were already recording.
Access goes through roles. Supabase’s row level security is built around Supabase Auth, which Matter didn’t use, so I used role-based access control to decide who could read and write each table.
Configuration lives in the database. The level configuration lived in its own table instead of being hardcoded, so our product team could tweak the levels from their own dashboard without waiting on a developer.

Tobi runs on Firestore, so I designed its data around how Firestore works. Firestore doesn’t do joins, and you pay for every document you read, so the design starts from the screens and what each one needs to load.

Everything lives under its household. Each household’s tasks, home elements, contractors, members, and panels all sit under that household’s document. The security rules check membership once, at the household, and that covers everything in it.
Lists load in one read. The main maintenance list is a single listener on a household’s tasks, sorted by due date. Each task carries a copy of its home element’s name and manual link, so the list never has to look up the element. The members list works the same way, with each member’s name and photo copied onto their membership.
Every copy has one writer. Copied data is only safe if it stays in sync, so each copy has exactly one place in the code that writes it. When you rename your furnace, that one place updates every task that points to it.
History and state change together. Completing a task records it in the history and moves the next due date in the same batch, so the two can never disagree.
Membership goes through the server. The app can read who’s in a household but can’t change it. Joining, leaving, and changing roles all go through Cloud Functions, so the rule that every household keeps at least one owner is enforced in one place.

Apps that ship and pass App Review

App Review can hold up a release over something small, and I know what it usually checks for.

Some rejections are easy to avoid once you know about them: a paywall without a link to the privacy policy or a way to restore purchases, or reviewers who can’t get into the app to try it. I handle all of that before the app goes in. I put the privacy policy link and the restore button on the paywall, and give reviewers a demo account with the paid features unlocked and reset it before every submission. When I launched Tobi that way, it passed App Review on its first submission, and it’s never been rejected since.

Review covers the App Store listing too, not just the app. At Matter, when I saw the new App Store screenshots, I flagged that the first few didn’t show enough of the app. Marketing and our head of product decided to submit them and see if they’d pass, and Apple rejected them for that reason. I went back to marketing and got another screenshot of the app into the first three slots. If I see something that will get rejected, I’ll say so before it’s submitted, even when it isn’t my part of the release.

Getting through review is one part of shipping, and I’ve handled the rest of it too. At Matter, I handled release work like App Store submissions, TestFlight betas, CI, and feature flags, and we released every week on schedule. On Tobi, I set up regional pricing and localization across multiple App Store storefronts, and handled subscriptions, restores, and refunds through RevenueCat.

Someone who makes unclear requirements clear

I like working from clear requirements, but when a feature shows up without them, I don’t wait for someone else to fill in the gaps. I help figure out what we’re actually building before anyone writes code, because that’s when changing it is cheapest.

When I get a spec, I read it alongside the designs and look for what it doesn’t cover, and I put myself in the user’s place and try the things I’d actually do in the app. I also read it against the data model to see what we already have, what we don’t, and what the feature will need, and since no feature lives on its own, I look at how it will affect the rest of the app.

Every gap I find goes back to product and design with a solution attached, so we spend the conversation choosing an answer instead of discovering a problem. Once the spec describes in detail what the feature does and how it should work, I write a technical doc on how I’ll build it, so both the what and the how are written down before I start coding.

At Matter, product made the final call on those gaps, and they usually went with the solution I brought. So on your team you’d get someone who finds the gaps early and shows up with answers, not just questions.

How I work

Hours: I prefer 7am to 3pm Pacific, but I’m flexible if the right role needs something different.
Location: I work remotely, and I’m happy to travel for in-person meetings a few times a year.
Communication: Async works great for me, and I’m always up for a video call when that’s faster. I respond quickly on Slack or whatever chat tool your team uses.

I leave a trail

Documentation matters even more now that AI writes so much code. The next person to touch the work, or the next AI agent, needs to know why it is the way it is, not just what it does. I take good notes and write down decisions as I make them, so nobody has to reverse-engineer a decision from the code six months later.

I use AI, and I check its work

AI helps me plan, write issues, and work through the code. Alongside the code, I come up with a plan for verifying the change, whether that’s unit tests or a page of UI screenshots, and that gets built and run too. By the time a pull request reaches anyone else, I’ve already reviewed it and the checks have already passed. I don’t want to waste another person’s time reading AI slop.

On Tobi, that verification is built into every pull request. The UI tests take a screenshot of every screen in light and dark mode, and CI posts them to a page linked from the pull request, so I can check a UI change without running the app. The unit tests have caught regressions before they shipped, and the screenshot pages made me faster. That checking happens before anyone else sees the code, so the person reviewing my pull request isn’t the one catching AI mistakes.

What I’m looking for

I’m happy to work on whatever needs doing: a new app, an app that’s been on the App Store for years, a single feature, or a bug fix. Frontend or backend works too. I don’t need to build the next flashy feature, as long as what I build helps us hit the goal we’re going for.

If I get to pick, new apps are my favorite. I joined Matter before it launched, helped ship it, and got to see it become App of the Day on the App Store. I think about the product, not just the ticket in front of me, and I like owning a problem from the first report to the fix.

Hire me on Toptal or email me, whether you’re building something new, maintaining an app that’s already out, or have a feature or bug that needs picking up. I’d love to hear what you’re working on.