The Road to Launching GetFired.au
A behind-the-scenes look at the late nights, the pivots, and the thinking behind our newest venture.
It started with a spreadsheet. I wanted to model my path to financial independence – properly, with Australian tax, super, the lot – and every tool I found was either US-centric, too basic, or locked behind a $3,000 financial adviser engagement.
So I built the thing.
That was six months ago. GetFired.au is now live, with paying users, a subscription billing system, branded email infrastructure, and a roadmap I'm genuinely excited about. If you'd told me in October that I'd be here by April, I wouldn't have believed you.
The name
GetFired is a play on FIRE – Financial Independence, Retire Early. Reframed as something you actively pursue. The .au is deliberate. This is built for Australians, with Australian rules, from the ground up.
Six months, not five years
I'll be honest about this: if I had tried to build GetFired from scratch by myself, writing every line, I'd estimate I'd reach this point after about five years of solo dev.
It took six months. The difference is AI.
But I want to be precise about what that means, because the discourse around "vibe coding" misses something important. There's a new wave of products being shipped by people who've never written code before, prompting their way to a deployed app. Some of those products are impressive. Some of them will fall over the first time they hit a real edge case.
I've been writing code since I was thirteen – learnt C about twenty-five years ago, then C++. I'm not vibe coding. I think of myself as a harness engineer: someone who understands the fundamentals deeply enough to direct AI agents effectively, catch their mistakes, and make architectural decisions that a prompt-only builder can't.
The agents are my team. Tireless, fast, available at 2am when the idea won't let me sleep. But they need a driver who knows where they're going.
The thing that vibe coding can't give you
Beyond the code itself, there's something else I bring to this that two decades of career have drilled into me: enterprise architecture thinking.
I've spent twenty years bridging business and technology – many all-nighters delivering projects and implementations for some of Australia's biggest and most powerful enterprises. When you've operated in those environments, you develop an instinct for the things that don't show up in a demo but absolutely show up in production: data residency, privacy regulation, system hardening, intrusion protection, operational stability.
That thinking has gone directly into the way GetFired is designed.
This isn't a frontend with some logic in JavaScript. The platform uses bank-level encryption – envelope encryption with per-record private keys, encryption in transit and at rest, not just at the storage layer. The backend is written in Go – readable, extensible, endlessly fast, and a natural evolution from my early days writing C and C++. It was a deliberate language choice: I needed something that was easy to write, easy to read, and easy for others to extend as the team grows, while still being performant enough for real-time financial modelling. The financial engine demands decimal-exact calculations, because when you're modelling someone's future, "close enough" isn't.
I've also been deliberate about trade-offs. I'm leveraging managed services to get live faster, then iterating toward bare hyperscaler implementation over time. Every early decision has been a conscious cost-benefit call – focusing on ROI and speed to market now, with a clear path to full infrastructure ownership later. That's not a compromise, it's a strategy. You learn to think that way after twenty years of watching enterprises either over-engineer into paralysis or under-engineer into crisis.
What I can tell you
The FIRE space in Australia is underserved. The tools that exist are either too simple to be useful or too expensive to be accessible. GetFired sits in that gap.
I'm deliberately not going deep on the feature roadmap here – the market is competitive, increasingly so, and the new wave of AI-assisted builders means products can appear fast. What I will say is that the architectural foundations are built to last, and that matters more than shipping features first.
What I've learnt
Ship the core, park the shiny thing. Early on I built a feature that was technically interesting but strategically commodity. Parking it and refocusing on the core product was one of the best decisions I made.
The hard part isn't building – it's deciding what to build. With AI agents, implementation is faster than ever. That makes product judgment the bottleneck, not engineering velocity. Knowing what not to build is the real skill.
Enterprise thinking isn't overhead – it's an edge. In a market where anyone can ship a calculator in a weekend, the products that survive will be the ones built on real foundations. Security, accuracy, and operational maturity aren't features you bolt on later. They're either in the architecture from day one or they're not.
What's next
GetFired is live and growing. I'm iterating fast, listening to users, and building toward something I genuinely wish had existed when I started my own FIRE journey.
If you're interested, give it a try.