A $64 Million Bus App and the Design Problem Hiding Inside It
Australia just spent $64 million on a bus ticketing app that still doesn't fully work.
The parliamentary inquiry called it "clearly not ready for launch." They launched it anyway.
Day one: QR codes didn't scan. Cards failed. Validators broke. The app crashed. The Transport Minister got censured.
Sound familiar? A few months earlier, the Bureau of Meteorology spent $96.5 million on a weather website so bad they had to bring the old one back. It's the same pattern playing out in Australia's age verification law and its AI policy.
The pattern nobody's naming
These aren't isolated incidents. They're symptoms of the same structural problem: large organisations building technology without anyone in the room who's accountable for how real people will actually use it.
The technology to build these things exists. It's not the hard part. The hard part is making sure someone in the room has the authority to say "this isn't ready for real people yet." And in both cases, nobody did.
Why this keeps happening
There's a specific failure mode in government and enterprise software projects. The decision-makers who approve the budget are different from the people who design the product, who are different from the people who build it, who are different from the people who test it, who are different from the people who decide when to ship it.
Each group optimises for their own constraints. The budget holders optimise for timeline and political optics. The builders optimise for technical requirements. The project managers optimise for milestone completion. Nobody optimises for the person standing at a bus stop in the rain trying to tap their phone on a reader that doesn't respond.
This isn't a tech problem. It's a design problem disguised as a tech problem. And it's often the result of hiring for the wrong thing.
What a design-led process looks like
If you don't have someone obsessed with how people actually use the thing, you're not building a product. You're building a press release.
A design-led process for a project like this would include three things that were clearly missing.
First, real-world testing before launch. Not lab testing. Not QA environments. Actual people, at actual bus stops, in actual weather conditions, trying to catch actual buses. The gap between "works in testing" and "works in the wild" is where these projects fail.
Second, a red team whose only job is to break the experience before the public does. Every major public rollout should have people actively trying to find the failure points, not to be adversarial, but to be realistic. If your QR code reader doesn't work when the sun is behind the user, that's a failure point. If your app crashes when 10,000 people open it simultaneously at 8am, that's a failure point. These are predictable problems.
Third, someone with the authority to delay launch. The most expensive word in product development is "ship it anyway." When the people closest to the product know it's not ready but don't have the organisational power to stop the launch, the result is predictable.
The cost of not testing
The cost of not testing is always higher than the cost of testing. Always.
A two-month delay to fix critical issues would have been invisible in a project timeline that already spanned years. Instead, the public got a broken product, the government got a parliamentary inquiry, and the taxpayers got a $64 million lesson in what happens when you skip the part where someone actually tries to use the thing.
The technology was never the problem. The problem was treating user experience as something that could be bolted on at the end rather than built in from the start.
---
