Why Small UX Tests Beat Big Features | Nick Holzherr, GitLaw

Welcome to Beyond the First Wins, the podcast about what happens after the plateau when early wins are no longer enough in business, product, and design. I'm Daniel, founder of Duran, and today I'm joined by Nick Holzer, founder of Gitlaw. Hi, Nick. Nice to have you here. Please briefly present yourself. Tell us what you're doing, what you're building these days.

Hi, nice to be here. I'm Nick. I'm founder of Gitlaw, which essentially is an AI agent that will create or review legal contracts for businesses for free.

Nice. And how you ended up with the idea of building something I saw that like you had different companies before.

So I've been building companies for about 20 years. I built before this a company called Whisk, which I sold to Samsung in 2019. Before that, an HR SaaS company. I also bought a company. So I've bought a few companies, I've sold a few companies, and in that process spent a lot of money on legal fees and not just frustrated with the fees, but also just the time it takes. It can take, you know, a week, 2 weeks, a month, and I spent, I calculated over Over definitely over a million pounds, maybe somewhere in the region of about two million dollars on legal fees over the last twenty years. So I was just like, this is a real problem. Ninety-five percent of small business owners can't afford any legal advice. They kind of like hack it themselves. There's there's a big gap to help those people, and that's kind of where the idea started. It wasn't actually AI initially. It was actually much more. We're called Git Law. It was much more around Git. for legal, which the way we were kind of thinking about it was templates, free legal templates built by kind of an open-source community of people who provide them, plus some of the revision history and kind of collaboration advantages of Git, pull requests and that kind of stuff, that could be really, really helpful to make that legal process simpler, faster, free, et cetera. And then, of course, halfway through that process of building, AI explodes, and we're just like, wow, actually, there's opportunities to go way beyond what we had originally envisaged. But also actually there's advantages in taking a Git approach, kind of a Git-esque approach to how LLMs work with content.

And as you mentioned, you had a bunch of companies. Most of them were around tech, or you had different companies as well?

Well, before Whisk and AirHR, I did build a company called Quirky, which was basically QR code CMS. This was like in 2010, 2009 or 2010, when QR code scanners were not default in the camera app. So it was way before its time. I actually think if I had done that business during COVID I might have made— it could have been my biggest ever business if I had stuck with it. But there was lots of headwinds, mainly that QR codes were hard to figure out because they weren't pre-installed on phones, the scanners. So, yeah, before that, I bought a coffee company. I loved coffee. I basically built 100% Arabica ethical coffee company in my local area because the coffee quality back in those days was not very good. There's loads of great coffee shops. Coffee's become big in the UK, but back then it wasn't. So, I built my first company, it's actually a coffee company, not a tech company.

How you transitioned from a coffee company to a tech company?

I mean, I'd always built software on the side, back to when I was like 15 years old or something. agency, or it wasn't an agency, it was me as a 15-year-old, but I was building websites for people locally in my local village, building CMS platforms, e-commerce sites, and that kind of stuff. And so, I'd always had a bit of a tech kind of interest, I would say. And then building Kogo Coffee, it was called, this coffee company, I realized how hard it is to scale. Every single new location you want, you have to get new premises, essentially. Shipping We literally had container loads, like large shipping containers of coffee cups and coffee coming over from different places in the world. So much logistical stuff you have to arrange. It made me realize the massive advantages of software. You build from anywhere in a small room or an office, and then you can scale it globally. But there are other challenges for software, is that it's much easier to— well, you're basically competing with the world. Whereas with coffee, you're only competing with people in your— whoever can walk in the radius of people where they can walk or drive to your coffee shop. But on balance, the advantages of software were well known to me because I had been in that, playing with software for a while. And, you know, they were much more attractive to run a business in. So, I quickly exited coffee. I sold my coffee company to another coffee company in the local area and spent the rest of my career focused on software.

Nice. And if you're thinking back in like how you started building tech products, I'm curious, like kind of what are the team setups or when you started to bring in people, what kind of people you started to bring in, kind of what were the setups back then?

Yeah.

So even now with GitLab, probably it evolved, I assume, right? As the businesses and your knowledge changed along the years.

Yeah. So typically I've always built sort of an MVP myself, although that's not always true. But typically I'm able to do the design work and the product work. and some of the basic technical pieces myself. And then, and sometimes, you know, with a few contractors that I can kind of hire and help along the way as well. And then, as the business starts to get a little bit of momentum, usually the first people that I've brought on board are always, you know, kind of highly skilled technical people. And then, as that kind of setup, you know, I then take the role of designer and product kind of person within that kind of group. And then, as more and more, as it starts to grow, then we start bringing in professional, better designers and, better product managers and better all of this stuff, right? And then I usually end up taking kind of a role of, I guess it's still kind of product leadership ultimately.

So you kind of was then in charge of the product and UX, as you mentioned in the beginning, but you were also in charge of like sales, marketing, and like the rest of it, or given that usually, at least from my experience, usually the CTO takes at one moment the product leader role in a way.

Yeah. I think that's true in the early stages. Yes. I think as I've evolved in my career of like setting businesses up, I do still like to kind of hold on to a lot of that product stuff and be highly involved, because I do think it's kind of like the core of what the business is, is often like the product. The kind of sales and marketing, yes, depending, again, depending what the business is and how much sales and marketing is needed in that particular business, yes, I'm usually ultimately in charge of that as well, with most of the businesses. They're kind of more product-led growth, not heavy kind of like sales. With Whisk is the exception to that, which is ultimately my biggest business so far. With Whisk, we did sell to some of the biggest companies in the world, some of the biggest grocery retailers like Walmart and Amazon and Tesco and people like that, and biggest recipe publishers. We had half a billion users on the platform across all our integrations. And that didn't come from our people coming to our website. It came from people going to like other people's website and then using our experience within their websites. So like that all came through sales. Basically, that kind of like big enterprise sales and partnerships. And there was quite a bit of sales involved in that. And yeah, ultimately, I was doing that and leading that.

Okay. And like you mentioned the MVP, that basically you build the MVP yourself. I'm curious how you end up in a way figuring out what needs to be built, what's inside of the MVP like this. That's the place I assume a lot of founders kind of think it's easy, but it's not that easy because you have a lot of like limited resources, time, people, whatever, money. And you have to figure out what you actually put inside of the MVP that brings value for your customers. So kind of How you figure out what you put inside of the MVP, and then what you leave out, and where you focus your attention and resources, those limited resources that you have in the beginning.

So I think it's a mixture of very early on, it's a lot of vision, you know, it's kind of instinct, I guess. But then quite quickly, you move to kind of user-led insights, right? So a lot of user research, talking to users, or doing surveys or looking at competitors and basically trying to understand what do the users want? I can tell myself, or what can be inferred that users want based on what's in the market already and what kind of standards there are in the space? And then it's basically kind of like, I guess that's part of the challenge as a founder is trying to find the, where do I fit in this market when there are so many other players that are also solving these problems for a user? Is there truly a business in what I'm trying to do? I think there's probably no good alternative to just doing lots of user research and speaking to lots of users. That's ultimately the source. I think today the process looks very different to what it used to. It's now much easier and faster because of AI. A lot of the kind of the user interviews or the user research can just be loaded in as, like, context to an LLM, and you can kind of parse through it. Ultimately, you do still need, I think, a human to spend the time to analyze it. And think independently of AI and then compare to what AI came up with. But that process used to take a long time to do the user research and parse it and turn it into product. Today, you can do that sometimes within like 48 hours, because you can automate the user interviews, you can automate the data aggregation and analysis and turning it into insights. So yeah, it's the fundamental process is the same. It's just now much faster than it used to be.

Yeah, that's right. One question that I usually got from founders when I mentor them is like, how many people you should talk to? I would rephrase that into when you know or when you have that conviction that you can move to the next step.

I think it depends on what you're trying to build. And like, it depends on how truly unique or different or how much validation is there behind your thesis or your hypothesis. So typically, I would minimum of maybe 20, ideally Be more like 50 or maybe 100. In some cases, I've done hundreds. I think it depends on how high quality that— I think it depends on what kind of interview you're doing or what kind of collection you're doing. If you're speaking to users on a video, you start to see the same pattern. And after a while, you almost can predict what each user is going to say. And at that point, I think you probably feel like you understand the user requirements relatively well because you're seeing the same thing again and again and again, and you kind of understand, okay, I understand the customer fine. And obviously, you want to ideally in that process have some ranking so you can understand what In what order? Once you start to see a pattern, you're like, okay, I'm in a good place. I can make some decisions on this. You know, there are— with a survey structure, you can do that. There's some platforms where you can hire people to do your surveys, and you can literally design the survey, click go, and then 24 hours later you have all the results.

Yeah.

It's not as good as like video interviews. So I think it depends, like, how much does it cost in your time? If you're doing 1-hour interviews with people, That's really expensive in all measurements of money and time. If you're doing a survey, it's way cheaper. So it depends. It all comes down to, like, what's the— with everything, it's like, what are my different hypotheses? What conviction? What data backs them up? Are they my gut instinct or are they proven? And then the ones that are gut instinct and unproven, validate. And then depending on how— also, how critical is it? How reversible is the thing that I'm deciding? If it's really fundamental, the bar for how much research you need is way higher than something that's minor and can be reversed very easily. So, it always comes down to those axes for me.

So, you're doing kind of almost like an assumption mapping kind of exercise?

Yes. Okay.

Yeah.

So, internally, what we do is we have different flows that each of our ideas, product feature requirements go through, which is they go from discovery, which is like, I'm just figuring out what was here. Then concept seed, which is the really short form, maybe size of an A4 or something or less, just the high level, what is the idea for this thing? And that usually maps out the different assumptions that we're making and whether they're validated or not. And then from there, we maybe do some more research, and then it ultimately turns into a product requirement document, which we then go and deliver. So that's a relatively heavy process because we are now a team of 20 people. And with a team of 20 people, you do need some process. Initially, you don't have to be quite as rigid as that, but I do think you want to still ultimately go through the same kind of process where you're trying to figure out, yeah, what are my assumptions, hypotheses here? Which ones are validated? Which ones are not? And then before you start building too much, try and validate as much as you can. But also, there's a good counter to that nowadays, which is in the last 6 to 12 months, which is you can build stuff much more cheaply. Sometimes it's cheaper just to build and put it in front of the user and see whether the user actually engages. It's a little bit harder to do if you're in a a space which has got sensitivity around the data that you're collecting or using, like in legal, you have to be a little bit more— you can't just throw stuff up and then there's massive security flaws in it or something, right? But ultimately, you can, yeah, what you can vibe code nowadays is pretty incredible and often better than a survey.

True, true. I'm just thinking about, like, yeah, as you mentioned, you can vibe code a lot of stuff nowadays. I'm thinking about how it differentiates when you vibe code for a POC or an MVP versus when you have, like, a somewhat more robust product with more flows and features and so on, how you translate the vibe coding part in a way into a more complex product.

So I think, I mean, ultimately you can, if you, it depends what platform you're using to vibe code, right? But like even the leading platforms, the biggest platforms with hundreds of engineers talk about how most of the stuff they write now is vibe coded code. I mean, it's not Lovable or Bolt or Replit or one of those, v0, which are all great for individual entrepreneur vibe coding something, but they're more like Claude Code or Codex or something similar where it's a little bit more technical, but you can provide so much more context, right? With a Lovable type experience, it's more like ChatGPT and you're just typing in a prompt and it gives you some— it builds an experience for you, which is super rewarding. But with Claude Code or Codex or similar, you write all the context of your company in Markdown files as context of process, sometimes referred to as spec-driven development, which we use. So, I have this, I have this, and basically the way I work as an individual is VS Code, which is basically just a viewer for Markdown files or files, in this context, Markdown files, loads of folders with all the different contexts that I might need. like, you know, the company mission and vision and differentiation and value proposition, and then, like, all the specs for all the different parts of our platform, some of the, like, legal things we have to keep in mind. And then we basically have skills that the AI uses that just knows when to look at different parts of our context. So, if they're building a new feature, look at this and this, and look at this part, this file, and this file, and then, you know, make sure you look and check that we're not breaking any legal laws for this. And then the quality of the code that it writes is incredible. Yes, an engineer could do it without Claude Code or without Codex, But it would take them so much longer. You'd probably have to have loads of meetings. Going back, like, you know, a couple of years ago when I was running Samsung Food, well, Whisk, which became Samsung Food, you know, we had a team of 120 people there. And like, it would take ages to do these things because an engineer would write the software specs, but then you'd have to go through legal to check that it passes the legal, the right privacy settings and GDPR and all this stuff. And it would take a long time, right? All the release process would take a long time. Whereas now you can actually kind of almost bake all that in straight into the initial version of the code and how it's actually implemented. And the agent can remind you of different things you have to keep in mind. So the whole process has changed. It's way, way, way faster. And I think vibe coding is a very broad term.

Mm-hmm.

For individual founders, it's Lovable or Replit or Bolt or v0. For bigger teams, it's basically the set. It's not quite as fast because you've got a lot more kind of stuff to keep in mind, but basically it's the same. But in VS Code or directly in core code.

Moving a bit back to the MVP stage, I'm really curious to understand when you were thinking that, or when you have that feeling that you're onto something and you are in a way closer to that product-market fit that every founder is looking for.

I think you can kind of feel it. So, I mean, it's interesting. The point at which it happens, there's different feelings. The first feeling is you're an individual. in your bedroom, thinking of an idea, right? And maybe you've built a first version of something, and you start to show a few people, and they're like, wow, this is great. Most people that you know will tell you that it's great, even though it might not be, because they want to make you feel happy. And no one wants to tell you that your idea is bad. And by the way, after selling Whisk to Samsung, I also became an investor. I've invested in, I don't know, 30 startups or something. And it's the same feeling as an investor. If someone comes to you and says, got this idea, do you want to invest? It's much easier to go, I love the idea, but I'm just not investing right now, because it makes you feel good, makes them feel good, everyone feels good, right? But it's not valuable. But I have experimented myself with giving negative feedback, and you give negative feedback and go, oh, actually, I don't think it'll work for this and this and this and this. And the person doesn't leave thinking, oh, thank you so much for being honest. They pretend— some of them pretend, or some people do genuinely, but it's quite rare. Usually it's a feeling of like, I hate you now because you told me that my baby is ugly. So like, it's Of course, people in your circle will generally give you positive feedback, right? So, it's important to go to people that are not in your circle or don't know that this is related to you, or people who are super honest, which you might be lucky enough to have in your peers. So, test it in a way that is meaningful. And if you start to see that there is real interest, genuine interest in what you plan to build, continue investing. But the true product-market fit For Wisk came much later. So we had various stages of product market fit in Wisk. We founded it in 2012. We had sort of bumps of product market fit until 2016, 2017, but no true product market fit. The true, and again, even what is product market fit? Even at 2016, 2017, it didn't— is half a billion users significant? You could argue it's not, right? It was for us, but like, is it? We were profitable. We had 30 people. We were growing really, really fast. But is it, is that enough? We weren't Instagram. We weren't, you know, we weren't like a huge company, right? So like, what, what is meaningful is another question. But for the Wist story, it was sudden. We suddenly hit product market fit about 2017. And then within a year, we went from 2 people to 30 people, from, from not profitable to profitable. 3 different large companies like Samsung came to us. We didn't go to them asking to buy our company. We agreed to sell it to one of them and we sold it to Samsung. But it's all happened within a year. So that's what product-market fit feels like. True product-market fit is suddenly everything is exploding, money is no longer a problem, and people want to buy you, and it's way more fun to run a company like that. The first bit took us 5 years, and there were loads of moments of some market fit in those 5 years, but it wasn't true product-market fit where it suddenly gets really, really gross. So I think it's all— the product-market fit term is often defined as that second, the bit where you are suddenly on the hockey stick to Instagram. Kind of growth happens very, very rarely. Very, very few founders truly experience that. Most founders, it's much more of a slow kind of like hard journey of growth.

And like along this product-market fit triplets, how things evolved on the product side and like the team side, processes and stuff like that?

I mean, it changed drastically because we were on the Whisk side. We were first a B2C product, then we became B2B2C, and then we became B2B. And that requires different skill sets on the growth and marketing side and sales side. So, like, totally different skills. On engineering, we had initially 20 people, we went down to 2, and then we went back up to 30. So, like, we were, you know, and in the middle of that, it wasn't like, you know, 2 big changes. It was like, cut, cut, cut, cut, cut, cut, grow. So, like, it, and that's painful. Like, it's easy to talk about now, but at the time, it's like literally people crying when you tell them they haven't got a job. And that's, I would say, happens more than half the time. So, you basically, every few months, you've got, Let someone else go because you haven't got enough money, and people are crying. And it's like genuine emotional hurt, not having product-market fit and going through these iterations. Ultimately, once you have that right, once you find the fit, once there are real customers pulling at you because they want more of your product, and they want to pay you more money, that's very— it's much easier, much more fun. And that's when you have a real business. But I don't think that many people actually get to that point. It's quite hard to get to.

Why do you think they don't get to that point? That's one question. But first, I would like to follow up on the people crying because obviously it's not easy to let people go. How do you navigate as a founder all the challenges? Because it's not one or two, it can be like months or years where it's quite challenging. And sometimes, I don't know, I assume you kind of feel alone. It's not a lot of people that you can talk with about this kind of stuff.

It's hard. I mean, the things that help I always had investors and board members who were supportive, so helped me, mentored and coached me through this stuff. And they've got an interest as well in helping it work, right? The other part is if you're lucky enough to have a good personal life, a personal life where you have people supporting you. I have a wife who's very supportive, and she has always understood that there are challenges in what I do and has always been there for me. And that's been massively helpful as well. I think it's harder if you don't have a personal life as well, and it's— the business is the only thing you have. It's also— that brings its own challenges if you have a personal life, because then you don't have as much time to dedicate to the business. But there's pros and cons. But in general, I think having that support network has been helpful to me. In terms of, like, how do you keep going? I think the hardest question is always, is this the right thing for me to be spending my time on? Like, do I believe I can get it to the next step? Or not? Because if you don't, then you shouldn't waste your time on a lower-than-market salary. You should just get a job, or you should build something, build a new startup, right? And those are always, I think, when things aren't going well, those are always the questions that you're kind of grappling with. Ultimately, I have personally got higher— one of the— I haven't got that many strengths, but the 2 strengths I have is I think I am able to find good people to join the business. And that's always been something that I've benefited from. People that are smarter than me or who are really specialized in their fields. The second thing is grit and not giving up. So sticking with an idea longer than other people do. And for me, that's worked out because the ideas that I've stuck with have ultimately become successful in the end, longer than people thought they would take, but they did eventually become successful. So there is like, and a lot of entrepreneurs talk about this, like the importance of grit, sticking things through when things don't look likely to succeed, but you still push through. And it's like this whole momentum thing, you know, the momentum of like this flywheel, where if you look at a flywheel, you know, at the beginning it goes very, very slowly, but because it kind of stores the momentum and keeps going, and then it goes faster and faster. And people initially, it's going slowly, and I think people always underestimate how hard it is to get even that level of momentum that they've got. And then if they keep going, the momentum speeds up and it speeds up, and it feels slow initially, and then suddenly you're going really, really fast. Grit is like determination is definitely has been something that I've benefited from when, and is the reason why ultimately Whisk was successful. 5 years of pain and then eventually success.

Okay. As a product designer, I'm very curious about first when you decide to bring in a designer or a product designer and how you do the transition of like you doing product and design to somebody else executing in a way your vision for the product.

Yeah. You have to find someone, I think, that's able to bring their own style and thinking to the table, but that doesn't misalign. It's a really hard job, actually, for the person coming in, and also for the founder, I think, passing over, because you don't want to micromanage people. So you want them to be independently able to do the job, but at the same time, it has to be more or less aligned to your vision. And if it's— then, because design can have a very big impact on The direction of the product, because they could design a feature very differently, depending on how they interpret it, or what they believe is important. Yeah, hiring, being closely aligned with the person or team, regularly meeting them, having the right structure to kind of, like, work with them, regular design, in my case, regular design reviews, being super aligned on specs, super aligned on what we're building, being super aligned on the vision and the mission, so that we're aligned right from the top all the way down. All that stuff is important, but ultimately finding good people is super important. And if you don't find the right people, then you will fail. And what's right is different for every person, right? Because everyone has slightly different styles.

And when it comes to these assumptions that you mentioned in the beginning, or if you want, bets that you put on the product, besides the fact that you can actually end up with a winning product or business in the end, while building these companies, were there any moments that you felt that You have to either put a big bet down on something, on a new feature, a new product direction, or pivoting the business and so on. And if yes, kind of how you navigate those stuff.

Yeah. So multiple times, I mean, you know, with Gitlaw, it was the decision of going AI first instead of Git first, essentially. And with Wisk, it was multiple pivots, B2C to B2B2C to B2B. So, In each of those moments, I think you kind of— usually there is, like, some momentum behind the shift. It doesn't come out of the blue. It's not like I wake up one day and decide that that's a good idea. It's like there is— we've had requests come in from clients or the huge amount of, like, data from the market of what's popular and not popular or where it's going. So, usually there is a lot of, like, signal. So, it's not like it's wake— it's not like a non-obvious thing where you have to wake up and think, shall I pivot the business or not?

Mm-hmm.

It's like you're seeing a lot of signal, whether it's from your Or investors or the media or whatever it is, or your own personal experience. I think in AI, what's become super clear to me is my own way of working has totally changed. I wasn't working with AI 3 years ago, 2 years ago, right? I mean, you could argue some of the stuff we were doing with AI, but like, by the way, Wisk was behind the scenes an AI-first company. We were doing like natural language processing using stuff that existed before TensorFlow and other The early, early kind of like deep learning models were easy to use. We were doing stuff before then using natural language processing. So we were like, we were deep in AI, but it wasn't part of like my working process. And then along come the LLMs, and my own process has totally changed. I now spend about 30% of my time in AI. In addition to this chat window I have open here, I have got VS Code and a bunch of— called Code Terminal, and it's not active right now, but like, that's what I'm doing when I'm not talking to you. I mean, I'm in there working with LLMs. So, like, totally changes the world. And then you kind of, if you're seeing enough of that, my own experience, plus everyone around me is all changing how they work, you've gotta think, how does this impact my product? It's not that I wake up one day and go, ooh, let's do more AI. It's like, the whole world is changing. How do we work in this new world? What are the opportunities? And then you start to, like, build a product that, or your product slowly evolves. And then obviously, how do you actually do it? Well, speak to your key people in your team, make sure your team, usually these ideas aren't just coming out of me. The whole team is saying these things, right? Everyone is kind of saying the same kind of thing, and the kind of consensus is building. And then, yeah, you take a decision to migrate across. And while from the outside, it might look like a huge pivot, from internally, it's actually just incremental. It might be quite quick incremental, but it's usually, in my experience, quite incremental.

Okay. So, it's kind of similar if you're thinking about, like, building a new feature, let's put it That's like a smaller bet in a way. It's kind of the same path. So you see what are coming from your customers, what your team maybe is talking about and what they bring up. And then somebody in the end has to make the call of building it or not building it.

Yep, exactly. It's like basically each pivot, you know, from the outside is actually probably like 100 small feature decisions. And those 100 small feature decisions are in your exact same process that they usually are. And you can slowly start to see those happen. And then usually at some point you go, from a marketing perspective, you go, hang on, we should probably reposition our company because we've changed so much under the hood, in the core of our product, it's changed so much, actually, it makes sense for us to kind of call this something different. That's not always the case, right? There are companies that totally change pivot in a different way.

Mm-hmm.

And they do just sort of stop working on one product and everyone starts working on a different product. That happens too. Those ones, that's not the ones I'm talking about. I'm talking more about when the same product Makes sense.

Okay. And I have a couple more questions before like the closing stage. If you're thinking about like blind spots and lessons, was there a product UX issue that slipped somehow under the radar until later while building, making these changes, growing your team, and so on?

I think with Git Law, not yet. We're relatively early in it. And we've also, the team that's building it is the same team that's built 2 products together before. So we've got a lot of experience building products together.

Mm-hmm.

But, like, with Wisk, certainly, there were times, mainly, I would say, big features we had built in our legacy past that were still in the main product that we were having to, like, support. Always, there are those big architectural decisions of, like, do we remove this big wholesale feature that we built 3 years ago that we thought was important? Or do we leave it in there? Because it's actually easier short-term to leave it in there. And there are so many of those decisions where you decide to leave it in there because it's more work to remove, but it has this long-term legacy issue, and it causes you lots of problems. And this is like, is there a right decision on what to do in these? It's so hard. I mean, there were so many examples of those. I remember we had, like, in Whisk, we had this idea of communities, where, like, communities would be hundreds or thousands of people coming together to curate recipes together in, like, in groups. And it didn't truly work in the way that we envisaged. There was creators collecting their groups of recipes, but there wasn't ever thousands of people collaborating on a theme and successfully doing that in our product. But it's still, I think it's still in there now, if you go in the app, that feature's still there, because it was so much work to remove, so people just left it in there. So there are so many good examples where, yeah, was it the right decision to leave those janky Legacy things there or not? I don't know because I've also read there's a taxi hailing service called Halo in London who were ahead of Uber, right? And from what I understood, I'm not sure this is sort of gossip or not. This is true, but they tried to replatform the whole thing into a whole new technology stack to kind of basically solve some of the legacy issues they had had, and they lost a year. So like this kind of stuff happens where. You can lose time, you can lose 6 months or a year if you're a big company, and you try and solve some of this stuff. So, what's right? Is it right to invest in solving those things, or is it right to just carry on and ignore the issues? In general, I would say, carry on, ignore the issues. But today, with vibecoding, like, you can just point, you know, it becomes, the cost of technology is lower, so maybe you don't have to live with those problems as much as you used to.

Okay. And, like, if you're thinking on the flip side, were there any, like, small increments, changes that you've done that ended up having a much bigger impact than you expected?

Massive ones. Yeah, absolutely. So, like, the simplest example is changing the color of buttons. Like, you know, sometimes a whole feature, which takes you months, has the same impact as just changing the color of a button from, like, green to blue or something. Like, I remember we literally, in Whisk, we had this button to add something to a shopping list. I can't remember what color it was. I think we changed it to green. It literally doubled the CTR, which means we had double the amount of people coming through it. And then we like— so small things like that have huge impact and super easy. Like, it's super easy to test as well, right? You just change the color or A/B test the color. So the learning is like, I think, try— and we don't live all these learnings, by the way. It's very easy to share learnings. It's harder to actually make them work.

Yeah.

But like, the lesson is test so many things at once. Test many, many things. Small tests are fine. Landing page copy, button colors, images, positions of stuff. Test stuff and learn and iterate fast. It is quite hard to actually do. It's very easy to say. It's very easy to point to tools that do it easily for you, right? There's loads of tools that do it easily for you. But to actually implement, to actually release those quick experiments fast is actually quite hard as well. We are, if you go to our Git lore, website, you will see that if you go to a bunch of anonymous tabs, as in where there's no cookies set, you will see different designs and different text. We are living that to some extent, but we could be living it more. It's a lesson that's hard to do, easy to say, but every time we've done it, lots of ROI in testing.

Why do you think it's hard to actually do it? Or Where do you see that there is the bottleneck in this whole process?

Well, I think you have to have good tooling to be able to do it fast everywhere. On the homepage, it's quite easy, but to do it in product, you have to have feature flags. The people in your team have to be thinking in that way as well, have to be basically pushing stuff up and launching automatically with feature flags and looking at the data. That requires a culture and a philosophy of, or a way of working for the team. And it's not natural. Like, it doesn't— it's not what most people think about first. What people think about most is usually, what's the big new, big rock feature that we should be building? That's usually where people center. But actually, there's a huge amount of value in iterating and testing on those, like, other parts. So, yeah, it's not natural, I don't think, as humans to do it. At least not to many people. Some people, to some people, it is natural. And if you find those people, send them to me because I want to hire them.

Okay. No, in the closing, if you would give some advice to some like other founders that are going through these changes and building and iterating, testing out stuff, going through those painful moments when they have to fire people, basically putting this whole thing together, what kind of advice you would give to other founders, both as a founder and maybe as an investor?

I think it's really helpful to be like confident and well-researched in your mission and vision. If you're building something that you care about, and that fundamentally works and achieves your goals, whether that is making money, or making the world a better place, or solving a personal problem that you have, or whatever it is, if you have a mission and vision that feels important and valuable, then I think it's much easier to go through all those all that pain because you're doing it for a good reason. That's why I think as well, if there's a real founder-problem fit, it doesn't have to— I'm building a legal platform. I'm not a lawyer. You could argue that's not a founder fit. But actually, I think it really is because I experienced a problem and actually I'm trying to help other businesses scale and be successful. So I really can identify with the problem. And actually, I have experience building, I think, good experiences, which I think, again, will help me. It's a really, really important attribute in this. And it actually is the rare one, not being a lawyer. Being a lawyer is relatively— there's relatively quite a few of those. So, like, having— if you know that you're building something that's important, then it's so much easier to get through the pain. And also, it's much easier to explain to people when you have to let them go, or when, you know, for any other reason, why that has to happen. And to the team who stay, because, like, hey, we're doing this so that we can achieve this mission and vision. And if the mission and vision is important, and people understand that, then everyone can understand and go, yep, that makes sense. They might not agree with your decision to let them go, but they're like, okay, I get it. Like, they're trying to make this goal happen, and this has to— they believe this has to happen in order to get there. If you don't have a clear mission and vision that people kind of, like, identify with, and feel confident in, then that's much, much harder.

Do you have a process of setting those and eventually communicating it to the team? Because from what I noticed, these are like 2 different aspects of it. I actually know yourself being very clear about the mission and the vision. And the other one is like putting that in front of your team and making them in a way aware of what and why you are building.

I think that most people will like be able to come up with something themselves, right? And nowadays chat to Claude and ChatGPT and whatever about it too. To refine it, definitely ask ChatGPT and Claude to tell you why it's bad, why it's not clear, because they will— it'll give you, like, if you ask it those negative prompts, it always wants to satisfy the prompt, right? So it will find things that are bad, and then some of those are good pieces of advice and some of them are not, and then you can iterate quite quickly. So you can iterate on it like that initially, then go and pitch it to people, pitch it to investors, to mentors, to friends, and get them to give you feedback. And that will also help you because then you're like, that's probably the best, to be honest. That's, for me, that second one is the one I've done most of, which is pitch it to people and then, based on their feedback, improve. And what I also notice, the more I speak through an idea, the more it kind of actually crystallizes in my brain. And often they come up with ideas, they ask questions, they're like, oh, does it do this? And you're like, yeah, it does. But the fact that I didn't understand that initially, let me put that in. Or, no, it doesn't for these reasons. You clearly don't understand the fundamentals of what I'm trying to build. And then, again, you can iterate on your deck. So, especially if you speak to smart people, and there are actually, I think, a lot of smart people in the investment community. A lot of the VCs, they're very smart people, and they see lots and lots of businesses. They understand the field well. So feedback from VCs, investors, angel investors, I find really helpful. And that's definitely been a way to iterate on that mission and vision. And then, of course, the important thing is also to communicate it well to your team. And that requires some discipline. Like, to remember to repeat your mission and vision regularly. And even just talking to you right now was a good reminder for me that I should probably go tomorrow and tell my team again what the mission and vision is, because you should repeat it regularly, right? And I probably haven't done it for a month or two. So, like, it's just, like, reminding yourself, like, make sure the team understands what we're trying to build, why we're trying to build it, how it's important, and also how they benefit if you're successful. So, one of the things that I'm trying to talk about a bit more in my team is the importance of using AI to make us To speed us up, right? And for the company, it's important to use AI because if we don't, we'll basically be slower than the top 5% of companies who are using AI. And we need to be in the top 5%, right? Or 1% or whatever. And like, if we don't use AI, we will be maybe in the top 10%, but not in the top 5%, right? We have to be at the top. AI usage is important for the company, but it's also really important for the individuals. Because if the individuals do it, then they will have a career. probably for life. If they don't do it, they might be out of work in 2 years because their job might be replaced, right? So it's important to tie it back to the individual. And with the mission and vision, we've given a lot of our team as well shares in the company. So there's also an incentive there of, if the company does well, you also get a payout. And with Wisk in the day, when we did well, a lot of our team members had enough money to pay off all or some of their mortgage, or in some cases, a lot more. People benefit, everyone in the team benefits when the business goes well. So, communicating that, why does it matter for the company and for the mission and vision? Why does it matter for you as an individual as well? It's super important.

Okay. Any future plans that you can share or closing thoughts that you might have, or any other ideas, books, resources that you found useful and might be important or useful for other founders?

I mean, to be honest, I have found AI, it's probably been overcommunicated and boring to people now, but the way that it's changed stuff, It's incredible. I'm not an OpenCLAW user, but there are ways of doing something similar in pure Claude. So, my day is, I spend time— first of all, it's really important to understand how to use Claude Code well, I think, or Codex. Really important to understand how to genuinely use it well and invest the time to make it with all the context and all the skills and everything set up. And you know how Git works, and all those things so that you can collaborate really, really, really well as a team with AI. And then secondly, build it really well into your process. So, you know, you can have scheduled tasks where, kind of, I have a morning brief that automatically looks at what's important in my tasks. How fast do I typically iterate through tasks? Therefore, what should be priority for me today? For each meeting, what's the agenda? What are the follow-ups I should look at? What's the background information about the contact? It's all this information, like, automatic. And every time I ask an AI, it's always got the context of everything about me. And so it's much— I don't have to re-explain. The productivity gain is just massive. If you're— when a founder says, I need to raise money to build an MVP, you're just like, why does your MVP not exist in Lovable? The time of this call of an hour, you could build it in Lovable and show me an example.

Yeah.

And then tell me why it's better than everyone else building a lovable MVP, right? Why are you going to win when anybody can build this in an hour? But that's the conversation that I should be having. And if that's the conversation you're having, then you're on the right track. If your conversation instead is, will you give me half a million to build an MVP? And you're like, well, the images you have, how did you get them? Oh, I got a designer to build them for me. And you're just like, well, okay, so you clearly don't understand where the current situation is with AI and where the world's going. Because, like, So I think you have to be AI-first as a company, as an individual. I think if you don't, I think your company will probably fail. And I think you as an individual will unfortunately be out of work in a matter of years, which is really sad and really scary. But I think I personally believe it's true.

Awesome. Well, thanks very much for all these insights. It was super helpful and insightful for me as well. And yeah, good luck with what you're building at Gitlaw and the other stuff that you have on your roadmap.

Thank you very much. I'm excited.

Thanks. Bye.