When it comes to complex software projects, decisions are rarely made based on capabilities alone. More often, they are based on perceived risk, with well-known vendors often assumed to be the lower-risk choice.
Choosing a software development partner comes with scrutiny. The decision is often reviewed by a range of teams, including procurement, legal, executives, or risk, if not all four. And if the project runs over, stalls entirely, or lands badly with users, the question is not just “what happened to the project?” It is, “who signed off on this?”
The decision is no longer just about who is best placed to deliver the project. It becomes about which vendor feels easiest to defend if something goes wrong. In many organisations, particularly in government and regulated sectors, recognisability becomes a proxy for lower risk, even when that says very little about how the work will actually be delivered.
But the problem is that brand recognition and delivery are entirely different things.
You may be familiar with the recent scrutiny of the Bureau of Meteorology website rebuild. That project’s cost was reported to be $96.5 million, rather than the previously stated $4.1 million. This cost criticism is on top of reported usability issues. However, that same firm then went on to win another $16 million government contract.
This doesn’t tell us that every large consultancy-led project is flawed to the same degree. But it does show that brand recognition does not guarantee value, usability, or delivery discipline.
The problem with treating brand as a proxy for low risk
Larger firms aren’t necessarily bad at delivery. But the issue is that in many environments, risk gets assessed by clients at the point of selection rather than at execution.
A recognised name can make a decision feel easier to defend. It might reassure a panel of decision makers and satisfy a governance process. But none of that tells you what is actually important: how the work will be delivered, who will be working on your project, how decisions get made once the project is live, or how quickly problems will be resolved.
People are often not shopping based on price or even on skill. They are choosing the option that feels easiest to justify internally. Unfortunately, this often increases delivery risk later.
Procurement rules are tightening
We know that the standards organisations are being held to are tightening. Commonwealth procurement rules put value for money at the centre, alongside efficiency, effectiveness, economy, ethics, transparency and accountability. In regulated environments, APRA’s CPS 230 requires entities to manage operational risk, maintain critical operations through disruption, and manage risk arising from service providers. CPS 234 makes it clear that information security obligations extend to assets managed by third parties too. In other words, risk doesn’t disappear because it has been outsourced to a third party.
So, if lower risk does not simply mean better known, what should software development buyers actually be looking for?
What actually increases delivery risk?
In our experience auditing and working with enterprise legacy systems, we’ve found that delivery risk tends to come from a small set of practical issues.
1. Separation between who sells to you and who works on your project
A red flag when choosing a software development partner is when the team that wins the work is different from the team that does the work.
You meet a senior group at the pitch. They are experienced, credible, commercially polished and reassuring. Then the project starts, and the day-to-day delivery shifts elsewhere. You are moved to a different team, in a different context, with a different level of experience, often in a different geography too.
That handover immediately creates risk.
This is a situation we’ve had to step into more than once. A team thought they were choosing an onshore delivery partner because that’s who they met during the sales process, only to have the work handed off after the contract was signed. What was meant to be a three-month build then stretches to twelve. Communication slows down, accountability disappears, and in some cases, they’re left without a working product or even ownership of the code.
This disconnect creates communication gaps between what was sold and what actually gets built, slows decisions, and weakens accountability. It makes it hard for a client to know who owns what part of a project once complexity starts to surface.
If you are evaluating partners, one of the most useful questions to ask is not how big the firm is, but who specifically will be on the project from week one and whether they are the same people who shaped the proposal.
2. Strategy outputs without delivery ownership
There is still a version of consulting that produces polished PowerPoints without actually resolving what happens next.
The deck looks good. The recommendations sound sensible, and the room nods along. But then someone has to turn that into a live system, work through the technical constraints, integrate it with legacy platforms, satisfy security requirements, manage stakeholders, and carry it through to production.
I’ve seen this play out firsthand. A strategy deck is handed over, the room agrees with the direction, and the immediate response is: “This makes sense, but what do we do next?”
Without a clear path to delivery, that’s often where it stops.
A strategy document can be useful. But it becomes risky when it stands in for delivery. The lower-risk model is not the one that documents intent most elegantly. It is the one that can carry responsibility from discovery through to release.
3. Junior team and rotating resources
Larger firms often sell themselves on their organisational depth. In practice, however, most software projects are delivered by relatively small teams. What matters here is not how many people exist in the entire organisation. It is the team's experience, continuity, and accountability that actually work on the project.
When teams rotate frequently, knowledge degrades, context needs re-explanation, and technical decisions lose their rationale. Delivery slows down because every handover creates yet another opportunity for misunderstanding or rework.
This breaks down quickly once delivery starts. Senior team members stay close to the client and the problem, but the actual work gets pushed down the chain. Each layer adds interpretation. By the time it reaches the people building the system, key context has already been lost, and that’s where errors start to creep in.
You end up paying for senior oversight while much of the work is handled by less experienced staff. That model can look strong from the outside because of the size of the brand, but inside the project, it often means more layers, more drift and less clarity.
4. Scale that doesn’t change delivery
One of the most common reasons buyers cite for leaning toward larger software development providers is scale. But most projects are not delivered by hundreds of people. They are delivered by a small core team.
When timelines slip, the instinct is to add more people to the project. In reality, that can have the opposite effect. More people means more coordination, more communication overhead and more room for misalignment.
What tends to work better is a small, experienced team that understands how to operate together and stays close to the problem from end to end.
The question then isn’t how many people the provider employs, but how much experience the team working on your project has. You’ll want to ensure the delivery model supports continuity, that there are clear escalation paths, and that the team structure can move at the pace that your work requires.
5. Offshoring and communication gaps
The commercial logic makes sense. Lower input costs, broader resourcing and round-the-clock coverage. But in regulated, security focused, stakeholder-dense environments, those savings can be offset quickly by slower feedback loops, more brittle communication, less visibility and more rework.
I’ve seen a consistent pattern with teams that have taken this path. The initial build is delivered, but issues surface as the platform evolves. Deadlines begin to slip, communication becomes harder, and it’s often unclear who owns what. In some cases, teams struggle to access or extend their own codebase, or to get timely responses from the people who built it. And that’s where the costs start to stack up: not in the initial build, but in the effort required to stabilise, extend or replace what’s been delivered.
If something goes wrong on a customer-facing platform, a member portal, or a critical operational workflow, you want short lines of communication. You want to know who is accountable, and you want to be able to speak to the people making decisions and resolve issues immediately.
What reducing delivery risk should look like instead
If you are buying software development services, especially if you operate in a complex, regulated environment, risk should not be assessed solely by recognisability.
Instead, it should mean:
- The team you meet is the team you work with
- Senior people remain accountable through delivery, not just through sales
- Governance is embedded into the way the work is run, not layered on after the fact
- The partner has a track record of taking systems live, not just advising on them
- Ownership is clear when the work gets difficult
- Communication lines are short and direct
- Security, resilience and accessibility are treated as delivery requirements, not compliance theatre
Real delivery risk in software does not come from optics. It comes from predictable delivery, clear accountability, and control over how the work is actually executed.
The questions to ask to find the right partner
If you are the one responsible for making this decision internally, the most useful question has hopefully shifted from “Who is the safest name to put on the procurement paper?” to:
- Who is actually set up to carry delivery risk with us?
- Who owns the work once the pitch is over?
- Who will still be there when edge cases appear?
- Who can move quickly when the system does something unexpected?
- Who can work through governance and technical complexity without creating another layer of it?
Where Airteam fits
Airteam is built on senior, hands-on delivery. The team you meet is the team you work with, remaining involved from discovery to release. We do not run a junior handoff structure. We do not outsource development offshore. Our team is 100% Australia-based and onshore, holding both ISO 9001 and ISO 27001 certifications for quality and security.
If you are weighing up software partners and want a clearer way to assess delivery risk, speak to us. We can walk you through how we structure our team, governance, security and delivery continuity before you commit. Reach out at hello@airteam.com.au or via our contact page.
Related posts
Australia's trusted software development partner
