My advice to a younger me
In 2012, Scott Weiss wrote The Path to Starting a Startup for Andreessen Horowitz. It’s 2026 now, and I still think about it. His argument was that the best preparation for becoming a founder isn’t grad school or a big company, it’s working at a startup, because the learnings are five to ten times more relevant than anything else you could spend those years doing. He also argued you should do it in Silicon Valley, where the ecosystem of talent, capital and network is densest.
I didn’t read it until later, but when I did, it stuck. The emphasis on learning by doing, on preparation and persistence, on building instincts through exposure to real startup chaos. He was right about almost all of that.
He was wrong about it having to be the Valley. But I’ll get to that.
The long road to getting it right
I’ve been building things since I was ten years old. I ran a web design side project through school that eventually became a hosting company, then pivoted into email security, changing its name three times along the way. It followed me around for over a decade, and it still runs today. I’ll come back to why that matters later, because it’s a cautionary tale, not a success story.
My first real job was at a commercial real estate startup that no longer exists. My second was a peer-to-peer real estate platform (built with the founders of Everyday Hero) that no longer exists. Nobody was ever going to let people sell houses to each other without agents. Ever. But I was twenty and thought I knew better.
Then I tried my own: OpenClub, a community management platform. I had a bit of angel funding and early signs of product-market fit. It’s essentially what Luma is today. But I couldn’t scale it, and the reason wasn’t the idea, it was me. I did this in 2016 when I had no idea how to run a company. I didn’t know how to hire, how to sell, or how to hold a difficult conversation with a co-founder, a customer or an investor. I knew how to write code and I thought that was enough.
It wasn’t. OpenClub no longer exists either.
Weiss wrote that the crucial skills for founders, like raising money, changing product direction and cultivating culture, are hard to learn on the job. He was right, and I proved it by trying to learn them on the job and failing repeatedly.
After OpenClub, I went and built things for other people. At AutoGrab, I built Australia and New Zealand’s most accurate predictive vehicle pricing system: scraping car markets every minute, running it through an ML model, producing residual prices more accurate than the industry leader at the time. I’ve built data pipelines that process terabytes per hour. These sorts of technical challenges are what make me thrive, and I needed them to rebuild confidence in what I could actually do.
But the real education came at Linktree and then at Blinq, which were my first exposures to genuinely compelling startups. Companies that were growing fast, raising real money and navigating high-growth mechanics. Watching leadership handle those scaling challenges taught me what kind of founder I wanted to be, and just as importantly, what kind I didn’t. It also opened my eyes to the mechanics of Australian venture capital, particularly through firms like Blackbird and Square Peg Capital. Australia’s superannuation system, where every employer is legally required to contribute a percentage of your salary into a retirement fund, creates a massive pool of institutional capital that flows into VC funds. It allows Australian VCs to write big cheques and back global success stories like Canva.
Eventually though, the product at Blinq reached its ceiling of complexity and I found myself spending my days interviewing candidates and managing existing systems rather than building anything new. I was hungry for chaos again, and there was none left to find there.
Leaving home
So I left Australia and moved to the UK.
Australia is an incredible place to live, but the tech scene is small, your biggest markets are fourteen-plus hours away and the path from idea to scale has real friction when you’re geographically isolated from the enterprise customers you’re trying to sell to. I wanted to be closer to the action.
In London, I joined Pactio, a company building the infrastructure layer for private equity. It struggled with product-market fit and ultimately didn’t survive, but the team there taught me what genuine excellence looks like. They are some of the best people I’ve ever worked with, and I still call several of them friends today.
Then came Pragmatic, my own attempt at building an AI email assistant. Another venture that didn’t make it. I won’t dwell on yet another failure, except to say that each one taught me something the previous one didn’t.
And then Oliver Beach described a problem to me that I’d felt deeply myself: the complete lack of visibility engineering leaders have over their workforce costs, their AI spend and how their teams map to the work being done. He pitched the pain, not a solution. No wireframes, no product spec, just a clear articulation of something that was broken and needed fixing. That resonated with me, because I’d learned by then that the best things get built when you start with the problem, not the product.
We co-founded Flowstate, with Oliver as CEO and me as CTO. It’s still early days, and it’s the hardest, most rewarding thing I’ve ever done.
Eight lessons for a younger me
Weiss argued that the most valuable learnings for running a startup come from actually working at one. I’d go further: they come from failing at several. If I could sit my younger self down, here are the eight lessons I’d force him to memorise.
1. Listen to your teachers
And I don’t mean your school teachers. I mean the people who try to guide you: parents, mentors, old bosses, the colleague two rungs ahead who keeps giving you unsolicited advice. Take it all with a grain of salt, of course. But recognise it for what it is: lived experience, paid for in somebody else’s mistakes, being handed to you for free.
That’s almost impossible to appreciate when you’re young. You think you know better, because the world you’re walking into looks nothing like the one they walked through. Sometimes you’re right. Most of the time you’re not, and the thing they were trying to tell you turns out to be load-bearing a decade later, when you finally trip over it yourself.
Listen properly. Absorb it even when you disagree. File it away. That information is dear, and it will help you later, often in ways you won’t see coming.
2. Don’t solution straight away
This is a lesson I’ve had to learn and re-learn at every single step. Someone describes a problem and I immediately start building something to fix it, because that’s my instinct as an engineer. But the gap between “I heard a problem” and “I understand the pain” is enormous.
I’ve learned to shut up, ask more questions and sit in the discomfort of not knowing. Don’t build anything until you deeply understand where the customer is coming from, because if you skip that step, you’re not solving their problem. You’re solving the problem you imagined they had. And if you don’t know who your buyer is, you’re just building for the sake of it.
Listen to your customers. They will actually tell you what they need, and if the pull is strong enough they’ll pay handsomely for it. Oliver pitched me the pain behind Flowstate, not a product spec. That’s exactly why it resonated.
3. Ship first, architect later
Remember that side project I mentioned, the one I ran for over a decade through three names and several pivots? It’s technically solid and it still runs, but I couldn’t care less about it because I built it without ever seriously asking who would pay for it. That’s the trap.
It’s fine to architect and prototype solutions as a way to learn, but you have to know that’s what you’re doing: learning. Don’t try to jerry-rig a prototype into a product and pretend it solves a real pain, because it won’t work. The market doesn’t care how elegant your code is. It cares whether you’ve solved a problem worth paying for.
Early on, nobody cares about your clean data pipelines. Perfect code without a customer is just an expensive hobby. And on the flip side, it’s completely okay for things to be a bit broken if it means you’re shipping, testing and learning. There’s a saying in engineering: “Nothing is more permanent than a temporary solution.” You have to learn to embrace that. You can always refactor later; you can’t resurrect a company that ran out of runway while polishing its codebase.
4. Get everything in writing, and never work for free
I learned this the hard way, more than once. I’ve seen equity conversations go sideways when nothing was documented: promises made and then conveniently taken away when it came time to honour them.
If you’re starting something with a co-founder, get a founder agreement in place early. If they resist putting things in writing, that tells you something important about the kind of partner they’ll be when things get hard. Run. And if someone promises you equity without the paper to prove it, run faster.
More broadly, your time is the most valuable asset you have as a founder. Some people will promise things, agree to terms, commit to timelines, then vanish or change the story when it suits them. If it’s not written down, it didn’t happen. Charge for your work from day one, because it sets the right dynamic and filters out people who were never serious. Work for the people who invest in you, and don’t waste your time on people who talk and don’t act.
5. Don’t go it alone
I’m a firm believer that you need more than one founder. You need someone to balance decisions with, to share the complexity and to help build trust with your team. A single founder carrying everything alone is a fragile structure, for the business and for the person.
But more than that, I think you need healthy friction. You don’t want a co-founder who agrees with everything you say. You want someone who thinks differently, who challenges your assumptions and who forces you to defend your reasoning. That friction yields creativity. A co-founder who agrees with everything you say won’t get you far, but genuine, constructive disagreement between people who respect each other is one of the most productive forces in a startup.
The key is that you always have each other’s back. You can disagree behind closed doors and still present a united front. I know Oliver has my back, and he knows I have his. That trust is the foundation everything else is built on, and without it, the friction just becomes conflict.
6. Know when it’s time
There are two sides to this, and both are easy to get wrong.
The first is the one that bit me hardest. Someone on the team kept pushing for a promotion they weren’t ready for, then took it personally when it didn’t happen and started actively undermining the people around them. They created a cultural rift that took far longer to repair than it should have, because I let it go on too long hoping it would resolve itself. I should have acted sooner. Roles can be refilled; culture cannot be repaired if you let toxic behaviour fester. Sentimentality about someone’s technical contributions will cost you far more than the short-term pain of replacing them.
The second side is the inverse, and nobody talks about it enough. Sometimes a great person on your team is unhappy, or has outgrown the role, or is being pulled toward something else entirely. Your instinct as a founder is to fight to keep them, because you need them and replacing them is painful. Don’t. Your teammates are peers with lives and ambitions of their own, not retention problems. The best leaders I’ve worked with actively helped people leave when it was right for them — wrote the reference, made the intro, celebrated the move. Those people almost always come back, as investors, customers, hires or advocates. The ones who get guilted into staying just become slow departures.
Both cases are really the same instinct: don’t let fear or sentimentality delay the right call. One protects the team, the other protects the person. Frame it as endings, not as firing, and the decisions get clearer.
7. Constantly replace yourself
This one is hard to explain to someone just starting out in technology, because early in your career the thing that makes you valuable is your ability to execute. You write the code. You fix the bugs. You ship the features. That’s how you prove yourself, and it feels good.
But as you grow, the most important skill becomes knowing when to step away from the keyboard. When you start a company, you are the lead engineer. Then you have to replace yourself to become a manager. Then you have to replace yourself again to become a leader. Each transition means letting go of something you’re good at and trusting someone else to do it, probably differently than you would have, and that’s okay.
Old me wanted to analyse every data point and micro-manage the solution. New me knows that letting others make mistakes is sometimes the only way they learn. Hire people you trust, give them the framework, and give them the freedom to explore — including the freedom to get it wrong.
8. Learn to fail in public
Look back at this post. My first two jobs, gone. OpenClub, gone. Pragmatic, gone. Pactio, gone. If you’d told twenty-year-old me that a decade of my professional story would read like a list of dead companies, I probably would have quit before starting. But every one of those failures taught me something that would have taken ten times longer to learn from a win. The failures are the curriculum. The wins just prove you paid attention.
Two things I wish I’d understood sooner. First, fail in public. Hiding your losses denies you the one reliable source of support: the people around you who’ve been through the same thing and can actually help. The founders I’ve seen struggle most are the ones who treat every setback as a personal secret. The ones who struggle least are the ones who say it out loud, early, to people they trust.
Second, don’t wait for a win to start again. Grief for a dead project is real, but the best thing you can do with it is build something new. The lesson compounds when you apply it immediately. Wait six months and you’ve forgotten half of what the failure was trying to tell you.
I still carry the scars from every failed venture. I also wouldn’t trade any of them. If you’re reading this and something you built just died, I’m sorry. It was worth it. Get up.
The real lessons of building a startup are rarely technical. The hard part is people: how you express ideas clearly enough that other people can run with them, how you sit across from a customer and actually listen instead of pitching, how you handle it when someone tells you your product isn’t good enough and they’re right.
I still get impostor syndrome while I’m doing it, and I suspect it will never completely fade. But I’ve learned to build through it rather than be paralysed by it. I love our customers at Flowstate. Once I’m introduced, these people feel like collaborators in the truest sense. I want them to succeed, and they want us to succeed. That dynamic is rare, and when you have it, you protect it.
Mindset, not postcode
Weiss’s piece was ultimately about preparation: the argument that working at a startup gives you instincts and learnings you simply cannot get anywhere else. He recommended Silicon Valley because it has the densest ecosystem of talent, capital and opportunity. He wasn’t wrong, and that ecosystem is still extraordinary. But I’ve learned that mindset matters more than postcode. You can develop those instincts in London, in Melbourne, in Brisbane, anywhere, if you’re willing to actually make the mistakes rather than just read about them.
In Australia and the UK, people still sometimes ask me, “Why are you even doing that to yourself?” I’ve rarely had an American ask me that. The default posture in the places where founder culture is densest is different: they’ll back you, challenge you and work hard alongside you no matter how crazy the idea sounds. That posture isn’t geographic, though. It’s a decision. You can find it in London or Melbourne or Brisbane the moment you commit to it, and you can stand in the middle of Silicon Valley and never adopt it.
You just have to decide who you want to be: the person who is in it for the long haul, or the person who doesn’t really care. Because if you’re the former, and you want to thrive, and you want to build your own thing, then you’ll be an incredible founder. But you need to learn how to do it first, and the way you learn is by doing it badly, then less badly, then well.
Weiss wrote that piece in 2012. It’s fourteen years later and the advice still holds: the best preparation for starting a startup is working at one. The only thing I’d add is that it doesn’t have to be in the Valley. It has to be in your head.
So that’s why I’m calling this what it is: my advice to a younger me.
If you’re just getting started, I don’t expect you to listen to any of it. Some of these lessons my parents tried to teach me years ago, and I ignored them because I thought I knew better. Shock horror, they were right. Lived experience is the only teacher most of us actually respect, and by the time you realise that, you’ve already done the learning the hard way.
But that’s the point. I wouldn’t change a thing.