# Choosing the Right Software Development Company in Perth

URL: https://nanosolutions.io/choosing-the-right-software-development-company-in-perth
Date: 1725235200
Updated: 1792454400
Description: A practical guide to choosing the right software development company in Perth, covering experience, tech stack, scalability, and local expertise.

---


<div class="post-tldr">
  <p class="post-tldr__label">The short version</p>
  <ul>
    <li>Three mistakes named: hiring on technical skill alone and ignoring cultural fit, not checking what post-launch support actually covers, and choosing on price, where the cheapest quote often becomes the most expensive job.</li>
    <li>The evaluation criteria are a portfolio spanning mobile, web and integration work, a stack that can scale, and case studies rather than testimonials, because a case study shows how a firm handles problems.</li>
    <li>Expect four phases and ask which one you are in: discovery, design and planning, build and test, then launch with ongoing support.</li>
    <li>This is general advice rather than a procedure. For a template, a scoring matrix and price bands, the [procurement guide](/perth-software-development-procurement-guide) is the practical version.</li>
  </ul>
</div>

Most software projects that go wrong were not sabotaged. They were bought badly, by people who had no way to tell a good supplier from a confident one.

The evaluation below is what we would use ourselves, written as though we were not the supplier. It is deliberately unexciting: the signals that predict a working project are not the ones that win a pitch.

## What the company is actually being hired to do

A software development company builds and maintains the systems your business runs on. That covers a wide range: a customer portal, a mobile app for field staff, an integration between two systems that will not talk to each other, or a replacement for a spreadsheet that has quietly become critical.

The important question is not "what can you build". It is "what will you still be maintaining in five years". A firm that only builds and disappears is a different supplier from one that operates what it builds, and the difference shows up about eighteen months in.

## What to check, in order

**A portfolio you can open.** Live products and sites, with the client's name where permitted. Screenshots prove nothing. Ask to speak to one reference.

**A stack with a future.** Current frameworks with published support windows, not a bespoke pile only the original developer understands. We build on [Laravel](/services/software-development/laravel-development-perth), Vue and standard cloud infrastructure, mostly because those decisions keep the application maintainable by other people.

**Case studies, not testimonials.** A testimonial says the client was happy. A case study says what the problem was, what was built, and what changed. Ask what went wrong on the project, too. The answer tells you more than the successes.

**A named team.** Who is doing the work, and for how much of the week. Subcontracting is normal; being told about it is rarer than it should be.

**How changes are priced.** A rate for change requests is a sign of a plan. No answer is a sign of a problem.

## Three mistakes that cost the most

**Hiring on technical skill alone.** You will spend months with this team and disagree with them at least once. Ask how they handled a missed deadline and watch whether the answer is specific.

**Assuming support is included.** "Ongoing support" can mean a phone number, or it can mean a retainer with response times and a maintenance budget. Get it in writing, with a cost.

**Choosing the cheapest quote.** A quote is a scope, not a price for the same job. The cheapest proposal is usually the one that understood the least, and the gap returns as variations.

## What the process should look like

Four phases, and you should be able to say which one you are in at any time.

1. **Discovery.** Requirements, constraints, and the thing you can remove from scope. A short, paid discovery is a better use of money than a free proposal nobody can afford to be honest in.
2. **Design and planning.** Architecture, data model, milestones. If this phase produces only a document and no decisions, it has not happened.
3. **Build and test.** Working software every week or two. If you first see the product a month before launch, the project is already behind.
4. **Launch and support.** Handover, monitoring, a maintenance agreement, and a plan for the year after.

We run projects this way, and the shape is written up on our [process page](/process).

## Custom or off-the-shelf

Custom software is worth it when the way you work is the reason customers choose you, and the process is stable enough to encode. Off-the-shelf is the better answer when the process is standard and a decent product already exists.

The test: if your team has built a spreadsheet around a product's limitations, the product is not fitting. If the product does the job and nobody complains, custom is an expensive way to feel productive.

## Questions worth asking

- Who will be on the project, and have they done this kind of work before?
- What happens if we need to change scope in month three?
- What does support cost in year two, and what does it include?
- Who owns the code, and where is it hosted?
- Can we see the last project you launched that is still running?

If the answers are vague, that is the answer.

## Working with us

We are a Perth team that builds and then operates what we build. If you are comparing suppliers, we are happy to be one of them, and we will tell you if the project looks better suited to an off-the-shelf product. [Get in touch](/contact).