Perth Software Development Procurement Guide for SMEs

Buying custom software is one of the riskiest purchases a small or mid-sized business makes — large dollar amounts, an intangible product, and a vendor relationship that often runs for years. In the enquiries that reach us, it is usually bought on a couple of conversations, a quote that feels reasonable, and a handshake. That is how projects end up late, over budget, or owned by a vendor you cannot leave.

This is the process we wish every client brought to the table. The numbers and weightings below are our rules of thumb, not industry standards — we have marked them as such throughout, so you can argue with them rather than inherit them. Where something is set by law or by government rule, it is linked to the source.

It works whether you are a private SME, a not-for-profit, or a WA Government agency buying under a panel arrangement. Use the templates freely.

Why software procurement trips up SMEs

Three things make software different from buying, say, a fleet vehicle or an accounting service:

1. You can't touch it before you buy it. You are purchasing a promise. Good scoping is how you make that promise concrete.
2. The cheapest quote is often the most expensive. A low number usually signals a misunderstood scope, and the gap reappears as change requests once you are committed. WA's own procurement guidance puts it plainly: achieving value for money "is much more than choosing the lowest price for a good or service".
3. Lock-in is real. Without the right contract terms, you can end up unable to move your own software to another vendor. That is a procurement failure, not a technical one.

This is not hypothetical, and the best evidence is local. In 2025 the WA Auditor General reviewed ten major State Government IT projects and found eight were over their original cost estimate and eight would be delivered late, with delays running from four months to six and a half years.

Those are government projects with governance an SME does not have. The failure modes are the same ones this guide is about: estimates made before the requirements were understood, and scope that moved after the money was committed.

The fix for all three is process. Here is the one we recommend.

Step 1 — Get internally ready before you go to market

The most expensive mistake is going to vendors with a vague idea. You will pay for that vagueness either in discovery fees or in a padded quote. Before you contact anyone, write down:

• The problem, in business terms. Not "we need an app" — "our field teams re-key the same data into three systems, and we lose two days a week to it."
• The must-haves vs nice-to-haves. A prioritised list. If you can't rank it, the vendor will rank it for you.
• Who the users are and roughly how many, by type.
• What it has to integrate with (accounting, CRM, ERP, anything else).
• Your budget band and timeline. Yes, share the budget. Withholding it just wastes everyone's first meeting. (Our cost guide gives you realistic bands to work with.)
• Your decision-makers and sign-off process.

The Auditor General's diagnosis of why those ten projects blew out is the argument for this step, in one sentence: entities "can easily underestimate project costs and timeframes in the absence of robust planning and a good understanding of their business and system needs, solution options and pricing."

If that document is hard to write, that is useful information: you may not be ready to buy custom software yet, and a short paid discovery engagement is a cheaper way to get ready than a full build.

Step 2 — Decide build vs buy vs hybrid

Custom software is the right answer less often than software vendors like to admit. Run this test honestly:

• Buy off-the-shelf if a mature SaaS product does most of what you need and your process can flex to fit it. Our rule of thumb: about 80% coverage, and under roughly ten users, off-the-shelf usually wins. Those figures come from the projects we have quoted, not from research, so treat them as a starting point for your own maths.
• Build custom if the software is your competitive advantage, if off-the-shelf tools actively cost you money (manual workarounds, double entry, licensing at scale), or if no product fits your model. A custom platform earns its cost here.
• Hybrid — the most common real answer — is custom software that integrates the off-the-shelf tools you already pay for, so you keep your accounting package and CRM but stop re-keying between them. This is where systems integration work lives.

Document which one you chose and why. That rationale protects the decision when someone questions it later.

Step 3 — Write a clear RFQ

A Request for Quote does not need to be a formal tender document. In our experience a focused two-page brief gets better and more comparable quotes than a vague email. Use this template:

REQUEST FOR QUOTE — [Project name]
[Your organisation], [date]

1. ABOUT US
   - What we do, size, location.
   - Who to contact and how.

2. THE PROBLEM
   - The business problem in plain language.
   - What it currently costs us (time, money, risk).

3. SCOPE
   - Must-have capabilities (prioritised list).
   - Nice-to-have capabilities.
   - Out of scope (be explicit).

4. USERS & INTEGRATIONS
   - User types and approximate numbers.
   - Systems it must integrate with.
   - Offline / mobile / compliance requirements.

5. CONSTRAINTS
   - Budget band.
   - Target timeline / hard deadlines.
   - Any technology or hosting requirements.

6. WHAT WE WANT FROM YOU
   - Fixed-price proposal (or scoping-phase proposal).
   - Approach and timeline.
   - Relevant experience / case studies.
   - Team who will do the work.
   - Ownership, IP, and exit terms.
   - References we can call.

7. HOW WE'LL DECIDE
   - Evaluation criteria and weighting.
   - Key dates: questions due, responses due, decision.

Send the same brief to every vendor. Identical inputs are the only way to get comparable outputs.

Step 4 — Read the capability statement critically

A good vendor will respond with (or already have) a capability statement — a short document covering who they are, what they have delivered, their certifications and panel memberships, and their team. When you read one, look past the marketing for:

• Relevant, named work in your sector or with similar complexity — not a logo wall.
• Continuity: do they keep clients for years, or churn through one-off builds? Long relationships signal software that actually works.
• Credentials that matter to you: for government work, panel membership (e.g. WA Government CUAICTS2021) and security posture; for regulated data, relevant compliance experience.
• Who actually does the work. Will the people in the pitch be the people writing your code, or is it a sales team in front of an offshore queue?

Step 5 — Score vendors with a matrix, not a gut feel

Once quotes are in, score them against weighted criteria. This removes "I liked them" from a six-figure decision. The weights below are ours, and they are arbitrary in the sense that any sensible set would do — what matters is agreeing them before you read the quotes, not after. Adjust them to your priorities:

Score each criterion out of 10, multiply by the weight, and sum. The highest weighted total wins — which is frequently not the cheapest quote. Note that total cost includes ongoing maintenance, not just the build: a cheap build with an expensive, lock-in support contract can cost more over three years than a higher build price with transparent maintenance tiers.

Step 6 — Get the contract terms right

The technical work matters less than these clauses, because these are what protect you when something goes wrong:

• IP ownership. This is the clause most worth reading twice, because the default position is not the one most buyers assume. Under the Copyright Act 1968, copyright in work created by an independent contractor generally stays with the contractor unless it is assigned to you in writing. Paying for software does not by itself transfer ownership of it (LegalVision explains the position and the exceptions). So the contract needs an express assignment. Watch for "licensed to you" language, which keeps ownership with the vendor by design.
• Source code access. You should have the code in your own repository throughout, not just at the end.
• Exit and handover. Define what happens if you part ways: documentation, access, and a reasonable handover obligation. A confident vendor has no problem making it easy to leave — which is precisely why their clients stay.
• Acceptance criteria. How is "done" defined and signed off per milestone?
• Change process. How are scope changes priced and approved? A clear process beats either rigid fixed-price arguments or open-ended billing.
• Warranty and support. What is covered after launch, for how long, and at what cost?

The WA Government path: CUAICTS2021

If you are a WA Government agency or local council, you can engage an approved supplier under the Common Use Arrangement CUAICTS2021 for in-scope ICT work without running a full open tender. Nano Solutions is an approved supplier (Contractor #225).

What a CUA does not do is remove procurement. It removes the open tender. Quote requirements, evaluation and record-keeping still apply, and they are set by the Western Australian Procurement Rules rather than by us, so check the current thresholds there rather than taking a vendor's word for them. The Department of Finance also publishes a guideline on purchasing from a CUA or your agency's panel, and the CUA list itself shows which arrangements are mandatory in the metropolitan area.

Our process page sets out how a panel engagement runs end to end.

Procurement red flags

• A quote dramatically below the others (misunderstood scope).
• Reluctance to put IP ownership and exit terms in writing.
• A pitch team you will never see again after signing.
• No paid scoping step — just a confident fixed price for a vague brief.
• Pressure to skip references.
• "We can start Monday" before they understand the problem.

Frequently asked questions

Do we really need an RFQ for a small project? Our own line is around $30,000, which is a judgement call rather than a rule — above it, even a two-page brief pays for itself in comparable quotes and in forcing you to clarify your own thinking. Below it, a clear written brief is still worth the hour. If you are a public authority, the threshold that actually binds you is in the Western Australian Procurement Rules, not in this paragraph.

Should we tell vendors our budget? Yes. A budget band lets vendors propose the right-sized solution instead of guessing. Withholding it usually produces either over-scoped or under-scoped proposals.

How many vendors should we approach? Three, in our experience: one gives you no comparison, six creates noise and slows everyone down. Public authorities should work from the Western Australian Procurement Rules instead, which set the requirement by value. WA opportunities are advertised on Tenders WA.

What if we don't know enough to write a scope? Pay for a short discovery or scoping engagement. It is far cheaper than committing to a full build on a guess, and you keep the resulting document regardless of who you build with.

How do we avoid vendor lock-in? Own your IP and source code, keep the code in your own repository, and put handover obligations in the contract from day one.

In summary

Software procurement done well is mostly preparation: scope clearly, decide build-vs-buy honestly, brief every vendor identically, score on weighted criteria rather than gut feel, and get IP and exit terms in writing. Do those five things and you remove most of the risk before a single line of code is written.

The templates above are free to copy and we would rather you ran a good process with someone else than a bad one with us. If a step is unclear, tell us and we will fix the guide.

Photo credits. All images used under the Unsplash License — free for commercial use, attribution appreciated:

• Reviewing quotes at a meeting table — Olena Kholina
• Scoping on a whiteboard — Paymo
• Reading a capability statement — Van Tay Media
• Signing the contract — Vitaly Gariev

Sources

• Western Australian Procurement Rules — Department of Treasury and Finance. The authority on thresholds, quote requirements and evaluation for public authorities.
• Purchase from a CUA or my agency's panel arrangements — WA Government procurement guideline.
• Common Use Arrangements — the current CUA list, including which are mandatory in the Perth metropolitan area.
• Tenders WA — where WA Government opportunities are advertised.
• 2025 Transparency Report — Major IT Projects — Office of the Auditor General for Western Australia, Report 21: 2024-25. The source for every figure in the chart above.
• Achieve Value for Money Guideline — WA Department of Treasury and Finance.
• Why Your IT Project May Be Riskier Than You Think — Flyvbjerg and Budzier, 1,471 projects, average cost overrun 27%. An international benchmark with a published sample, unlike the Standish CHAOS figures often quoted for this.
• Copyright Act 1968 — the statute behind the IP position above.
• Does my business own the software it is having developed? — LegalVision, on why payment alone does not transfer copyright.