Blog

How to hire an AI or React Native developer in Sydney

I am Muhammad Adil. I live in Sydney and I take on AI, React Native and full-stack work myself. People write to me when they have already spoken to an agency, collected three vague proposals, and…


I am Muhammad Adil. I live in Sydney and I take on AI, React Native and full-stack work myself. People write to me when they have already spoken to an agency, collected three vague proposals, and still cannot tell who will sit in the repository. This note is how I would hire me — or someone like me — if I were the client.

Start with the product, not the job title

A lot of briefs say “we need an AI developer” or “we need a React Native developer in Sydney” and stop there. Those titles hide different jobs. One founder wants a thin wrapper around a hosted model. Another wants a fitness product with bookings, memberships and a trainer console. A third has a vibe-coded prototype and needs someone to say whether it is safe to put real users on it.

I ask for the decision you are trying to make in the next eight weeks. If the decision is “should we keep this codebase?”, start with an evaluation. If the decision is “can members book a class on iPhone and Android?”, start with mobile. If the decision is “can the team stop living in spreadsheets?”, start with a dashboard or a small SaaS slice. The hire follows the decision.

I keep my own services in that same split. Mobile work sits under app development. When the codebase already exists — especially AI-generated code — I would rather begin on AI app evaluation than pretend a greenfield build is what you asked for.

Sydney versus remote is a working-hours question

I am based in Sydney. I will meet in person when a workshop actually shortens the project: first scope, a painful integration, or a store-release week. The rest of the week is written updates and a shared board. That mix is how I already work with studios in this city and with clients elsewhere in Australia.

If you insist on a five-person “Sydney team” in the room every Tuesday, I am the wrong hire. If you want one engineer who answers in Australian time, owns the repo, and does not rotate juniors through your Slack, we can talk. I wrote more about who I am and how I work on the about page.

Timezone still matters for App Store reviews, gym-class peaks and anything that pages you at 6am. A contractor in a distant timezone can be excellent. They cannot sit with a trainer at 7am in Marrickville when the check-in flow fails. Say that constraint out loud before you compare day rates.

What I look for in a React Native brief

I want the platforms (iOS, Android, or both), the accounts model, and the two screens that make the product real. For a studio app those screens are usually “book a class” and “pay for a membership”. Everything else can wait a sprint.

I also want to know whether you already have a design system, a backend, or a no-code admin. React Native is a poor place to invent your entire business. It is a good place to ship a client that talks to a boring, well-named API.

Two recent products I shipped in this lane are public as case studies: the Di Lorenzo fitness app and the Feels at Home fitness app. Read those if you want to see class booking, subscriptions and trainer workflows rather than a generic “we do mobile” slide.

If the product is a studio, diary or class-booking app, I wrote a separate note on how I build React Native fitness apps in Sydney.

Ask any candidate — including me — how they handle over-the-air updates, store review, push permission prompts, and the day a payment provider changes a webhook. If the answers are only “we use Expo” or “we use Firebase”, keep asking.

What I look for in an AI brief

AI work goes wrong when the prompt is treated as the product. I want the source of truth (which documents, which database, which staff member is allowed to be wrong), the failure mode you can live with, and who reads the output before a customer sees it.

If you already have a prototype from Cursor, Lovable or a weekend hackathon, do not hire someone to “just add auth and ship”. Hire someone to read the code, list what will break, and tell you the cheapest path to something you can support. That is the evaluation service I already sell. It is cheaper than rebuilding in public.

If you do not have a prototype, I would rather start with one workflow: a weekly summary, a lead qualifier, a support draft. A dashboard that shows the human what the model did is usually more valuable than a chat box on the marketing site.

How I would run the first two weeks

Week one is access, a written risk list, and a thin vertical slice that a real user can click. Week two is the first thing that can fail in production: a payment, a notification, a permission, an export. I would rather find that early than polish empty screens.

I work in the repository you will keep. I do not hide work in a private agency monorepo and “hand over” a zip. You should be able to fire me and keep the app. That sounds blunt. It is the test I use when I hire other people for my own products.

Communication is short written notes, not a 20-page status deck. If something is blocked I say so the same day. If I am the wrong person for a slice — for example a long brand film or a paid-social retainer — I say that too. I do not take that work.

Rates, retainers and the questions that waste a month

Fixed-price whole-product quotes without a written slice are how both sides get unhappy. I will quote a discovery or an evaluation as a fixed piece. I will quote a first mobile slice with a named set of screens. I will not quote “the app” as if the App Store were a PDF.

A monthly retainer makes sense after the first release, when you have real users and a backlog. It does not make sense as a way to avoid deciding what the product is.

Questions that waste a month: “Can you also do our Instagram?”, “Can you staff a dedicated offshore pod?”, “Can you rebrand us?”. Those are leftover agency packets. I build and review software. If that is not what you need, you will have a cleaner search without me in it.

A short checklist before you send the first email

  • What decision must this hire unlock in eight weeks?
  • Who owns the Apple and Google accounts, the domain, and the database?
  • Is the first release a new app, a repair of an existing one, or an evaluation?
  • Do you need someone in Sydney some of the time, or only during Australian hours?
  • What must never be generated by a model without a human in the loop?

If you can answer those, write to me with the answers. I will tell you whether I am free, whether the work is a build or a review, and what the first paid slice should be. If I am not the right person I will say that in the first reply. That is the whole process. There is no sales ladder behind it.