Startup to Scale-up Club Q&A – 13th Jan 2026

I joined Anton Kooll again, along with co-panellists Maarten Ectors, Mario Tomic and Eugenio Galioto for Startup to Scale-up Club. Once again focusing on product and technology, we fielded questions from startup founders looking for advice.

As always, we start out with each panellist’s “do’s” and “don’ts” for startup founders, then move on to the questions from the attendees. We cover topics including:

• recommendations for automated infrastructure monitoring;
• safe presentation of medical data in Femtech apps;
• trade-offs of cloud versus local AI deployment for agricultural technology;
• the risk of patronising, gender-based marketing in Fintech; and
• the value of building a trustworthy community over superficial personalisation.

Have a listen below!

Also available on Spotify:

Transcript #

[Anton Kooll] This is Startup Product and Tech Q&A, 176th session. We’ve been doing these now for over four and a half years, almost five years, and we’ve had about 290,000 people tune in. None of this would have been possible without people like our four brilliant panellists today. We’re here to help startups with whatever questions you may have in terms of building your early stage, whether you want to know perhaps something about your product roadmap, maybe a bit beyond that—your design, your prototype, landing pages, apps, testing, automation, full stack, low-to-no code, launching your MVP, or anything in between or beyond for that matter. This is the place to be.

The way we’re going to do this is we’re going to try and keep it quite straightforward. We’ll have some quick introductions, then we will be going on to some do’s and don’ts of early-stage product and tech, and then we’ll start taking some questions. If you want to ask us questions, you’ll need to join us here on our Microsoft Teams call. It’s audio-only, which means you can tune in from anywhere via any platform or device. All you have to do is simply go onto our website, startuptoscaleup.club. There you’ll be able to see today’s session, which is Startup Product and Tech Q&A 176. Scroll down a little bit and you’ll find today’s session. Click join; it’s a quick registration on Luma, and then through there, you’ll find today’s link.

Once you’re here on our Microsoft Teams call, all you have to do is drop your question in the chat. We give you the mic, you introduce yourself, and then fire away with your question. There are no wrong or right questions. Anything to do with early-stage product and tech—it’s allowed. There’s no need to be shy because it’s a learning curve for us all. Now, if your questions today are not on product and tech, then please save them for the other conversations we run. On Mondays it’s talent; on Tuesdays, product and tech. As you can see, today on Wednesdays it’s growth; on Thursdays it’s fundraising. The second Friday of each month it’s UK startup law, and the third Friday of each month it’s UK startup finances. That’s all from 12 to 1 pm UK time.

So again, they’re all from 12 to 1 pm UK time, and they’re all available on our site: startuptoscaleup.club. Now, you see, the reason why we do this is that, unfortunately, over 90 per cent of startups fail. The top three reasons for that are: one, market fit; two, running out of money; and three, not having the right people. But there couldn’t be anything as important in terms of your ability to thrive—not only to well and make sure you survive, but actually your ability to thrive—than your ability to get your product and tech sorted and do it right. So that’s why I’ve got four amazing people with us today to help you on that journey and ask any questions you may have.

So, without further ado, I’m going to start the introductions. Perhaps in the meantime, if the team would like to drop their LinkedIns in the chat and maybe just a couple of words about what their strength is, or what they like to work on, or what they normally work on when it comes to product and tech, please feel free to do that. My name is Anton Kooll; I’m your host. I’m Albanian and I love working with startups; normally, right after they get investments, I embed within their teams and help them hire and keep the right people. I also do some growth advisory work with a few other startups and accelerators, and help some angels and family offices with their due diligence and their assessments.

[Pawel Kaminski] A pleasure to meet everybody. My name is Pawel. I’m the co-founder and CTO at [Company Name] where we in principle help early-stage businesses, or businesses in what we call ‘non-sexy’ industries that require a transformation of their tech and product towards the economy of the 21st century, driven by technology and product thinking. And I’ve been helping and supporting founders and startups for the last 20 years, running technical product teams and building businesses—especially in this early stage, from zero to Series A. A pleasure to be here.

[Maarten Ectors] My name is Maarten Ectors, happy to meet you all. I’m a multi-award-winning innovator. I have a fractional consultancy where I work around the future of AI and all types of next-generation technology. In the past, this included blockchain, IoT, and cloud in 2010, and so on. Lately, I’m also the CEO of [Company Name], and we’re building an army of digital workers based on an open-source platform. Sort of think about it as the ‘Upwork’ for digital workers.

[Jock Busuttil] Hello everyone, my name is Jock Busuttil. I’ve been in product for about 20 years or so, and I work as a freelance product coach and head of product. I typically work with companies in a coaching capacity, an advisory capacity, or even hands-on as an interim member of their team. I’m also the author of the book, The Practitioner’s Guide to Product Management.

[Eugenio Galioto] Hi everyone, I’m Eugenio Galioto, a product-led fractional CTO, senior agentic engineer, and serial founder. Currently, I lead the tech teams across USA, UK, Australia, and Italy, with relevant agentic applications in production in fashion and real estate. I’ve also been part of accelerators like Entrepreneur First and OnDeck. I co-founded the business scale startup in the Bay Area and founded various other startups in different industries. I’m here to improve your way to build impactful stuff.

[Anton Kooll] Now, that is a golden team; thank you very much for that. How about this? How about we start with the do’s and don’ts. I’m sure you’ve seen plenty of those—stuff that founders do well, but also not quite so well.

[Pawel Kaminski] Sure, okay, so why don’t I start with a ‘don’t’? One thing that we are seeing a lot with our early-stage founders is starting from zero, or starting from the position where they are. For us, one of the crucial things is: don’t try to build crazy long plans and roadmaps. In most cases, the products that we build now are really tricky when they meet reality, which means trying to plan for the extremely long term—outside of having a vision—is really, really hard. So, don’t expect that your beautifully crafted Excel spreadsheet with 500 features in the correct order is going to be what you will be doing.

There is a level of predictability and forward-looking. Most founders start with, “In 2029, this is how my business is going to look like”. That’s way too optimistic and very rarely meets reality. From the perspective of a ‘do’, I will leave the guys to talk about customers and so on. My perspective on what to do is: do much less than you think you have to do, but do it in a way that—I really like the latest quote from Walt Disney—people can feel perfection. This means: try to do dramatically less, but in a world of plenty of things being built, try to be great, or outrageously great, at one thing. Hopefully, that one thing sorts out the biggest problem, but being great at one thing is going to be the differentiator for you.

[Maarten Ectors] I’m going to talk about a ‘don’t’ that I did wrong, and how I then did it differently. In 2024, I built a sort of app focused on all companies that had not enough functionality to warrant their own app. The old app was a terrible failure because I couldn’t find the right customers for it. So, then in 2025, I started working with AI customers, trying to find what problem they had in common, and then built the Green Tick AI platform based on their feedback. I’m still building, but the thing is, it’s already sold now to several customers. The lesson here is: work first with customers, then make what they need, and definitely use AI for it. It’s a lot better to generate revenue.

[Eugenio Galioto] So, I would say: do focus persistently, because being unfocused is one of the most dangerous elements that stops you moving ahead. In terms of a ‘don’t’: do not lose momentum. Keep making progress regardless of everything, in a way that keeps your mind always involved in what you’re doing. You will naturally find a way to optimise around it, of course, with AI, other tools, and other ways of doing things, but at least always be involved and don’t lose momentum.

[Jock Busuttil] So, I’ve been watching probably too much TV at the moment, so my ‘do’ is: focus on ‘what-if’ scenarios. Think about the most critical things that affect your success or potentially your failure, and kind of ‘game out’ alternative scenarios. For example, if you’re overly reliant on LLMs, what would happen if the cost triples or quadruples over the course of the next few years? Game out those scenarios and see whether your business model still stands up.

As a ‘don’t’, I would suggest something I’ve seen over and over: don’t assume that ‘you can build it and they will come’. If you watch Field of Dreams with Kevin Costner, the thing is, it’s easy to get wrapped up in the great thing you’re building. There’s a cognitive bias called the ‘IKEA effect’, where you get really invested in something that you’ve built yourself. The problem is that you can get so wrapped up in building something that’s really great that you kind of forget to check whether anyone actually needs the thing, or has the problem that you’re solving. So: don’t assume you can build it and they will come.

[Anton Kooll] That is some amazing advice; thank you very much to all four of you. Rightio, we’ve only got 44 minutes to go and I’ve got a few questions to go through, but it would be nice to have some questions live. Please don’t be shy if you’re tuning in via the live streams—whether that’s LinkedIn, YouTube, Facebook, or Instagram. If you’re on the live streams, please be aware that, unfortunately, we can’t monitor your questions there. If you do want to ask us any questions, you’ll have to join us here on our call on Microsoft Teams.

It’s audio-only, which means you can tune in from anywhere via any platform or device. It doesn’t matter if you’re working from a shared office in Shoreditch, or walking your dog in Surrey, or perhaps changing baby nappies in Bristol, or maybe having lunch in Liverpool, or making lunch in Glasgow—you can join us from anywhere. There are links on all those live streams, but if not, you can always check out our website: startuptoscaleup.club. Scroll down a little bit and you’ll find today’s session, which is Startup Product and Tech Q&A 176. Click join for a quick registration on Luma and there you’ll find today’s link. On the other hand, once you’re here, simply drop your question in the chat, we’ll give you the mic, you introduce yourself, and then fire away with your question.

If, however, your questions today are not on Product and Tech, please save them for the other conversations we run. Mondays it’s Talent, Tuesdays Product and Tech, Wednesdays Growth, Thursdays Fundraising. The second Friday of each month it’s UK Startup Law, and the third Friday of each month it’s UK Startup Finances. That’s all from 12 to 1 pm UK time. You can RSVP to any of them via our site, startuptoscaleup.club. Actually, what you also might want to do is go onto our site—at the top and bottom of that website, you can see a WhatsApp icon. If you click on that, you’ll be able to join our WhatsApp community of founders, investors, operators, and, of course, our second-to-none expert panellists.

I am going to read the question that was sent in to us, but otherwise, if you’ve got any questions on Product and Tech, please feel free to drop them here in the chat yourself. Okay, that’s an interesting one. She says, “Everyone expects me to get this right as we can’t afford to mess up. I’m the more tech-savvy out of three—I’m assuming co-founders—of a marketplace in Birmingham that handles real-time inventory updates from vendors. We need a monitoring system that alerts us when updates fail, but we’re new to this level of infrastructure. How can we implement a logging setup that detects these issues early, and which tools would help us track inventory data flow and prevent inconsistencies?”. I’m assuming they have some kind of SaaS that helps retailers and others deal with inventory. Why didn’t you join us live?

So, I’m guessing the problem is: when updates fail in terms of getting alerts for that inventory, what do you do and how can you make sure that data flow in the infrastructure works right? Is that right, team? I know this is a bit difficult because the person’s not here, but yeah, you can add.

[Maarten Ectors] So, there are several monitoring systems available, including those provided by cloud providers, and most of these monitoring systems have something called alerts. You basically can define when to trigger such an alert, so if there’s a problem with infrastructure, you can then trigger it. You could see if you could automatically resolve it. Sometimes, restarting a server or handling an incorrect input can resolve it. Sometimes you cannot, so then you have solutions where you get pinged and woken up, perhaps at three o’clock in the morning, to go and fix something. Basically, the question gives away that they should invest a little bit more time in infrastructure automation and DevOps to understand what’s possible, because if they have a SaaS, that’s going to be a very critical aspect of their business.

[Eugenio Galioto] Well, I will say that there’s not much to update on the previous answer. The key point is that all of this is already battle-tested in terms of techniques, so it’s about having one proper freelancer doing just DevOps to fix all of this. It’s battle-tested; it’s not pioneering, so it’s just about choosing the right solution.

[Jock Busuttil] I don’t have anything to add specifically, but maybe the other panellists who are doing this kind of thing within their own startups or for their clients could give some examples. Could you maybe give some examples of the kind of tools that you use to do this in your context?

[Anton Kooll] Fine Jock, thank you. Paweł?

[Pawel Kaminski] So, it depends on the infrastructure at this moment. For example, if you are on Heroku, which is a platform-as-a-service, they’ve got multiple reports if something goes wrong, so you can just set it up on Heroku as part of the platform. We use a combination of things from the perspective of controlling bugs and defects. There are tools like Rollbar and Sentry, and just like the guy said, there’s plenty of them; just type in your infrastructure plus your languages to find those tools. They work really, really well. It’s just like adding Google Analytics to your website or your system; you start capturing more and more.

Also, the GCP platforms have these; it’s not like alerts are an add-on, they are built into the thing. You just have to configure them. So, if someone logs into your database structure, you can set it up so that it tells you every single time a transaction fails. My view would be a little bit more from the perspective of how to think about it: we always say ‘move the quality to the left-hand side of the process’. This means: don’t try to catch the updates only when they fail somewhere in your database. I am sure that they are failing in your database because of some reason earlier in the flow. This means you might actually build a better input of the data, or better checks wherever the data is coming from. If you’re uploading a CSV, do not allow a bad CSV into the system. If you’re allowing people to manually put this in, make sure that your form on the front end constrains them enough so they can do the job, but forces the data formats to be in a correct shape.

And the other thing that we’ve seen work really, really well is—sometimes you don’t know how smart and creative people are when using your system. Stuff like LogRocket, which allows you to view this session anonymously to see how the user clicks and what they do, might help you find out where the issues are coming from rather than just responding to them happening. And the last one is: make those issues extremely visible to everybody. We do what we call a ‘zero bug policy’, which means every single time a bug, or a defect, or a wrong update fails, it goes to our ticketing system automatically. The development team has a rule that they should pick that particular ticket before working on new functionality. That’s what we call a zero-bug system because they can triage and fix it straight away. Making it visible, moving it to the left, and watching how users ‘creatively destroy’ your system are the ways to stop issues from happening rather than just monitoring the outcome.

[Anton Kooll] This is from a Femtech founder who’s based in Leeds, pre-seed, who used to be a midwife. “We’re creating an app that helps expectant mothers track pregnancy health metrics and access prenatal care advice. The question I have is that we’re struggling with how to present data to expectant mothers in a way that it’s easy to understand but medically accurate. Should we invest more in creating simple user interfaces with explanations, or focus on integrating medical professionals into the platform for real-time advice?”. Question two: “How do we ensure that we’re providing up-to-date, evidence-based health information?”.

[Jock Busuttil] From a product perspective, things that immediately spring to mind are fundamental principles. I’m sure you already are thinking about this: how can we minimise the risk of harm to the expectant mothers? Clearly, when giving medical advice—particularly in a scenario where you don’t necessarily have full diagnostic capability—the challenge is to ensure that what advice you do give is not potentially going to cause harm, either through inaccurate advice or absence of advice. To combat that, you need to have a very well-designed interface, researched with representative users, thinking about the possible range of abilities and understanding in your audience.

You also need to ensure that you have an excellent content designer who can make sure that the information you do present—whether verbal, visual, or otherwise—is absolutely clear and unambiguous. The third thing, since you say you have a midwife background yourself, is to make sure that your medical basis for the advice you’re giving is as clinically sound as you can make it. I would think about it like a government service. In my background, I used to work in government on some services there, and the challenge is simply being able to accommodate a broad diversity of people. You must make sure that anybody from any level of understanding will be able to get the right—and in this case, a safe—result from using your product. I think, just reiterating that: user safety is tantamount. You must do all the appropriate safeguards as you go along.

[Maarten Ectors] If you want to see if users understand a simple user interface nowadays, go to things like lovable.dev and generate different designs in minutes. Then, show them to different users and ask, “What do you understand here? Can you tell me what’s clear and what’s not?”. Look over their shoulder as they click through a version of your app. You will very quickly learn what they understand and what they don’t.

Making simple user interfaces is a lot easier now with AI. Whether to use simple interfaces or a medical professional is actually a business decision. Is there something where you can show some simple information and then have medical professionals available as a premium service? If customers value that and would pay for it, that makes sense. If your business doesn’t warrant that, then you might have to go with the simple user interface. As for how to update the information, it’s unclear where this information is coming from. This is why I always suggest people join the call so we can ask questions. Are you reading this from sensors? Can you validate that information was the latest? Or is this something that the user inputted? If it’s user-inputted, you need to continuously ask if things have changed. It’s not clear enough to help you on that aspect, unfortunately.

[Eugenio Galioto] The key aspect here is to understand whether this is an agentic app or not. For example, I’m reading “real-time advice,” which I’d expect to be done by an AI, by an LLM. The very first principle here is that the app needs to be usable and understandable, so the UX/UI comes first. You can have three data points out of ten, but if these three are very readable and impactful, it makes sense to invest there. Then, there’s the aspect of the agentic flow. If you have an agentic app, this is a bit different because you have more freedom in how you interact with the user. Instead of being a fixed button or a fixed text form, it becomes a conversation. Every time, you can refine the conversation in a way that’s transparent from the user’s perspective but meaningful to you. You know which points you want to collect and which advice you want to give. So: first point, maximum focus on the UX/UI. If it’s unusable, it’s just useless. Second point: if it’s an agentic flow, you need to combine that with the UX/UI and refine the prompt and agentic stuff. Maybe you want to start with a fraction of the metrics you want to collect, as long as you can provide real value on those.

[Pawel Kaminski] That’s superbly interesting and great advice from everyone. I’ll just add: I’ve been recently on the battle of how we display the dashboards and information to our founders about how their businesses are doing. It’s exactly the same problem: how do we display data so that it is, as the founder here said, “simple,” but also understandable so you can make decisions based on it? I went down the rabbit hole of trying to figure it out. I think that the security of the user and not causing harm is the crucial part. Whatever you do, if you are trying to manipulate the data or can’t display it correctly, just don’t. It’s better not to show it than cause harm.

There are a few other rules about data excellence, and these are not just my thoughts—there are experts in the domain. There are really cool books by a guy called Edward Tufte. He talks about powerful ways to create dashboards and present information. One principle is to always show the data, which sounds obvious, but in many cases, people augment it or make it invisible to the eye. There is a statement about never distorting the data. If you watch the news and someone says the budget goes up or spending goes down, has it been normalised against other factors? You can very quickly distort data on dashboards, and I’m sure you can distort medical data as well.

There is an interesting aspect regarding ‘data versus the amount of ink’ required to present that data. The less ink—or in our case, pixels—used versus the amount of information shown, the better. If you’ve got plenty of stuff that makes the data less visible, it is much more difficult for the audience to read it. As an advice to this person: one, you can experiment plenty. You have to be safe and secure. You can get advice from medical professionals. It just requires attention to detail. The moment we as humans see a data representation that makes sense, you feel that perfection. It will be very obvious if it’s not working; keep digging, keep searching, and keep asking questions. There are also tools for heat maps, so you can see where people are clicking or where their mouse goes. There is plenty to do; it just requires a certain level of attention, and I don’t think there are easy answers. It just needs time.

[Anton Kooll] Question: Agrotech founder in Norwich, seed stage, family farming background. “We’re building a platform to help farmers monitor soil health using AI. How can we decide whether to host our AI models on a cloud platform or deploy them locally on the farm’s devices? What are the pros and cons of each approach in terms of performance, scalability, and internet connectivity in rural areas?”. I think we’ve had a few similar questions from farmers; I’m guessing this is a common issue. We live in such a bubble, so it’s hard for me to understand if you’re not in that industry, but I’m basing it on the fact that we’ve received a few questions from farming tech lately about the difference between clouds and physical devices.

[Eugenio Galioto] The very first question is whether we are talking about Large Language Models (LLMs) or traditional neural networks, such as deep learning models. The difference is that the inference of LLMs locally requires big hardware or significant trade-offs, like quantization or cloning. If we are talking about deep learning models, you can decide based on how cheap the hardware to run them is. However, a network of devices represents costs, logistics, and maintenance. Maintenance takes more effort in general, so it’s not always the best solution. In some cases, it could be easier to solve the internet issues first. Imagine satellite internet connections and stuff like that. I would try to solve the infrastructure first and keep everything in the cloud—at least at the beginning—just to validate that everything works and make operations smoother.

If we are talking about larger language models or vision models that require billions of parameters, it’s crazy expensive to run them on-premise at the farmer’s place. Even if you have NVIDIA Jetson or similar local devices, it’s probably not worth the effort. It’s way better to start with cloud solutions, improve connectivity where possible, and start from there. So, it really depends on your case, but in both cases, I would start by fixing connectivity issues—for example, with satellite internet. Locally, it can even be something with LoRa, depending on your hardware skills, and then later you can optimise on-premise solutions.

[Jock Busuttil] I won’t speak necessarily to the technical implementation, but I would say: consider where the constraints in the system are. For example, if the primary constraint is internet connectivity, then think about how that constrains the design of any potential solution. Is it that you have intermittent connectivity, or reliable connectivity but at a low bandwidth? Understanding that constraint informs the design of what is possible. If you know you have intermittent connectivity, then whatever you build has to be able to cope with being intermittently on and offline, regardless of what models you use or where they live. If you are constrained on bandwidth, you need to think about the minimal amount of information you can get away with sending. Understand the context of your users—in this case, the farmers—and design for the lowest common denominator. If you can’t create something that addresses the desired outcomes whilst functioning within those constraints, then you have to look at ways of removing or changing them. As the other panellists said, you could change constraints by adding technology, like satellite connectivity. Fundamentally, you have to understand what those constraints are and whether a solution is still possible.

[Pawel Kaminski] I love the idea of searching for the constraints that will enable the rest of it; it brings me back to the ‘theory of constraints’. One thing I would strongly consider here is: you can start building your product with the users that you really, really want to have, and not—in the first instance—build for people who don’t have an internet connection. I reckon there is a segmentation of problems you can approach. Building hardware products versus software products is a very different ball game in terms of difficulty. I’m sure there is plenty you as founders could learn from the automotive industry. The moment a car becomes a piece of software that drives on the road, a lot of things become enabled. The last thing I would strongly consider is how to monitor what is really going on in your system, no matter if you build it distributed or not. I can imagine founders calling you and saying, “It doesn’t work on field 75; what’s going on?”. If you’ve got no answers because your system is offline or doesn’t collect information, you’ll be in customer service hell. Observability would be something I would consider as the first thing: can I know when something goes wrong? Maybe based on that, you can figure out the constraints.

[Maarten Ectors] I would look at six different aspects to make a decision. First of all: the data volume. Are we talking here about simple sensors, like a humidity sensor or temperature sensor, or cameras that take high-definition images? In fields where the data volume is very high, you might have to do local processing. If it’s very low, you might not have to use the cloud. You don’t want a ‘data tsunami’ going into the cloud from thousands of high-definition cameras if you can process locally and just validate that there’s no new information—so ignore, ignore, ignore.

The next one is cost. On-premise validation and running models is going to be a lot more expensive than using the cloud, provided data volumes aren’t too big. Hardware is expensive, especially if you need GPUs or TPUs for AI. There’s also a hardware availability issue: is the hardware available to everyone, everywhere in the world?

Connectivity is another one. Several methods were mentioned, from LoRa to Starlink. This depends on how much data you have to send. If it’s a soil sensor for humidity, it’s better to use something like LoRa and send it to the cloud. If it’s video, you’d probably use Starlink and might want to do expensive processing on-site.

Response time is also key: do you want something to happen immediately? If you need millisecond response times, you need to do it locally. That is probably not as important for this use case, so the cloud is still a possibility. Everything else falls with the business case: is there a return on investment? If farmers don’t want to pay for expensive equipment, then the cloud might be your only option.

[Anton Kooll] Thank you very much for that, gentlemen. We’ll go through to another question which I’ve put in the chat, but I’ll read it out loud. By the way, just a reminder to those of you that have just tuned in: this is Startup Product and Tech Q&A 176. We’re here to help you build your early stage, from product roadmap to prototype, MVP, and anything else in between or beyond.

The question is: Fintech founder based in London, seed stage, I am a chartered accountant. “We’re building a platform that offers financial literacy tools and low-fee investment options for women. We’re trying to create a platform that feels personalised and approachable for female investors. Should we focus more on developing financial content tailored to women, or prioritise creating a community-building feature? What’s the best way to ensure the app feels different from existing investment tools whilst maintaining credibility?”. I have to admit—.

[Jock Busuttil] This question started my ‘spider-sense’ tingling slightly. The reason why is it reminded me of the 2012 Bic Biro that was ‘designed for her’. That just created an absolute PR disaster because it was just really patronising. I’m not suggesting for a moment—I don’t know whether you’re a male or female founder, or what the rationale is for coming at this—.

[Anton Kooll] The message was from a male, so I tried to look them up on LinkedIn. I can’t find much; it seems they’re not public yet. But this message came from a male person, and I’m assuming he’s a founder or co-founder.

[Jock Busuttil] Okay. I mean, again, I can’t speak to this not knowing who you are or whether you have female co-founders. My overriding question would be: to what extent are the investing habits of women significantly different from men in the first place? If the goal is just to make investing more understandable and easy to get to grips with, I’m not entirely sure how the male/female split would come in. I would counsel caution as to whether or not this is a fundamentally good idea. Maybe test out the concept before investing a significant amount of your time and money to figure out whether this is actually a good idea with your intended target audience. Be open-minded to the responses you get.

[Maarten Ectors] I also, from the description, can’t understand what the problem is that the customers have. So again, if there are listeners and you have a question or comment, join us, because we love to ask you questions. Here, the first question is: what’s the problem that your customers are saying they have, for which existing investment tools aren’t adequate? If there’s no such problem, you might actually be building ‘hope they come’, and then finding out they don’t.

In the past, I worked on a similar use case, but it was for young parents. We didn’t necessarily look at whether a parent can invest in stocks and ETFs, but rather: is there a market for parents to open a JISA for their children, and then have family and friends—the grandmother, the uncle, the aunt—able to make gifts into that JISA? Then the parents can invest those savings into trackers so that by the time the children are 18, a lot of money is generated. If it’s that type of thing, yes, it could be interesting, but then we’re not talking about women only; we’re talking about parents. We need more information to help you tell you exactly what to do here.

[Anton Kooll] What are your thoughts on this?

[Pawel Kaminski] I have to admit, I agree with the guys. Unless we hear from the audience that you’re trying to target, it’s very, very tricky not to be patronising. I would consider taking this question totally outside of ‘woman or not woman’ and just look at personalised versus community-driven advice. In most of these scenarios, I would probably go for the community aspect. Personalisation done really well is useful, but we as humans can be untrustworthy of it early on, especially if it feels intrusive.

Even though 80 per cent of the shows we watch on Netflix are recommended by engines, my first point of view would be to consider community first. We love to follow; we love to be part of a shared responsibility. We trust imitation—look at eToro, where you follow someone else’s trading patterns. There is something in community building that scales the confidence of people. You find a connection with someone who is a human like you. I like the community aspect more than personalisation, even though the funny thing is you can put ChatGPT in and call it ‘personalisation’ tomorrow. That’s an easy thing to do, versus building a correct, trustworthy, well-vetted community, which is much harder. I would be cautious about building this, in principle.

[Anton Kooll] Thank you very much, team. Here’s my quick two pence on this. Number one: I’ve learned that one of the best things to do in startup land is to try to find a solution to a problem rather than the other way around. Once you do that, you have a much better chance at succeeding. Work on something that you are well-versed in and something that you’re passionate about. The more you know about something, the more likely you are to avoid deadly mistakes. The more passionate you are, the less likely you are to give up when storms come—and in startup land, storms are always coming.

That doesn’t mean a man can’t come up with products targeted solely to women, but just make sure you know what you’re doing. As the chaps here touched on: if you deal with a community, you will be able to learn much more about what you can personalise. Maybe you can find a way to do both—i.e., use the power of AI to personalise what you learn from a community. Definitely ‘community first’ if you had to pick one. What are your parting words for us today?

[Jock Busuttil] I think the overriding theme is: understand the people who you believe have a valuable problem that you can solve. Understand who they are and what their context is, and ensure there are going to be enough of them to justify your investment.

[Maarten Ectors] In general, for a startup, the hardest thing to do nowadays is no longer build a solution; AI has helped with that. The hardest thing is selling your solution. Why don’t you start with that? Try to sell it even before you have it. People could pre-order or sign a letter of intent so that you know customers are waiting for something. Then you can design it with their input, and your success will be so much better.

[Pawel Kaminski] I agree. Technology has almost never been the problem. Deeper understanding of the problem and the ability to sell it is the goal, so keep chasing that and keep talking to us. Learning is a very powerful thing and we should all be optimised towards this. Learning together is even more fun. It’s been a pleasure to be here; thank you very much.

[Anton Kooll] Well, thank you very much to all three gentlemen, really appreciate it. A couple of quick things before my parting words. Number one: this was Startup Product and Tech Q&A 176. We ran six Q&As in total seeking to help you go from startup to scale up with on-demand, tailored advice. We do that by inviting the kind of people you saw here today—successful founders, savvy investors, and seasoned operators.

We also have some groups on WhatsApp where you can connect with these experts and fellow founders. You can do that by going to our site, startuptoscaleup.club; top and bottom of the site, there are WhatsApp icons you can click to join. This is also how you can register for any future sessions: Mondays Talent, Tuesdays Product and Tech, Wednesdays Growth, Thursdays Fundraising. Second Friday of each month is UK Startup Law, and third Friday is UK Startup Finances. They’re all from 12 to 1 pm UK time. Remember: this journey of yours in startups can be challenging but also exciting, so try to have some fun and be kind to yourself. Thank you very much, hopefully we’ll see you tomorrow for Startup Growth Q&A. Have a great afternoon and God bless you all.