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. Yet most SMEs approach it with no procurement process at all: 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 can't leave.

This guide is the procurement process we wish every client brought to the table. 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 — they are here to be copied.

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. The gap reappears as change requests once you are committed.
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.

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.

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 80%+ of what you need and your process can flex to fit it. Below ~10 users, this is almost always the cheaper path.
• 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 40-page tender document. For most SME projects, a focused two-page brief gets you better, 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?

Lead magnet: We keep a procurement-ready capability statement for Nano Solutions on hand for exactly this purpose — useful as a template for what good looks like, and as documentation if you are justifying a panel engagement. Request it via the contact form.

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. Adjust the weights 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. You should own the source code and all IP outright on payment. Watch for "licensed to you" language that keeps ownership with the vendor.
• 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 directly 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). For agencies this means a faster path, pre-arranged rates, and lower procurement risk. 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? For anything above ~$30,000, yes — even a two-page brief. It gets you comparable quotes and forces you to clarify your own thinking. Below that, a clear written brief is still worth the hour it takes.

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 is the sweet spot. One gives you no comparison; six creates noise and slows everyone down. Shortlist to three serious candidates and brief them identically.

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.

If you want a steer on any of it — or a capability statement to use as your benchmark — get in touch. We are happy to help you run a good process, even on projects we don't end up building.