The 9 Questions Every Aussie Business Asks a Software Developer
From "how much does an app cost?" to "what if I don't know what I need?" — here's what we actually tell clients when they ask.
Every software company has heard the same nine questions roughly four million times. Not because clients are unoriginal — because these are genuinely the things that matter, and most of us in this industry are terrible at answering them in plain English.
So here they are, answered the way we'd answer them over coffee, not in a sales deck.
How much does custom software actually cost in Australia?
Most small business software projects in Australia land somewhere between $20,000 and $100,000+, depending on scope, and mobile apps specifically tend to sit between $15,000 and $150,000+. The honest answer is "it depends on what you're building," but the biggest cost drivers are always the same: how many user types your system needs, how many third-party tools it talks to, and how much custom design work is involved.
If a quote comes back suspiciously low, it's usually missing something — QA, post-launch support, or a realistic amount of design time.
The 9 questions we hear on almost every call
1. "How much will this actually cost?"
Everyone asks this first, and fair enough. The problem is most businesses ask it before they know what "this" is. A rough guide:
| Project type | Typical range (AUD) | Timeframe |
|---|---|---|
| Simple mobile app (single platform, few features) | $15,000–$30,000 | 6–10 weeks |
| Custom mobile app (iOS + Android, backend, integrations) | $25,000–$150,000+ | 3–6 months |
| Business website with custom functionality | $5,000–$25,000 | 4–8 weeks |
| Custom web platform / internal tool | $20,000–$150,000+ | 3–9 months |
Quick win: Ask for a scoped estimate, not a ballpark. A vague number protects the agency, not you.
2. "I don't really know what I need — is that okay?"
Yes, genuinely. This is most clients. A decent software partner will help you translate "our booking process is a mess" into an actual technical brief. If a company can't work with a rough problem statement and instead insists you arrive with a finished spec, that's a sign they're not used to doing discovery properly.
3. "Can you just build what our competitor has?"
You can ask, but the better question is why their thing works — for their business, their margins, their users. Copying a feature set without understanding the business logic behind it is how projects blow their budget in month two.
4. "Why does everyone quote such different prices?"
Because everyone scopes differently. One quote might include three rounds of design revisions and post-launch bug fixing; another might not. Industry estimates suggest scope gaps — not hourly rates — account for the majority of quote variance between Australian dev shops.
Common mistake: Comparing two quotes side by side without checking what's actually included in each. A $40k quote and a $70k quote for "the same app" are rarely the same app.
5. "How long is this going to take?"
Longer than the first estimate, if we're being honest — but a good team builds buffer into the timeline instead of pretending delays won't happen. Here's roughly how a mid-sized build breaks down:
- Discovery & scoping — 1–2 weeks, defining what's actually being built
- Design (UX/UI) — 2–4 weeks, wireframes through to final screens
- Development — 8–12 weeks, usually in sprints with regular check-ins
- Testing & QA — 2–3 weeks, running in parallel with late development
- Launch & handover — 1–2 weeks, deployment plus training/documentation
6. "What happens after launch — do you just disappear?"
A reputable company doesn't. Software isn't a "set and forget" purchase; it needs monitoring, security patches, and small fixes as real users find edge cases you didn't test for. Ask upfront what post-launch support looks like and what it costs — it's often a separate monthly arrangement.
7. "Do you build it, or do I own it?"
You should own it — the code, the IP, all of it — assuming your contract says so. This is worth checking before signing anything, not after.
| Item | Should be true | Red flag |
|---|---|---|
| Code ownership | Transfers to you on final payment | Vendor keeps rights or "licenses" it to you |
| Source access | You get full repository access | You only get a compiled app with no source |
| Documentation | Provided as standard | "We'll explain it if you have questions" |
| Third-party accounts | Set up under your business's name | Set up under the developer's personal account |
8. "Should I hire a freelancer, an agency, or an in-house dev?"
Depends what "done" needs to look like:
- Freelancer — good for a narrow, well-defined task if you already have technical judgement in-house to manage it.
- Small studio/agency — good when you need architecture decisions, design, and QA handled by people who've done it before, and you want one team accountable for the outcome.
- In-house hire — makes sense once software is core to your business long-term, not just a one-off build.
9. "What if the requirements change halfway through?"
They will, at least a little — that's normal, not a failure of planning. What matters is whether your contract has a clear change-request process. Good teams build software in short sprints specifically so shifts in direction cost you a conversation, not a rebuild.
What a good first conversation actually sounds like
Before/after, because this trips people up constantly:
Before: "We want an app like Uber but for our industry, can you give us a quote?"
After: "We need customers to book a service, get matched to the nearest provider, pay in-app, and rate the job afterward. We think we need iOS and Android, and we'll have maybe 500 active users in year one."
The second version gets you an actual number. The first gets you a guess.
Quick reference: what to ask before you commit
| Question to ask a dev company | Why it matters |
|---|---|
| What's included in this quote, specifically? | Prevents scope surprises later |
| Who owns the code and IP after launch? | Protects your business long-term |
| What does post-launch support cost? | Avoids being stranded after go-live |
| How do you handle changing requirements? | Tells you how flexible the process really is |
| Can I speak to a past client? | Best signal of how they actually work |
None of these questions are awkward to ask. Any team worth working with in 2026 has answered them a hundred times already — you're not the first person to wonder if you're being overcharged, and you won't be the last.