App developers in Perth: what to know before paying for an app

Thinking of paying a Perth developer for your own app? The questions owners really ask, answered straight, before you sign anything or hand over a deposit.

7 min read
  • Perth & WA
  • Work software
A pest inspector checks an Ocean Reef termite inspection in EasyDone on his phone beside a service van.

Written by Colin Tross, founder of EasyDone and an audio visual installation business owner. Last checked 10 October 2026.

Should a Perth trade or service business pay a developer to build its own app?

Usually not to run the jobs. Yes, when the app is the product: something your customers will open again and again that nobody else sells. Somewhere in between sits most of what owners actually want, which is "my techs on their phones and my customers kept in the loop". That's already built, and you can be using it next month instead of next financial year.

Below are the questions owners really ask before they sign a developer's proposal, answered straight. We'll use a made-up Joondalup business to keep it real: Coastline Pest & Termite, owner Rhys Tandy, five techs, a lot of annual termite inspections between Ocean Reef and Two Rocks, and one very tired office manager called Bev.

"What am I actually paying for?"

Not an icon on a phone. You're paying for four things, and the quote you get often only prices the first one:

  1. The build. Screens, the database behind them, sign-in, and the connections to anything else you use.
  2. The accounts. An Apple developer account, a Google Play account, hosting, a domain, an email for support.
  3. The upkeep. Apple and Google update their phones every year. Someone has to keep your app working on them.
  4. The support. When Bev rings at 7 am because the app won't sync, who answers?

Perth developer PWD, for one, describes discovery and prototyping as part of how it approaches custom work.1 That's good practice. Just ask what you walk away with at the end of discovery, and whether you can take it to someone else.

"App, web app, or something that already exists?"

Here's the honest shape of it for a business like Rhys's.

RouteMakes sense whenWhat usually bites
Existing job softwareYou need quoting, booking, field work and invoicing done properlyYou'll want a few things changed for the way you work
Custom web appA browser workflow suits your people and their phonesOffline and installing work differently on different phones
Native phone appYou need the phone's camera, alerts or the app stores, and it's core to what you sellThe upkeep, every year, forever

A web app can be "installed" to the home screen, but MDN's own guidance shows support varies by browser and platform, and that installing it is a different thing from working offline.2 An icon on Bev's phone doesn't mean a termite report survives a dead spot in Yanchep.

"Who owns the code and the accounts?"

This one catches people out. IP Australia explains that intellectual property created by a contractor generally belongs to the contractor unless the contract says otherwise.3 So get it in the contract, in plain words.

Then sort the practical side, because legal ownership is useless if you can't actually get in:

  • Apple's organisation enrolment needs a proper legal entity and someone with authority to sign for it.4 Enrol it in the business's name, not the developer's.
  • Google Play has personal and organisation developer accounts with their own verification steps.5 Same rule: the business owns it.
  • Hosting, domain, code repository, payment services: list each one, with an owner and a recovery plan. Not a shared password in a Word doc.

If the developer gets hit by a bus (or just moves to Bali), could another developer pick it up from what you hold? If the answer is "probably not", you don't own it yet.

"How do I test it before I pay the last invoice?"

Write down what should happen, then try to break it. For Coastline, that looks like:

  • A tech opens tomorrow's inspection, adds photos and notes, and the office sees them without a phone call.
  • The office moves the job while the tech's phone is offline. He reconnects. Which version wins, and does he know?
  • A customer with a long name and two sites. A photo that fails to upload. A forgotten password. An apprentice who shouldn't see prices.
  • Every phone your team really carries, not just the developer's shiny one.

A prototype proves people understand the screens. It doesn't prove the thing is ready to hold real customers' details. Don't accept a phone app from a desktop demo.

"What does it cost to keep alive?"

More than the build quote suggests, and forever. Agree up front:

  • What happens when Apple or Google changes something and the app breaks.
  • How urgent faults are handled outside office hours, in Perth time.
  • What small changes cost, and how long they take.
  • What gets tested before every release, and who signs it off.

If the developer won't put a maintenance arrangement in writing, that's your answer.

"What should I ask a Perth developer in the first meeting?"

  • Who exactly will build it, test it and support it after launch? Is the person in this meeting still around in six months?
  • Can you show me something similar you built, and which part was yours?
  • What do I hold at the end: code, accounts, documentation?
  • How do you handle offline, and can I watch it happen on a cheap Android?
  • What's your support response, and who do I ring?

Bring one person from the office and one from the field to the workshop. A room full of managers will miss the detail that slows everyone else down.

"What if what I want is just my techs on their phones?"

Then you don't need an app built. You need one that already exists and can be changed for you. Yeah, we make EasyDone, so we're biased. Here's what Rhys would get out of the box.

His techs open Today on the phone and see their inspections in order, with the access notes, the gate code and the dog's name. On my way sends the customer a text the tech can read before it goes. Time runs against the job, and photos, notes and checklists go straight onto it while the tech's still in the roof space.6

EasyDone phone Today screen with an annual termite inspection in Ocean Reef as the next job and an On my way button
The phone's Today screen, redrawn for the web with Rhys's first inspection: in order, with On my way. Example job.

Customers can check where their callout is up to on a status page, so Bev stops fielding "is he still coming?" calls.6 Quotes, bookings and invoices sit in the same system, so a termite treatment quoted in March becomes the job and then the invoice without anyone retyping it.

The live EasyDone phone schedule for the whole team, showing each tech's first job with time and hours, and a Book button, with callouts
The owner's phone: the whole team's day, and a Book button. Fictional demo records.

And Bev doesn't have to learn every screen. She asks the Assistant: "Who's overdue for their annual termite inspection in Ocean Reef?" or "Book the Clarkson job for Thursday morning with whoever's free." It finds the records and does the work, and anything involving money or a message to a customer waits for her OK.7

The EasyDone Assistant answering Bev's question about overdue termite inspections and booking the Clarkson job for Thursday, with reminder texts waiting for her OK
The Assistant card, redrawn for the web with Bev's two asks: answered and booked; texts to customers wait for her. Example details.

"What if my business does something odd?"

Every good business does. In EasyDone you ask for the change and Workshop plans it, builds it and tests it for your business, then it's yours.8 Our honest limit: not every request gets built exactly as asked. We'll tell you straight when there's a better way, or when it's a job for a proper custom build.

That's still a long way from paying a team to build, host and babysit a whole app from scratch.

"Will AI make building an app nearly free?"

Owners ask this a lot now, and fair enough: AI coding tools are genuinely changing how fast developers work. But the expensive parts of an app were never just the typing. Someone still has to work out what it should do, test it on real phones, keep it secure, keep it running when Apple changes something, and answer the phone when it breaks.

So yes, a build might cost less than it used to. The upkeep, the accounts and the responsibility don't shrink nearly as much. Compare proposals on what's delivered and who's on the hook afterwards, not on which tools the developer uses.

A quick decision check

Answer these honestly before you ring a developer:

QuestionIf yesIf no
Will customers open it every week, for something only you offer?A custom app might be your productYou probably don't need one
Is the main need techs on phones and the office in sync?That's job software, already builtKeep reading
Do you need something genuinely odd that no software does?Ask for it to be built into existing software firstOff-the-shelf will do
Are you ready to pay for upkeep every year, forever?Then a custom build is on the tableThen it isn't

For Coastline, the answers were no, yes, a little, and definitely not.

So, should Rhys build an app?

Not for running Coastline. He gets the phone side, the office side and the admin done for him in software that already works, and he spends the build money on another van.

If one day he wants an app his customers open every week, one that's genuinely his product, that's when he rings a Perth developer, with this list in hand.

If your gap is bigger than a few changes, our Perth custom software guide walks through that road. If it's mostly "techs on phones, office sorted", have a look at EasyDone's modules, check the pricing page, and bring a real job to a demo. We'll run it on a phone in front of you.

Talk to us

See how it fits your business.

Tell us how your business runs today. We'll show you the parts of EasyDone that would help, and be straight about the parts that wouldn't.

Your message goes to our team at hello@easydone.work.

Questions about EasyDone? Ask here, and a person from our team will reply.