Written by the EasyDone team. Last checked 10 October 2026.
For most Perth trade businesses, shaping a platform beats building from scratch. Most of any process (enquiry, quote, booking, crew, job record, invoice, chase) already exists in good software, so pay to build only the few steps that are truly yours. A brand new custom app only makes sense when your core process is unlike anyone else's and you're ready to own its upkeep for the next ten years.
What's really going on?
Take a made up example: Clarke Lifting & Rigging in Welshpool. The owner, Neil Clarke, and a local developer have mapped his process on three metres of butcher's paper: enquiry, lift plan, crane and rigger allocation, a site docket signed by the supervisor, and a hire invoice at the end of the month, per site, with a different approval limit for every builder. On Monday the developer will quote a custom app built around that paper, and he suspects it'll have a lot of zeros on it. The question to ask first isn't "how much?". It's "how much of this paper actually needs building from scratch?"
The business runs six cranes, a pool of riggers and dogmen, two yard hands and an office of three. The work is a mix of construction lifts, plant shutdowns out at Kwinana and the odd air-conditioning unit onto a roof in Subiaco.
For years they've run on spreadsheets, a whiteboard and a booking app that knows nothing about cranes. Every Monday morning is a scramble of who's going where, and the end of every month is a hunt for signed dockets.
Neil's instinct is that his business is different, so it needs different software. He's half right. Some of it is genuinely different. Most of it, if we're honest, is the same as every other trade business: an enquiry, a quote, a booking, a crew, a job record, an invoice, a chase.
The trick is working out which half is which before anyone writes a line of code.
Which problems actually deserve custom software?
The ones that are repeatable, costly and owned by someone. A messy process needs tidying first. Software just makes a messy process faster.
Take one of Neil's sore points: different approval limits for different builders. On the butcher's paper it looks like it needs a custom engine. Ask a few questions and it turns out to be three rules: one builder's site manager can approve up to a set amount, another wants everything signed off by head office, and emergency call-outs go ahead and get approved after. That's a rule, not a new app.
Here's a quick test for every box on the paper:
- How often does it happen? Every job, or twice a year?
- What goes wrong when it fails? A late invoice, a crane at the wrong site, an unpaid docket?
- Who owns it now? If nobody does, software won't fix it.
- What's today's workaround? Write it down, warts and all.
Business.gov.au says to choose digital tools around your business goals and to bring your staff into the change.1 Do that literally. Get the person who actually chases the dockets to help write the brief. Her list of exceptions will be more useful than any list of nice screens.
The three routes, side by side
| Route | Where it fits | The question to ask before you buy |
|---|---|---|
| An existing product, set up for you | Most of your work follows the usual path: enquiry, quote, job, invoice | Can its settings, permissions and templates cover the gap? |
| A platform with changes built for you | A good core, plus a handful of things specific to your trade | Who builds the changes, who maintains them, and who supports them? |
| A brand-new custom app | Your core process is genuinely unlike anyone else's | Who pays for, owns and looks after the whole thing for the next ten years? |
None of these is automatically cheaper or faster. A platform with too many bolt-ons can turn into a mess. A small, tight custom app can be easy to live with. It depends on what's in the proposal.
But here's what most people miss. With a fully custom build, you're paying someone to rebuild the boring bits too: customers, quotes, scheduling, invoicing, reminders, permissions, a phone app, backups. That's a lot of zeros for things that already exist and already work.
What should you ask a Perth developer?
Who'll understand the work, who'll build it, and who answers the phone when it breaks at 6 am on a shutdown morning.
A Perth office is handy for workshops on the floor with butcher's paper. It doesn't tell you where the developers are, where your data lives, or who's on call. Ask for names, hours in Perth time, the escalation path and whether any of it is subcontracted.
WA's digital industries information hub is a decent starting point for understanding the local tech scene.2 It isn't an endorsement of anyone. And the Small Business Development Corporation offers free, confidential business advice3 if you want a second opinion on the business case before you sign.
Then test them. Give each developer one scrubbed job with a nasty exception: say, a lift that gets rescheduled because of wind, with a new site supervisor signing the docket. See how they handle it without a slide deck.
What needs to be in the contract?
Outcomes you can check. For example: the yard can see which crane is where tomorrow; a supervisor can sign a docket on a phone; the office can see who approved what and when.
Then how changes work. How are new requests priced, who can approve them, and do they move the delivery date? A written change log beats a handshake promise to be "flexible".
And the one that catches people out: who owns the code. IP Australia explains that intellectual property created by a contractor generally belongs to the contractor unless your contract says otherwise.4 Paying the invoice doesn't automatically make it yours. Get advice, and get it in writing.
Ask for documentation, a usable export of your data, and a handover test. Owning code nobody else can run isn't much of an asset.
What does it cost to keep it running?
This is the bit that turns a good idea into a millstone. After launch, someone has to look after hosting, backups, restoring from backup, security updates, user access, integration changes and things going wrong.
The Australian Cyber Security Centre treats cloud security as a shared responsibility between the provider and the customer.5 Even if someone else hosts it, you still have to manage who has access.
Make a list of every one of those jobs, with a name against each. Then ask the uncomfortable question: what happens if the developer gets a job in Melbourne, or retires to Dunsborough? Could someone else pick it up from the documentation?
The middle route, done properly
The middle route is the one we chose for EasyDone, so we're not neutral here. This is how it works in practice.
EasyDone already does the boring bits that would eat most of a custom budget: enquiries, quotes, customers with their sites, scheduling, the phone app with Today and On my way, timers against the job, checklists, projects with scopes and progress claims, stock, purchase orders and invoicing with overdue reminders.6 Your business runs on its own server in Sydney, managed for you.7
A signed docket on a phone? That's a required checklist step with the supervisor's sign-off, and the visit can't close without it.6 Hire invoicing per site at month end? That's invoicing from the finished jobs under each site.6
Then the genuinely different bits get built for your business. In EasyDone that's called Workshop. You ask for the change in plain words, it gets planned, built and tested, and you review it before it's yours.8 For Neil, that might be a lift-plan record on every crane job, or a wind-hold status that moves the booking and tells the site supervisor why.
Our one honest limit: Workshop is ongoing development, not a vending machine. Not every request gets accepted as asked, and some get a better idea back. But you're not paying to rebuild invoicing to get there.
And the admin gets done for you. The office can ask the Assistant: "Move the Kwinana shutdown lift to Friday, book the 60-tonne crane and Erin, and let the site supervisor know." It finds the job and the people, asks for anything missing, and waits for an OK before anything goes to the customer.9
What's actually worth building?
Usually a lot less than the quote assumes. Take the butcher's paper and a highlighter, and mark every box that already exists in a normal job system. For Clarke Lifting, enquiry, quote, booking, crew, job record, invoice and chase all go yellow, which is most of the paper.
What's left is three boxes: the lift plan, the wind hold and the per-builder approval rules. That's the bit worth building. That's the bit that's actually Clarke Lifting.
So where do you start?
Grab your own roll of butcher's paper. Draw your process from the first phone call to the money in the bank. Then get the highlighter out and mark everything that every trade business does. What's left is your real brief.
Our guide to what custom software costs in Perth will help you price the rest. And if you want to see how much of your paper already exists, book an EasyDone demo and bring the paper. Seriously. We'll go box by box.
