How to choose an app developer: what to check before you sign

Choosing an app developer comes down to evidence you can check before you sign: what they charge, who will actually write the code, what they have built that you can open and use, and whether you get a written scope and a fixed price before the build starts. Then ask who owns the code, the designs and the accounts (the answer should be you), how often you will see working software, and what happens after launch. In Melbourne, as anywhere, the search results are crowded with directories and "top developer" lists. Use them to find names, then shortlist on the checks below. This guide sets out what to check, the questions to ask on the first call, how fixed-price and hourly billing compare, the red flags, and how we answer each question ourselves.

Six checks separate the developers worth a first call from the rest. None of them needs technical knowledge.

1. Prices you can see. A developer who publishes prices, or at least a range, lets you check the budget before anyone's time is spent. If nothing is published, ask for a range on the first call. A range should be easy to give; a detailed price should not be, until the scope is written.
2. A named person who writes the code. Ask who builds the app, and whether any of it is passed to subcontractors or junior staff. You want to meet that person before you sign, not after.
3. Work you can open. A live product, an app store listing or a web app you can sign in to tells you more than a page of screenshots. Ask what the developer's role was: did they design it, build all of it, or build part of it?
4. A written scope before the build. The scope names the workflows, the kinds of user, the integrations and what is deliberately left out. A price without a scope is a guess.
5. Ownership in writing. The code, the designs and the accounts the app runs on should belong to you. More on this below.
6. A plan for after launch. Ask about the warranty, maintenance, the notice period and the hourly rate for changes before you need any of them.

Lists of the best app developers in Melbourne rank well in search, and they are a reasonable place to find names. Treat them as a starting point rather than a verdict. Check whether a list explains how firms were ranked and whether any place on it was paid for, then put each name through the six checks above. A review on a directory is worth more when you can see the project it describes.

A first call is usually free. Use it to ask questions whose answers you can compare across firms, and write the answers down.

• Who will build the app, and will I talk to that person during the project?
• What do you need from me to give a price range, and how soon will I get it?
• How do you turn the range into a fixed price? Is there a paid discovery step, and what does it produce?
• How often will I see working software: every week, every two weeks, or only at the end?
• What happens when I ask for something that is not in the scope?
• Which accounts will be in my name, and from when?
• Do you build a separate native app for each platform, or one codebase for iOS and Android, and why?
• What does the warranty cover, and how does it sit alongside the consumer guarantees under the Australian Consumer Law?
• What does looking after the app cost each month after launch, and can I stop?
• What would you leave out of the first version?

The last question is the most revealing. A developer who suggests cutting scope is thinking about your budget and your launch date, not only about the size of the job.

There are two common ways to pay for a build, and they put the risk in different places.

Hourly, or time and materials. You pay for the hours worked. It suits work that cannot be defined in advance, such as an investigation, or small changes to an app that already exists. The risk sits with you: if the work takes longer, the bill grows. For context on day rates, the recruiter Hays' IT Contractor Rates Guide FY24/25 lists contract mobile app developers in Victoria at $800 to $1,100 a day, excluding superannuation, with rates correct as at June 2024. If a quote is in days, check how many days it assumes and what happens when they run out.

Fixed price on a written scope. You pay an agreed amount for an agreed scope. The developer carries the risk of the work taking longer, which is why a fixed price needs a written scope first: the scope defines what the price buys. Changes are priced in writing before they are built, so the price only moves when you decide to change what is being built.

For a defined app with a budget behind it, the fixed price is usually the safer choice, as long as the scope is specific. A fixed price on a vague scope only moves the argument to the end of the project.

With us, a web app or an MVP costs $15,000 to $40,000 ex GST and a mobile app $20,000 to $50,000, each fixed in a written scope before the build starts. How much it costs to build an app in Australia explains what moves a project within those ranges.

You should, and the agreement should say so. Ownership has three parts, and it is worth asking about each one.

• The code and the designs. Once the project is paid for, the agreement should give them to you. The open-source libraries an app uses stay under their own licences, which is normal; what matters is that the code written for you is yours.
• The accounts. Hosting, the domain name, the source code repository and the Apple and Google developer accounts should be set up in your business's name from the start. An app published under a developer's own store account is hard to move later.
• The knowledge. Documentation and a hand-over session mean another developer could pick the app up if you ever need one to.

Ask for all three in writing before you sign, not after launch.

• A firm price for a large build before anyone has asked about your workflows, the kinds of user or the systems the app must connect to.
• No written scope, or a scope that lists features without saying what is left out.
• Accounts, the domain or the app store listing in the developer's name.
• Nobody can tell you who will write the code.
• Most or all of the price paid up front, with no milestones.
• No working software to look at until the end of the project.
• Promises of downloads, rankings or revenue. A developer controls the quality of the build, not the market.
• Maintenance terms that are vague, or a long minimum term you only learn about after launch.

One red flag is not always a reason to walk away: ask about it and judge the answer. Two or three together usually are.

It is only fair to hold ourselves to the same checks. These answers are on our pricing and process pages, and in every services agreement.

Two honest limits. ELORA DIGITAL is new, so there are no client case studies yet; they will appear on our work page as projects launch and each client agrees in writing. And we are not the right developer for everything: we do not take projects under $4,000, and for heavy native graphics or specialised media processing we say so in discovery and point you to someone better suited. Our mobile apps are built in React Native, one codebase for iOS and Android, and submitted to both stores under accounts in your name.

Write down the one thing the app must do, who will use it and which systems it has to talk to. Take that same brief to every developer on your shortlist, so the answers can be compared. If your budget is small or the job is a one-off, a freelancer may suit you better than a studio, and that guide explains when.

If we are on your list, tell us about your project. ELORA DIGITAL is a small app development studio in Melbourne, based in Box Hill North, so the person who replies is a founder. You will get an estimate range within one business day, and if another kind of developer would suit you better, we will say so.