Gael Donnay on Building an MVP Without Burning Cash

Daniel Hakim0:00
Now, as you all know, our mission at BOA is to make quality advice and networking accessible to entrepreneurs across Australia at every stage of business. And today we're going to be learning from Gail. Gail is the founder and CEO of Step Insight, which is the development company that has built BOA. It's actually built all of KUBZ backend technology as well, and another family business that I have that I've worked with Gal for a very long time. He's been a CUB member for maybe like 8 years or 6 years, I don't know, a long time. And he works with many very successful companies, typically helping them, typically being their technology partner, helping them become more efficient and scalable. So, and Gal, I want to thank you for being here.

Gael Donnay0:53
First of all, thank you.

Daniel Hakim0:54
Thank you for having me. I want to start like, this is a topic that like It hits home a lot for me because obviously I've got both a technology-based business, Bower, and I have a more bricks-and-mortar business, Kubb. And definitely I think the technology business is more difficult, right? And so, and technology is something that is very appealing to get into, but a lot of people go in without understanding the full everything they should understand before starting and what to expect. So I really want to dive into that today. And the first thing I wanted to do was and prevent people from spending too much money on a piece of technology before they're sure, um, that that is exactly what they need. So can you maybe share— the first question I had was, how can founders test the idea or concept before investing, um, a significant amount of money in their, uh, in their app, in their technology, in their idea?

Gael Donnay1:55
Yeah, so there's, I'm going to say like heaps of things that can be known. The very, very first thing is for me like to be very, very clear. Like as Dan was saying, technology can be hard. And the first thing that people do usually is like they're not very clear on what they want to do. So the very first thing that I would do is actually get on a piece of paper, get on your laptop and start like really writing like, okay, what is it that I want to do? What is my ID going to do? What is What is my audience? What is my target market? I know it sounds simple, but like just doing this will actually force you to reflect on what we actually are trying to achieve here. Being clear on your business model, it doesn't mean that it's not going to change, but like it is like somehow a question that people completely like forget to think about. And like, because your product market fit is the first thing that you want to actually like solve. Like you want to make sure that there's actually a market, there's actually an audience, there's enough like, and that you're actually solving a problem. So getting very, very clear on like what is it that we need to do is the very first things that, very first step in what we need to do. In terms of testing it, we discussed like, it's always like hard. There's always interviews with people. We're always like going to say yes, yes, I would use this or yes, I would pay for that. So it's a bit of a hard one, but it is very useful to still discuss with industries, like making sure that you have the right network around you so that you can leverage this network when comes the time of testing this. The goal really, really, like if you want to test like an idea is to get out on the market. Like, so you need to build something really, really fast. So that you can go out and test. Nowadays, we've never been in a better time, like with AI, to actually build something fast, to build something super fast and cheap. Like there's like the no-code, low-code tools have never been better than now. Like where literally anyone now can build like a very, very quick mockup that actually have like a backend, which is like functioning apps with pretty much like zero, um, zero coding knowledge. So you can get like something fast. I'm gonna say fast, we're talking like days, like of getting something that you can get out to just test. If it doesn't look good, it's okay. If it doesn't do, it doesn't have like all the bells and whistles, it's okay. What you want is like get this app out there, getting it tested with real life users so that you can refine your processes, making sure that like what you're doing is actually like working.

Daniel Hakim4:44
So what I took from that is obviously first you need a plan, an idea, you need a plan, but the plan means nothing. Unless you've proven product-market fit. Now, when it comes to product-market fit, and I wanna talk more about product-market fit, but when it comes to product-market fit, interviewing people, what I heard from Gal, and to be honest, what I believe is true too from my experiences, interviewing people is not enough to let you know you have product-market fit because people are biassed and, or people might say that sounds good, but they might not actually use it or want it. So the best way to act, or the only way really, to actually improve product-market fit is to get an MVP out into the market and get in the hands of people. So a few questions here then. With the MVP, are there websites or platforms that people can use to build one themselves using AI now?

Audience member5:39
Yes.

Gael Donnay5:40
Like, so, and again, things that maybe like 6 months ago were not possible, but now like with tools like Lovable, with Base64, Um, what's the first one? Uh, Lovable. Lovable, like I love you. Yeah, Lovable. Yeah. Uh, like there's another one called like Base44. I said 64, but Base44.

Daniel Hakim6:02
Base44.

Gael Donnay6:03
Um, and those, those two like products, there's Figma Make as well. Like, so, um, allow you like literally like to build app by just telling them like what you want to build.

Daniel Hakim6:15
Like, uh, So basically building an MVP now is a lot cheaper, a lot faster. And, um, like when I was building an MVP, like we started building MVPs 4 years ago, you know, building MVP was slow and it wasn't super cheap either. Whereas these days you can build MVPs in a couple of days. And if that doesn't work, you can get in the market. If it doesn't work, you can build a new MVP that does something slightly differently that, you know, tests a new product or service. So I think that's a really powerful new tool. Can you share with us though your opinion on the difference between an MVP and what a lot of people bring up is a prototype?

Gael Donnay6:54
Yeah, like, so, so prototype is something that you do really, really quick that you, you know, you're gonna throw away. Like, uh, so what we're discussing, like, those, those type of, of products, um, they're usually like prototypes. So you know that after this you're gonna have to rebuild your, your, um, your tech stack, your product. You're gonna have to rebuild it. So that's why we, again, like this, you want it to be at pretty much zero cost. Prototypes should be like at pretty much zero cost, especially in an early stage startup, like, because you know, this is something that you're going to take and you're going to throw away or like your MVP is then like the bare bones, it says what it means, like, so it's the minimal viable product. So it's the product which has like the least amount of functionalities, but which will still do exactly what it needs to do to deliver commercially, like to actually like execute on the idea and deliver like the solution that you're trying to achieve. Like, so that's the difference. But an MVP like is never something that you're going to take and throw away. This is the base. This is the foundation of your product that will continue like growing and evolving. Like, so it has to be stable. It has to be robust because you're going to build on it. And this you don't want to take and trash. Otherwise you've burned money for nothing.

Daniel Hakim8:14
Yeah. So the MVP you're actually building on and it becomes your final product. Now, um, it's something that like, uh, you know, I've fallen into a few times. I'm sure a lot of people here have is that you have the, sometimes you can see the vision for your product. You can see the future. Um, and it's very alluring to feel like you need to build that whole vision in order to make the product, um, valuable or important. So when it comes, so, so what advice do you have for people to choose what they're most I guess valuable feature is like, how do you actually get the most basic important feature in your MVP? And it should be, should it be one feature or should there be, you know, three or how do you actually choose?

Gael Donnay8:58
So yeah, it's a good, it's a very good question. And this is the pitfall that most like, I'm going to say entrepreneurs like fall into. They usually think that again, they need to build the world like to, and then it needs like all the best, it needs to be perfect, it needs to be beautiful, it needs to have like all of the the features that they have imagined in their head. And that's when you start like burning cash. Like, so Steve Jobs said, like, simplicity is the ultimate sophistication. And it is what it is like, to make sure that MVP is what it needs to be, you need to get like one sentence was like, okay, what is it that I'm building? I am building a solution for business owners and entrepreneurs for like, you know, that allows them like to do networking and allows them like to meet each other. That's it. That's what I'm trying to do. So one sentence about like what I'm, my solution, my product like needs to do. That's the step number one. And then you go like backward. You say, okay, I have like all of those like features that I want, like everything that I want to build. You go backwards. It says, okay, if I remove this, does it actually, like, is my solution still, like, doing what it needs to do? Is it still delivering the value that it still, it needs to deliver? And that's how you get, like, to your, like, MVP, your lean MVP, which is I only need the bare bones. I only need what it's supposed to deliver, like no bells and whistles.

Daniel Hakim10:33
But often one product can have multiple features that delivers the same or delivers, like, If we, like, let's say we use Boa as an example, but if the goal was connecting business owners, so business owner networking, there could be features that do that in different ways. So do you then have to choose, okay, that's fine, that's the case, but which is the feature that does it in the, what's the most important way or most effective way to deliver on that value and choose that feature?

Gael Donnay11:02
So like the way, if it becomes hard, like usually, and we have like a certain budget, what we would do is like we use like things like Moscow Matrix, which is like must have, should have, could have, won't have. And you kind of like categorise like your features like this, which is just like, this is a must. What is a must is part of MVP. Anything else should go, like from an MVP point of view, you could have some of the could haves depending on the budget.

Daniel Hakim11:35
But you maybe shouldn't.

Gael Donnay11:36
But you should not. Like focus on the must have first. And split like all of your features between that, being like really honest. And again, your technology partner should help you with that. Like a big, big like things that we're seeing often is our clients do not listen. Like they think like people think in features in terms of outcome. Like you need to think about outcome first, not features. And like We see this every day. Like we, like technology partners, like see like what works, what doesn't work. Like when we, like you want to do too much, like too much too soon, because like more is going to take more time. So more time to go to market, more time to actually like longer to know if something is going to work or not.

Daniel Hakim12:27
Like, uh, guys, please throw in any questions you have on building— this is yours— throw in any questions you have on building an MVP, or specifically even with your MVP, or, you know, if you want feedback on what you should build, shouldn't build, what it may be. Now I want to talk to you about money because I always say there's only two things that can kill a business. You either run out of money or you run out of hope. And normally with startups, particularly tech startups, is you're running out of money and it's because you weren't efficient enough in the early stages, building the MVP, trialling the MVP and finding the most value and finding product market fit. So, What advice do you have to all of us today on how to— the best way to actually stay in your initial budget? Because often, you know, we raise a little bit of money from people, we've saved up, we've got a budget. How do we actually stick to that budget and make sure it doesn't blow over? And what are the ongoing costs that happen once you finish building? Because that's one thing a lot of people don't realize. Once you finish building, but then you— there's still ongoing costs with the technology to keep it going and bugs and issues. So Features bear money.

Gael Donnay13:39
So like money and budget are probably like, if like not being simple with like your features and your scope is the number one like mistake that entrepreneurs make like when building an MVP, budget is the second one. And budget for me like is kind of like two sides to that. There's on one hand, like, I'd be very clear with, I have a budget, like, which is, this is what I can spend on this MVP. And as you were saying, you cannot spend everything on just your MVP. So the first thing is, I would be very, very clear, like, with, again, like, tech partners, about what, like, how much money we want to invest into this. It is not so that like a tech partner is going to say, okay, well, let's spend like all of this money on this. It is like, so okay, we have this, we know the list of features that we can do with this. Let's try and focus on the features that we can do with this budget. And also like how we can use that like wisely, how we can use this budget wisely. Like a lot of like a tech partner, again, if something is not like super, super clear, And which is hard, like building tech is hard. Like I have to take like the vision that is in your brain, kind of like download it into mine and try to understand what needs to be built. Like which there's often like a lot of variables, a lot of parameters, like building a tech is like, is this iceberg, like it's your seal, but you don't know what's under. So looking at fixed cost project as well, like try and make sure that we're discussing like fixed costs with your technology partners.

Audience member15:33
Use.

Gael Donnay15:34
But it is very important to know this budget and know what we are going to spend, like, so we can get like the best solution for that. As you mentioned, the second part of like your budget is like, don't spend everything on one technology. Don't spend everything on just the MVP because like building the product in any, as any business, as any service and any product only represent what, maybe like 50% of the equation. There's still sales, there's still marketing, there's still a lot of things that needs to be done for iteration. Iterations to make this a successful business. So that's one. And then, as you mentioned it, once the MVP is out, like, you are going to get feedback from your users. You're going to get like starting like real use case and things are going to evolve. Like, that's when like it really starts, like the work really starts. Like, so there's this and then there's ongoing cost of maintenance. There's making sure that we're not creating like too big of a tech debt. Like you are going to, this is inevitable with big business, like building tech product. Like as you go along, like these things that are not necessarily moving, but like you actually don't want to leave this for too long. Like you want to make sure that everything, frameworks evolves, like new technology, new architectures, new this, new that. You want to make sure that you're not staying with something which is like 5 years old, like, because otherwise, like, the gap becomes like too big and it's becoming like hard then after to do it. So you also want to save a little bit of a budget to make sure that like a runway, a runway, like, so, like you said, well, sorry.

Daniel Hakim17:18
So just to be clear. So if you've, so if I've scraped together 50 grand for a product, obviously don't spend 50 grand on my MVP. At most, would you say spend $25,000?

Gael Donnay17:31
50% of it? I would say like, look at 60% of it, like 60% max. That's what I would, of my budget.

Daniel Hakim17:39
Maximum to go to the MVP.

Gael Donnay17:41
Yeah, maximum, because you're going to have iteration 100%. And as I was saying, you don't, then you don't want to get stuck as well with, okay, my, my, like, like a misconception that a lot of like founders have, like, is that, okay, I'm going to build my MVP, I'm going to put it on the App Store, or I'm going to release it like on the, on the web. And it's going to make me money like straight away. This is not going to happen unless you like, you know, you're lucky or the product is, has been like tested and trialled already. Like there's a market for it. Like people know it's coming. It's going to take some time to ramp up and start like the money flowing. Imagine like at a subscription of like $10, $20, how much you need to, how many of those monthly subscriptions you need just to cover the cost of of building a second MVP. Like if you just had to say build a second MVP, how much would it cost? Or if you were saying like my ongoing costs are like $5,000 a month, how much just to cover those costs do you need like to get this? So it takes time like to make money. So you need to have like this runway for marketing because otherwise you're just like, okay, my MVP is there like and no one knows about it. Like, so you also need cash like to do that.

Audience member18:50
Yeah.

Daniel Hakim18:51
And what can founders expect for ongoing costs from their tech partner? Because I think that's something that a lot of people don't expect. It's like, okay, I've built my MVP, but obviously I constantly have things pop up on the tech where users or people are asking me questions. And so you do need an ongoing cost with a technology partner. What should people factor in for an ongoing tech cost?

Gael Donnay19:16
So ongoing tech costs, you want to kind of like take into consideration between 10% and 20% per year of the original build. That's roughly like the, you know, the rule of thumb, like, is around that.

Audience member19:32
Okay, good.

Daniel Hakim19:34
And guys, I'm going to move to Q&A soon. So if you have any questions, throw them in the chat. I did have one more topic I wanted to go over with you. And that was what should founders expect from technology partners or their tech team when it comes to documentation of what to expect of what they're building. So for example, like as a founder, I'll be like, okay, I want to build a networking platform for business owners. And these are the features I want and this is what I want to do. And then the tech company or your dev team gets it. And are they supposed to produce like a plan, like if you were building a house and give it back to you and then build, or how does that work? Like, what are red flags?

Gael Donnay20:26
Like, so for me, like probably like the, I'm going to call this like the number one red flag is, and something which is becoming like more prominent is going to be really, really highlighted in 2 days' time where again, with AI, I'm going to say that like coding and it's because it's going to become like more in the next year to come is going to become like more and more of a commodity. So the part which is actually like the hard part in tech is the in-between, is understanding what needs to be built. So for me, like the number one green flag or the number one red flag like goes both ways is whoever you work with, whether it's technology partner or someone in-house, like the person which is going to be responsible, either your CTO or your tech partner, the person which is going to be responsible for that is like needs to understand exactly what you're trying to build. If you speak to this person and in one or two meetings, you don't feel like this person knows exactly, okay, this person talks my language, like he gets it. Like I can feel that he gets exactly what I'm trying to do. Like it's a feeling, like it's a feeling of explaining what needs to be done and the other person like understand very, very well because like the person in between the founder and the tech team is like probably like the most important, important person, like, uh, because that's, that's the translation in between like what exactly needs to be done to actually how it gets done. Um, so for me, that's the number one green flag slash red flag, like, so it's making sure that the, the person you're discussing with—

Daniel Hakim22:19
but should they produce design plans so you know exactly what it's going to look like and how it works?

Gael Donnay22:23
Yeah, so, so then, then Step number 2 is that, like, again, remember like this plan, this one-pager that we discussed like before about like being clear, super, super clear about like your idea and what are we gonna build. This is like the starting plan. Then out of this, normally what you wanna build is what we call like user stories. Like, so you wanna see as a user, I am able to connect on this platform. As a user, I'm able to go and post like a, something on this. I can message someone as a user. This is all the user stories. This is all the features that are going to need to be developed. Again, based on our list of MVP, based on what we need to actually achieve. Then the step number 3 is for the tech team to produce, as you were saying, a prototype, like a design. And again, right now it has to be a working prototype. It has to just to be a point-and-click, something that you can use, click, like, and trial. Like, so this actually forces— because this forces you to, the tech team and also the founder, to actually think about everything. Like, it's going to force you to understand, oh yeah, what about this? I hadn't thought about that. How do I go from here to here? Like, uh, like, like, now, like, does it make sense for the users? Is it complicated? Like, so it forces you to actually see what it, and even if it takes a little bit more time before going into dev, actually like moving stuff around, like on a prototype, like on a, on a design, pieces of design is much, much, much cheaper, like than doing that after when it's developed. And sometimes it has like very little, like, uh, impact when you have to change something in development, but sometimes something small can have like a really, really big impact. You don't see it, but actually like it changes like the way things have been structured. So that's why, again, if you're clear, we know exactly how it is, we know exactly it's been designed, what it's going to look like, how it's going to work, then you code. Like, you don't code before that. Like, unless you have that, you are going to rewrite stuff.

Daniel Hakim24:31
Otherwise, it will be very expensive.

Gael Donnay24:32
And it's going to be expensive. Like, the most expensive part is actually development. So if you have to change something, like, and it has an impact on, I'm going to say, like, the structure of of how things works, that's when it became—

Daniel Hakim24:45
so basically the one-pager with very good communication and, and the tech company, your tech team ability to communicate exactly what it should do, then design template like a workflow, then a pro— then a prototype, um, that you can actually, you know, move the screen, touch the button so you can be like, oh, it does— this doesn't feel natural, or this— I feel like doing this, or—

Gael Donnay25:06
and then you build, and then you—

Daniel Hakim25:08
and that could be for new features or obviously new app but it could be a new feature on your app or on your website. Everything.

Gael Donnay25:14
So, so just a single new features, you, you do the mockup, you do the design. The design is, is probably, is exactly the same as you were, you build a house, you don't build a house like, like without like building blueprints, like architects, like actually like designing. And remember that like building a piece of tech is like a more like building like a massive building or a bridge. Like, uh, it's, it's, it's quite complex. So that's you need like those plans, you need to think through actually how you're going to do things because otherwise like you trial and then again you spend a lot of time and a lot of money. A lot of like tech vendors as well like work not as a fixed cost project, then they're gonna charge you like every hour that they work on. So if like this happens and you're not clear on what you're doing or you have a lot of rework because it wasn't clear, it doesn't work, it hasn't been thought through, it's gonna get, it's gonna get costly.

Daniel Hakim26:09
Guys, I'm gonna move to questions. Jack, do you want to ask your question first? That's a really interesting one. Oh, Jack, you can, you can ask either. I get texted them. So whichever one you ask both, ask both.

Audience member26:28
Sorry.

Gael Donnay26:29
The second one, it was, I was just saying what you're seeing in AI, um, in addition to all kind of your live coding abilities and tools and apps now. Um, what's your view on creating a product that can stay relevant and not be replicated easily?

Daniel Hakim26:43
Yeah, because it'd be easy for people to replicate you now, no?

Gael Donnay26:46
Can I be honest with you? Any product is very easily replicable nowadays. Like, not nowadays, even like 10 years ago. Like, you can— a good, a good, like, uh, software programmers, like, can have a look at literally a piece of software, look at what it's doing, understand the business, and then you can replicate it. You don't need the code. Like a lot of people think that like you need the code or my code is my IP. Like actually I would say like the screens, like the flow, like all of this for me is more important than how it's coded because like you can reverse engineer by just literally like looking at what a software is doing. So, and you always say that the marketing and branding behind it is still the most relevant by keeping that, I guess. And like all of this, but also like when it's becoming like more, I'm going to say like more of an IP with something which is less like copyable is like all of your, I'm going to say like all of your algorithm, like the things which are not like easily like understandable by just like looking at it. Like, and it is like all the, all those like hours, all those like trials and errors that you've put into like making like those pieces better. Like, Saké, why does it, why does it do like this? What does it actually like when I have like this information and this information? What does it spit out like this? Like, it's because like we've been like thinking about like a process, an algorithm behind like to actually like, yeah, give an output to to a solution. That's the part which is actually like the hard part to replicate. And you're right. Now, like, now, like, you can pretty much like take any visuals, like, and ask like an AI to reproduce. So, yes.

Audience member28:42
Yeah.

Daniel Hakim28:44
Yeah. I haven't done it yet. I need to test them.

Gael Donnay28:50
Workflows are changing. Like now, like you can, as you were saying, like now literally you can take like a piece of software that exists and then recreate another software based on that. Like, and when I say recreate, it can do like mockups, it can do this. So even for us, like our workflows are changing of how we work. Like, but the problem now is it is going like so fast. So you people have to adapt, like, because Yeah, you have to adapt constantly.

Daniel Hakim29:15
And Jack's second question was, um, what, like, what's the, what are your thoughts on the best way of finding a technical partner? Like a technical co-founder. Did you mean co-founder or partner? Yeah, co-founder.

Gael Donnay29:30
Yeah, because it's, I think it's one of those things about doing a lot of biohacking myself and, and, you know, you can get 80%, 90% honest of the way there, but it would be ideal to have someone that's with me that can. So for me, like, this is like one of the number one, I'm going to say number one rule is either like when you build something is either work with a technical like partner, which is local. If you're not yourself like a technical person, or if you don't have a technical co-founder, like, go find a technical co-founder, like, so that you can have, like, someone working with you. There's a few things, like, so here, for example, like, in Sydney, there's Antler, like, I don't know if you know about it, like, where you can literally, they kind of, like, look at pairing founders. And so you're looking for co-founders, they're looking at this for you. And it's all around, like, obviously, like, they're assessing your IDs. They're also, like, investing in it. And as part of this program, they look at pairing co-founders. So it's one of the ways of doing it. Finding co-founders 100% is also, I would go in, how do you call this, like, the incubators, like startup incubators, like such as Fishburner, Stone and Chalk, those type of communities where you can also have the pitch nights. So I go to pitch night, there's always like, there's always a lot of people and there's always a lot of like people that are looking for partners, people that are looking to get like into teams as well. Student Talk, thanks Streamlabs. They are probably like here. Are you Cinebase? Yeah. So here in Sydney, like 100%, like Fishburners, Tank Swim Labs, and Stone Chalk.

Daniel Hakim31:38
And he said Antler as well.

Gael Donnay31:40
Antler.

Daniel Hakim31:43
Yeah.

Gael Donnay31:43
Um, all good, Jack.

Daniel Hakim31:45
Thank you, Amanda.

Audience member31:47
Uh, good morning, guys. How you going?

Daniel Hakim31:49
Morning.

Audience member31:50
Thank you. Really wish that I had a session like this before I developed, cause I just launched in July. But I guess when I was finding a development partner, they didn't really tell me what platform they were using, whether it was reactive or native. I probably want to know your opinion on it because I guess cost-wise as well, what are people doing these days and what's the best way to develop? Is it best, you know, to develop native or reactive?

Gael Donnay32:22
So, so, uh, like I would say 100%. So we're talking mobile, I guess, like here. Mobile apps. Yeah, so mobile app nowadays, you want to go like cross-platform. So you do not want to build native. If you build like, we still like, we arriving to like native code being able to be used on both, but it's still not, it's still not there. So right now, like you want to go like cross-platform. So, and you have like only two framework that you want to use, like which are either like React Native or Flutter. Like one is done by, like, you know, is backed by Google. The other one is backed by Meta. So that's, they're the two big like framework for mobile that you wanna use because they are cross-platform. So you don't have to, you don't have to two codebase. So meaning like paying twice. And also like when, again, ongoing cost, I have changed something here, I have to change something there. Like, so in terms of maintenance is also like a nightmare. Like for your tech team, like, and for your wallet as well. Like, so 100%, like at the beginning, you know that if you get big in maybe like X years, you will have to rebuild native. It is probably like a given. If you want to be like a perfect mobile app, you might have to go native, but it's not now. And The differences are like so little and like, it's not even worth worrying about it. It doesn't work.

Daniel Hakim33:53
Exactly. Worrying about it is not successful for us.

Gael Donnay33:56
Like, so, so 100% like cross, uh, cross-platform at the moment, like cross-platform framework.

Daniel Hakim34:04
Well, anything else, Amanda? All happy? Awesome. Nice to see you. So did I. Daniel.

Audience member34:17
Hey, look, how's it going?

Daniel Hakim34:18
Good, matey.

Audience member34:19
Um, yeah, really interesting so far and really timely as well. So, um, I work with corporates, um, helping stressed-out employees with their breathing habits. Um, I've since actually developed a quick 5-minute breathing test which takes in inhales, exhales, breath holds, series of questions to give you a score. I've built this all using Replit. Yeah, it gives you exercises based on your breathing score and things like that. The— there's probably about 50 takers so far, but I'm trying to get to that point where I'm getting the non-biased testers in there. In its current state, it's not massively user-friendly getting to the next stage of retraining program. So like a Headspace meets Strava type of experience. Based on what you're talking about, like, at what point would you say I start to invest in that tech assistance from a professional? And in what are some of the best ways to really get some of those non-biased testers using it so I can actually prove that it's worth my time to start getting to those next phases?

Gael Donnay35:28
So, so for me, like, the best, the best test is actually like to get it done. Like, I'm gonna call this like in real life, but like your real users. So like you need to get a way like to get it tested, to get it used by the literally the people that would use your products. Like, because that's where you're gonna actually, things are gonna come out. Like, that's when you're gonna know like, oh yeah, this works, this doesn't work. Like, oh, I need a little bit more of that. Or, or actually like this, like, uh, we really didn't need that. So you, you need to find a way like to get it out. Like, so I would say, okay, who are my users right now? Like, who do you want to give this to? Can you actually, like, with the people that you're working with, without this app, like, right now, can you actually, like, give this to them as literally not, oh yeah, I'm trying to test this. Can you, do you want to test this? No, no, no. As part of your work right now, try to use it for yourself as part of your work right now, as part of your own workflow. I would use this as one of my tools. To do my work so that I can actually see, okay, if it helps me, it actually gonna help like those other people and using this as a, again, as a real life scenario. That's how I would do it. That's how I would do it. And because before that, you're not gonna know like if it's, you can invest like really in the product. Like, so I would not before you have like this validation.

Audience member36:56
Yeah, great. Awesome. It seems, it seems that the test itself, I've been sharing it with clients as I go into the space and say, if you want to cheque out your own personal test, scan this QR code, it will take you to the test, etc. And it seems to be landing. But as it is just a test, it kind of ends once you've done the test. The kind of key part is the next part, right? And based on building with Replit, I've tried to build that free training program. It's actually pretty solid. But it's very, it's like building a house on very fine stilts.

Gael Donnay37:26
I feel like I could blow it over at any point. Yeah, and that's why like those two, like those local, like I haven't used Replit, but like very, very little, like to be honest, but you have things like, as I was saying, like have a look probably like at Base44, like which is probably more geared toward like building application, like no-code application, which is probably like a little bit more robust in what is going to come out of it. And still like being able to, I'm gonna call this like vibe coding or like building like by just like prompting like an AI. And they have like, they already have kind of like templates of apps as well, like of type of apps that you can build. Like, so you, again, you don't start from scratch. So that's something that would probably allow you to go much further than what you have and on a more robust basis. Because that's the thing as well, when you want to test, you also don't want to give to users something which is crap, which is like, okay, it's just a gimmick. I want still something which is useful and which is solid, that looks actually like a real product.

Audience member38:43
Yeah, great feedback. Is there any no-code tools that you would recommend?

Gael Donnay38:48
Yeah, so as I was saying, like, if you want to do something which is more like prototype, like probably like the lovable, the Figma Make. If you want to do something a little bit more solid, like Base44.

Daniel Hakim39:02
Base44. Yeah. Thanks, Dan. And also Monica Chambers put in the chat, Sure, a good reminder, the UTS startups and UNSW founders. The university ones are great. I always hear really good things about them. So thanks, Mon. Guys, if there's no other questions, that's it for today. I hope that was useful. I hope anyone that's already built their apps is not now depressed. But I certainly would have loved this when I started. So I hope everyone got some value from it. We appreciate you all taking the time to be with us this morning. We love you for focusing on constantly learning as entrepreneurs and doing what you're doing, which is trying to build something valuable for the world and making your own impact. So thank you all, and we hope you have a very good day. See you soon.

Gael Donnay39:55
Thank you, guys.