Something happens in almost every first meeting I have with a founder. They open a laptop, sometimes a notebook, and start walking me through everything the product needs to do. Login. Onboarding. A dashboard. Notifications. A referral system, because someone at a networking event told them referrals drive growth. By the time they get through it, they’ve described twenty separate products stitched into one, and I still don’t know why any of it matters to the person who’s supposed to use it or what would bring them back a second time.
For as long as I’ve been doing this, the deliverable that matters most has been the story: one clear enough that my team can build from it without me sitting in the room every day, and one clear enough that a stranger could hear it and understand exactly who it’s for and why they’d come back. AI has sped up how fast that story can turn into something real, sometimes dramatically. Finding the story in the first place is still entirely on the founder, and a decade of watching this industry move hasn’t shifted that part much at all.
That story is also what decides whether anyone comes back after their first visit, and a product people keep returning to is the one with a chance of becoming a business. Week after week, working that story out is the part I see Australian founders find hardest when they’re deciding what to build first.
A spec won’t tell you who comes back
Ask most people what a product person actually produces, and you’ll usually get some version of the spec: the document that lists every feature, every flow, every edge case. I used to weight that document more heavily than I do now. After a decade of watching Australian founders build, I don’t think it’s the thing that matters most.
A spec tells you what a system does. It doesn’t tell you why anyone would let that system into their life, what they’d actually do once they were in it or how often they’d come back. Those questions matter more than the feature list, and they’re a lot harder to answer honestly.
AI has made this problem visible faster, because it’s removed the excuse that building takes too long to find out.
What’s actually changed
A few years ago, testing a product idea meant weeks of development before you had anything an actual person could touch. That cost bought founders, and if I’m honest, it bought agencies like ours a certain amount of cover too. If an idea took two months to build, nobody was going to admit it wasn’t very good until well after the money was spent.
That excuse is mostly gone. A founder can describe an idea to an AI tool over a weekend and have something clickable by Monday morning. I’m not going to pretend that isn’t useful, because it is, for testing whether an idea has legs before anyone commits money to it. What I’ll say plainly, because founders deserve the honest version rather than the sales pitch, is that a weekend prototype demonstrates that an idea can exist. Whether it holds up under genuine customer use, live data and a second and third visit is a separate question, and a weekend build was never put together to answer it. Getting from one to the other is still where most of the actual cost sits, and our guide on how much it costs to build and launch an app in Australia walks through exactly where that spend goes if you want the detail.
What hasn’t moved, and what I don’t expect any tool to move, is the call underneath all of it: deciding which one product, for which one person, actually deserves to get built. That was always the hard part of the job. AI makes it obvious sooner, rather than three months and a fair chunk of a founder’s savings later.
A story from our own portfolio
A founder came to us wanting help building a way for people to manage private loans between family and friends: who owed what, on what terms and when repayments were due.
My team and I worked through what the product actually needed to do, for the smallest group of people it had to serve. What we didn’t build says as much as what we did. FairShare, the product that came out of that process, doesn’t match lenders with borrowers, and it doesn’t move money between them. As founder Michael Gallacher describes it, staying out of those two areas is what let the product concentrate on clarity and follow-through: a shared, visible record of the loan, a repayment schedule, reminders and an optional digital agreement for people who want more structure. The repayment schedule also builds in a reason to return, since every due date gives both people in the loan a prompt to open the same record again.
That focused version is what got the prototype fully funded within 24 hours. FairShare has since launched its consumer product and raised capital across two investment rounds, reaching a valuation of A$2.5 million. That came from being ruthless about which single story the product needed to tell before anything else got built.
Judging a product by whether people come back
There’s a question I put to founders constantly: are people really using this, or did they sign up once and disappear? Download counts and waitlist numbers feel good in a pitch deck. They tell you almost nothing about whether a product earned a place in someone’s week.
I’ve written before about what it looks like when people aren’t using your product and how to fix it, and the diagnosis is rarely a missing feature. It’s usually that nobody, including the team that built it, can say in one sentence what the product does for someone and why they’d come back to do it again. If your own team can’t answer that, your users certainly can’t either.
This is also where the gap between a product and a business tends to show up. A product can be clever enough to make someone say that’s neat, once. A business needs people showing up on their own, repeatedly, because the thing earned a place in how they operate. It’s a mindset change I still watch founders work through as they build.
Scope around the thing people will come back for
The instinct to build everything at once is understandable. Founders have spent months, sometimes years, thinking about an idea, and every part of it feels essential by the time they’re ready to build. Cutting scope can feel like cutting ambition, though in practice it rarely works out that way.
When my team works through MVP scope with a founder, the exercise mostly comes down to removing: sorting a feature list into what has to exist for the story to work, what can wait for evidence and what should be parked until there’s a clear reason to build it. The story decides the scope. If a feature doesn’t serve the one thing the product needs to prove first, it doesn’t belong in the first release, no matter how good it sounded on the whiteboard. For a lot of products, that one thing is whether people will come back and repeat the core task.
Onboarding decides whether there’s a second visit
There’s a moment in every product where a new user has to work out, quickly, whether this thing is for them.
Some people arrive already sold and will find their way in regardless. Others bounce off within seconds and were never going to stay no matter what you built. The group worth designing for is the one in between: curious, willing to give it a try, but not yet convinced.
I see the same pattern in early user testing, more often than founders expect. Someone opens the product for the first time, and if that first screen doesn’t make it obvious what to do and why, the story is over before it started. A blank input box asking “what do you want to build” sounds flexible in a pitch. It’s often the worst possible welcome for someone who has no idea yet what the product can do for them. Good onboarding teaches the story one small piece at a time, rather than handing someone a blank page and hoping they fill in the gaps themselves. Someone who couldn’t work the product out the first time rarely comes back for a second go.
What I’d tell a founder starting this week
AI has made the mechanics of building remarkably cheap. Anyone reading this could have a working prototype of almost any idea within days, and I’d encourage most founders to actually do that before spending actual money on development. It’s a legitimate way to pressure-test an idea, and I’d rather a founder find a flaw in a rough prototype than in a finished product long after the money is already spent.
Deciding which idea deserves that time in the first place, and explaining to a stranger why they should care, is still entirely a founder’s call. I don’t expect any tool to take that over. Every founder I’ve worked alongside who built something people kept coming back to could answer one question without hesitating: who is this for, what do they actually do inside it and why would they bother a second time. Everything else, including which tool builds the prototype, sits underneath that answer.
If you’re holding a feature list right now, work out the story behind it, including why someone would come back to it, before a single screen gets built.
Sasha Reid is the co-founder and CEO of Hyper, an Australian startup studio. Since 2015, he has helped more than 1,528 founders turn early ideas into viable products and businesses. Founders supported by Hyper have raised $482 million in capital.
Sasha writes about validating app ideas, defining an MVP, app development costs, AI-built products, early traction and preparing startups for investment.
