Native App Developer

Job Type : Full-Time Salary : Based on experience Advantage to have : Experience with Accommodation systems Experience : Min 5 years experience in a comparable role Location : Surfers Paradise, Gold Coast | Remote Location Gold Coast, Queensland. Remote considered for the right person in a compatible time zone (AEST). Who we are Homhero makes cloud software for people who manage short term rental properties. Booking, availability, pricing, guest messaging, cleaning, owner reporting, and the connections to channels like Booking.com, Airbnb, and VRBO all run through our platform. We are a small team based on the Gold Coast and we love what we do. Where the stack is, and where it is going Right now a good part of the product runs on a legacy PHP core with a Sencha (Ext JS) frontend. It works, it carries real traffic and it got us to where we are now. It is the present, not the direction. The direction is already underway. We have a newer engine written in NestJS and TypeScript that we are actively building out, and a React frontend taking over from Sencha. The plan is clear: retire the PHP core, consolidate into the TypeScript engine, and modernize the frontend. That is where you come in. You would be building the new things while helping move what matters off the old ones. Expect time in both, with the balance shifting toward the new stack as the work progresses. What you would actually work on Building and owning our React Native app: architecture, features, performance, and the release process behind itShipping a real app to the App Store and Google Play, including signing, provisioning, review, and staged rolloutsExpo and EAS for builds, submissions and over the air updates, along with the judgment for when Expo helps and when you need to drop below itHelping build our UI library alongside our lead product designer, shared with the React web frontend where sharing makes senseThe parts of mobile that are not just React with different components: offline behavior, background sync, push notifications, deep links, camera and file handlingWorking against the API surface of our backend, and telling us when the shape of it makes the app harder than it needs to beWriting tests that proof: unit, component, and end to end on a device or simulator, not just one of the three About To be concrete about what sits under all of that, here is the current landscape. Read it as a picture of the work, not a checklist you have to arrive fluent in: Mobile: We currently ship a few PWAs and would love to now move to a more native experience to take advantage of push notifications and a few other things. These apps are built in Ionic + Angular and some even still use some jQuery to make things interestingBackend: NestJS and TypeScript on the new engine, PHP on the legacy coreFrontend: React for the new web interface, Sencha (Ext JS) on the old oneInfrastructure: AWS, mostly Lambda and EC2, with RabbitMQ for messaging You will not touch every one of these every week and nobody expects you to walk in knowing all of them. It is an honest snapshot of what the job involves and what you would pick up along the way. The UI library We are rebuilding the interface and we want the components to be a real library rather than whatever accumulated in a components folder. That means component APIs someone thought about, documented behavior, accessibility taken seriously, and a plan for keeping mobile and web from drifting apart. You would build this with other devs and our lead product designer. If you have done it before and have opinions about where shared component libraries go wrong, we want to hear them. What we are looking for We care about what you can do and what gets you excited. You Will Probably Be a Fit If You have shipped React Native apps to both the App Store and Google Play, and been through what goes wrong along the way: rejections, expired certificates, a rollout you had to halt, an SDK deprecation with a deadline attachedYou know Expo well enough to argue about it in both directionsYou are strong in TypeScript and comfortable owning a codebase rather than only adding to oneYou have built or maintained a component library and care about how a component is used, not only how it looks with a focus on devXYou can work with a designer without needing every state handed to you as a specYou write tests because you want software to keep working, not because you need to tick a boxYou can write down how a system works so someone else can understand itYou are direct about problems and comfortable disagreeing in a technical discussion Swift or Kotlin experience is useful for the days when the native side is the only way through, though most of the job sits above it. Experience with accommodation, property management or travel systems is a bonus, not a requirement. Tools We use GitHub and Linear. We embrace LLMs but make it clear the responsibility for code still lies with you. LLMs are a tool that may help you but ultimately you need to understand each line and why it’s there. We encourage code reviews, pair coding, the usage of LLMs and are open to any new tools that may help you in the pursuit of excellence in code delivery but nothing is mandated. How we make the hiring decision No whiteboard puzzles and no take home test. Bring us code you have written and are proud of, and walk us through it. It can be open source, a hobby project, something from past work you are allowed to share, anything real that you can talk about. A bonus if the code is somewhat related in stack or purpose to what we do. We want to see how you think about the code you write and the decisions behind it. We will ask questions, so treat it as teaching us about something you already know inside out. Expect about two calls, with a third if we need it. The first is with the CTO. The second is with an engineering lead. Somewhere along the way we will show you a rough map of our current architecture so we can talk honestly about what we have now and where we want to take it. The conversation goes both ways. We take the probation period seriously. There are two check-ins during it, with an honest read from both sides on how it is actually going, and at the end we make the call together.