The Un-CTO Advantage: Lessons from Non-Technical Founders Building Award-Winning Tech
- Lauren Rutter
- Nov 26, 2025
- 11 min read
Updated: Dec 1, 2025
Three founders share why outsourced development delivered better results than hiring in-house technical teams.
"I don't think I need a CTO," Lacey Webb said from the stage, and you could almost hear the collective intake of breath from the startup-focused audience.
It's the kind of statement that violates nearly every piece of conventional wisdom in the tech industry. Investors ask about it. Advisors insist on it. The entire ecosystem treats it as gospel. If you're serious about building a technology company, you need a technical co-founder or a Chief Technology Officer.
However, Lacey Webb, Shane Britten, and Anthony Joseph - three non-technical founders who've built technology platforms in vastly different industries - aren't following that playbook. And judging by their results, maybe they're onto something.
At a recent panel discussion in Brisbane, these founders shared their journeys building technology companies without traditional technical leadership. Lacey runs Resource Hub, a waste management consultancy with its own compliance platform. Shane built Social Protect to combat online abuse after a family tragedy. Anthony's family has been in the fresh produce business for over 100 years and has built a trading platform for the industry.
What emerged wasn't just a defence of their choices; it was a compelling argument that for many founders, especially those solving real industry problems, the conventional wisdom might be entirely wrong.
The CTO Myth and Why It Persists
The pressure starts almost immediately. Launch a tech startup as a non-technical founder, and the questions come fast: "Who's your technical co-founder?" "When are you hiring a CTO?"
Shane Britten experienced this pressure firsthand. After a family tragedy drove him to build Social Protect, everyone had opinions about his team structure. "I think I'd probably challenge the idea that we have four CTOs," Shane said, gesturing to the SixPivot team. "They're just you and your team.” (Referencing panel host and SixPivot founder, Faith Rees.) “To have someone in-house dedicated to technology when what we're principally trying to solve is a people problem, I don't think that necessarily makes the most amount of sense."
His reasoning is pragmatic: "At lean start-up time, every dollar has to count for $100, right? Getting someone with the right technology background and experience who can traverse between social media, mobile apps, web development, everything else that fits in that tech stack… no one's got that range of experience anyway."
It's a point that often gets lost: modern technology stacks are incredibly diverse. Social Protect needs expertise in social media APIs, mobile development, web platforms, cloud infrastructure, AI integration, and security. Finding one person with deep expertise across all those areas isn't just expensive, it's essentially impossible.
Lacey Webb redefines what a CTO should be: "I do want a CTO, but I want a different CTO. Number one, they have to be comfortable with the fact that Chris Gilbert is my guy and that the SixPivot team will be our development team. I don't need a technical CTO. I actually need a sales-driven CTO."
Resource Hub has two businesses: a service business that grows 100% year over year, and a subscription software platform. The bottleneck isn't technical execution; it's sales and market expansion.
Anthony Joseph, who describes himself as "a fruiterer — as non-technical as it gets," offers another perspective: "I don't need to be the smartest person in the room, but I need really good people around me. What works for me is when I can call Faith, or I can call one of the [SixPivot] guys and say, just tell me what the problem is, explain it to me, and then I can say, okay, how do we fix it?"
But there's another advantage all three mention: "I don't want to manage the techs," Shane admits with a laugh.
The Expensive Education: When Big Firms Don't Deliver
Anthony Joseph's family has been selling fruit and vegetables in Australia for over 100 years. The fresh produce supply chain, as he describes it, is "a very complicated, opaque market."
"If you could imagine the stock market before it was digitised and being able to access information," Anthony explained. That was the state of fresh produce trading, and he saw an opportunity.
In 2016, Phoenicia engaged with EY's digital supply chain team. "They all got hot, warm and fuzzy about the idea of building a solution for the fresh produce, $13 billion per annum industry."
The scale was significant: within 9 months, 10,000 build hours and substantial investment yielded a working product. "Do I regret? No. Are we a bit ahead of the curve? Yes. But that effort would not have happened without getting excited by it."
But the relationship fractured. "We were dealing with a couple of layers of people before us to the developers up in India, and it was a bit clunky," Anthony shared. "We weren't going to transition the industry globally in five minutes."
When they parted ways with EY, Phoenicia had a product but no tech team. That's when they found SixPivot.
"We landed with SixPivot, and it was just, it was a godsend. We're working straight with the team and really streamlining things. Touch wood, it's an extremely stable product now."
Faith Rees, monitoring the panel, joked: "Anthony doesn't ring me very often. Maybe once or twice a year, and then I'm like, oh my God, what's happened? But fortunately, there's never really an issue."
Anthony acknowledged: "Once we got them under the hood, there was some fundamental stuff that we had to sort out, which they did. The product is stable now because of the finishing touches they put on it."
The lesson? "You have to learn, and you have to understand. And if you don't know something, ask. Going from a big firm with all the shiny bells and whistles to highly technical and really close to us - I just saw a problem and wanted to design a solution."
The Cost of Getting It Wrong
Shane's journey also came through painful contrast. His initial offshore build took 12 months. Then came the Manchester United opportunity.
Shane secured a presentation with the football club, potentially game-changing for a platform protecting public figures from online abuse. He triple-checked with the technical team: ensure everything was flawless, here's the date and time, let's test it.
"I jump on the call, and they've got the servers down for maintenance. I can't even open the mobile app. It says the servers are down… We didn't get a call back from Manchester United."
The contrast with his current setup is stark. That 12-month build was rebuilt in 3-4 months with the assistance of two SixPivot developers. "Now we've been doing live demos for two years. It's never failed. I could put it up right now and show comments getting deleted with absolute faith that they're going to get deleted."
Lacey's learning curve was different. Resource Hub was initially built on someone else's HSE platform as a concept test. "It was okay, but we had no control. We couldn't grow it. We couldn't change our questions. There was no flexibility at all."
The difference with SixPivot? Seven weeks from concept to a working platform that immediately delivered value: cutting report generation from 60 hours to 12 hours.
"I thought that it was going to be a 12-month process. I did not think it would be seven weeks later, when I had a working platform."
What Actually Works: Deep Understanding Over Technical Sophistication
The success of all three platforms hinges on a deep understanding of the industry problem, paired with technical partners who take the time to understand the context.
"I don't think there are any firms that get to the heart of the problem you're trying to solve like SixPivot does," Lacey explains. "Their understanding of our industry meant we could dive right in without wasting time on context-setting."
For Shane, working with social media platforms — companies that "are not there to help you eliminate abuse"— required precision. "We needed to be incredibly crisp on our technology because any little gap in our requirements was being met with derision or turning us back off. It was a very complex build and performed excellently once we had it done."
For Anthony, reliability isn't a nice-to-have; it's existential. "The software actually runs our main trading business. Essentially, we've become the use case for it."
Small Teams, Big Impact
Shane's rebuild took a quarter of the time with two developers compared to the larger offshore team. The difference? Daily interaction with developers who understood the mission. "It's not so much about the technology; it was more about the understanding of what you were trying to achieve," Faith noted.
Anthony's experience reinforced this: moving from EY's large team with multiple layers to working directly with developers eliminated communication bottlenecks.
Lacey found another advantage: "Having an organisation where they're across several different businesses, sectors, and types of technology — what am I limiting by bringing somebody in my business versus having access to that broader expertise?"
Shane's Soapbox: When Tech Isn't the Answer
Midway through the panel, Shane asked for his "soapbox moment"— and delivered one of the afternoon's most memorable observations.
"I'm so damn sick of hearing just AI everything. AI can do really cool stuff. But it's not always the answer to every problem."
He shared a story about a friend who suggested using an AI tool to convert Social Protect's entire codebase into another programming language. "But if we're putting it in AI, we're giving our code to someone else, right? We're basically giving them our entire product."
His broader point resonated: "We all don't understand the tech we're using daily. Imagine if I came to you as an officer of the Australian government and said, 'I'd like you to carry a tracking device around 24/7.' Would you do it? Hell no. Well, you're not only doing it, but you also paid for it."
The core message: "If a problem is a human problem, sure, we can apply tech to solving that, but we're not getting attacked by Skynet just yet. People are driving the negative things happening in our world. So, let's continue to understand people."
Technology isn't the hero of these stories; it's the tool that enables human-centred solutions.
Finding Your People
Perhaps the most valuable lesson came from Lacey: "It's really important to talk to people. You can't be an expert at everything. There are loads of people with incredible knowledge and experience out there. But it's important to work out whether they're your people, and if they're not, move on and find the right ones."
She'd been wrestling with a problem for three and a half months: how to leverage Resource Hub's services business to grow the software platform. A single 20-minute conversation changed everything.
"A problem I've been sitting on for three and a half months has frankly already turned into a bunch of emails, a couple of meetings, some clients set up, and two people onboarding to my platform next week." Her advice: "Just talk to people."
Shane echoed this: "I can call Faith, or I can call one of the [SixPivot] guys and say, just tell me what the problem is, explain it to me, and then I can say, okay, how do we fix it."
Anthony learned this lesson the expensive way with EY. His advice to founders: "You have to learn and understand. And if you don't know something, ask."
Practical Lessons for Non-Technical Founders
Here are the key takeaways distilled from three founders who've built award-winning platforms without traditional technical leadership:
Lesson 1: Domain Expertise Beats Technical Knowledge
The Pattern: All three founders understood their industries deeply before understanding technology. That domain expertise was more valuable because it ensured they were solving real problems.
In Practice:
Shane's counterterrorism background shaped how Social Protect handles accountability
Lacey's 20 years in waste management informed exactly what Audrri needed to capture
Anthony's century of family produce experience revealed supply chain gaps
Anthony's Take: "I just saw a problem and wanted to design a solution."
Lesson 2: Test First, Learn Fast (Even When It's Expensive)
The Pattern: Validate concepts before major custom development. Sometimes the education comes with a price tag, but it's worth it.
In Practice:
Lacey used an existing platform to prove demand before building Audrri
Shane's offshore build clarified the requirements for the successful rebuild
Anthony's EY experience taught him what works and what doesn't.
The Payoff: Better decisions, clearer requirements, faster execution when you build the right thing.
Lesson 3: Partners Matter More Than Org Charts
The Pattern: All three resisted pressure to hire CTOs or build in-house teams. They found partners who understood their industries and communicated effectively.
Why It Works:
Access to diverse expertise (APIs, mobile, web, cloud, AI) without one person needing all skills
No management overhead of hiring, onboarding, retaining technical staff
Flexibility to scale up or down based on needs
Shane's Logic: "Getting someone who can traverse between social media, mobile apps, web development—no one's got that range of experience anyway."
Lesson 4: Small Teams Move Faster Than Large Ones
The Pattern: Smaller, focused teams with direct communication outperform larger teams with layers of management.
The Evidence:
Shane: 12 months (large offshore team) vs. 3-4 months (two developers)
Lacey: 7 weeks from concept to working platform
Anthony: "Clunky" with layers vs. streamlined working directly with the team.
The Reason: Less coordination overhead, faster iteration, better alignment on mission.
Lesson 5: Build for Evolution, Not Just the MVP
The Pattern: Design for change from the start. All three platforms have evolved through multiple iterations with seamless handovers.
The Results:
Resource Hub: second iteration, self-service capabilities, and AI integration coming
Social Protect: continuous platform additions, enhanced detection
Phoenicia: stable enough to run daily core business operations
The Key: Initial architecture designed to accommodate growth.
Lesson 6: Don't Follow Playbooks That Don't Fit
The Pattern: None of these founders followed conventional startup wisdom, and all built successful platforms.
What They Didn't Do:
Didn't wait to find technical co-founders
Didn't raise VC before proving concept (Resource Hub, Phoenicia)
Didn't hire CTOs before understanding what they actually needed
Anthony's Wisdom: "I don't need to be the smartest person in the room, but I need really good people around me."
Lesson 7: Solve Human Problems, Not Technical Ones
The Pattern: Technology is the tool, not the objective. Focus on the human problem.
Shane's Reminder: "If a problem is a human problem, sure, we can apply tech to solving that, but people are driving the negative things happening in our world. Let's continue to understand people."
In Practice:
Social Protect: Online abuse is human behaviour, not just a technical problem
Resource Hub: Enabling environmental professionals, not just building software
Phoenicia: Creating transparency in relationships, not just building a platform
Lesson 8: Ask Questions, Keep Learning
The Pattern: Don't let technical complexity intimidate you into silence. Good partners explain, help you understand, and work with you.
Anthony's Hard-Won Lesson: "You have to learn and understand. And if you don't know something, ask."
Lacey's Addition: "Find your people, talk to them, figure out if they're your people, and if they're not, move on."
Lesson 9: Direct Communication Is Non-Negotiable
The Pattern: Layers between founders and developers create problems. Direct access matters.
The Evidence:
Anthony's EY layers were "clunky"— direct SixPivot communication streamlined everything
Shane's Manchester United failure came from misalignment
Lacey's seven-week success came from direct collaboration
The Rule: If you can't easily communicate with people building your product, that's a red flag.
The Bottom Line
These founders aren't arguing that no company should hire a CTO. They're proving that for many non-technical founders, especially those solving real industry problems, other paths work better.
Their results speak for themselves:
✅ Telstra Business Award wins and finalist positions
✅ AFR Innovation Award placements
✅ International recognition
✅ Platforms running real businesses
✅ Industries genuinely transformed
The real question isn't "When should I hire a CTO?" It's "What does my business actually need to succeed?"
For Resource Hub, Social Protect, and Phoenicia, the answer was the right partners who understood their missions and could help bring their visions to life.
Ready to Build Your Platform?
Whether you need a CTO, a development partner, or something in between depends on your unique situation. But if you're a non-technical founder with deep industry knowledge and a clear vision for solving real problems, you're already starting from a position of strength.
Want to learn more from these founders?
Read our Resource Hub and Social Protect case studies
Explore how the right development partnership can help you build without compromising your vision
Have questions about your own technology journey? Let's talk about what your business actually needs, not what conventional wisdom says you should do.
Contact us to discuss your challenge and explore what's possible.
