Building SAAS in 2025 Against The AI Heavyweights

If you build a system to work one way and hyperfocus on making things, the system that you build the product that you design will end up much more fragile for it. It'll always be much easier, more simple to design something with one clearly defined path of the way the user should go. However, in most cases, users don't ever operate and work on a system in the same way. We built software that serviced thousands of agencies. Uh this is pre-content space, so we're not talking normal agencies. We're talking real estate agencies. And they all had very different ways of working. Um every single office had a different process, even within the same brand. They all like to do things certain ways. They like to do it the way they've always done it. Change is hard. Adapting to change is hard. That increases friction of onboarding users. But if you go down a path where you build everything that people ask for to do it exactly the way that they ask for it without considering if there's a better way that can work without too much change or you can build something in a flexible enough way that they can work within it without you having built exactly what they need which is good for no one else. Does that make sense? essentially to build a business that's going to survive what's happening right now which is the takeover of AI tools the takeover of vibe coding the shortened time horizon in which like someone can copy an app so it used to take weeks months years to spool up a competing product to something else these days it could happen in minutes if it's a simple product it could happen in weeks if it's a more complex product and if you do a lot of the work and the thinking for that other business that wants to copy you. You've you've essentially just handed them on a silver platter the road map of how to build what you're building and that is not sustainable long term. It's not going to be easy to sustain long-term businesses in that landscape. I think one of the key things that you can do and probably should be doing if you're designing a business or software is to build optionality into it. So Nasim Taleb said in a strategy that entails optionality, you don't have to be right that often. You just the mere fact that you have more to gain than to lose in each bet that you make is sufficient. People always talk a lot about robustness in product design and product management and system design. Um and usually when they talk about robustness, they're asking is the system reliable? Is it going to stay up? If you get a whole bunch of traffic overnight, is it tested? Can it handle traffic? But robustness, that sort of robustness is just going to absorb shocks. That's essentially a shock absorber of your business. It's going to when you take a hit, you bounce back up again. Uh and it's a defensive struct like it's a defensive structure and it is a strategy that you have to employ. It's something that you have to do in your business. You have to be defensible in that level of robustness. But but what you're really after is a system that doesn't just take those hits. it can adapt and evolve and sometimes hopefully use the hits, the changes to level up. That's why we think of anti-fragility. The first building block for us and what I think is really important for an anti-fragile business or software product is optionality. What does optionality mean exactly? Well, it's having more than one way to solve a problem. It's making sure you're not boxed in by a single path, a single user path, even a si single business response path. It's the same thing. And you specifically, you want your software product to be able to flex without falling apart. And that is flexing to the way the users use the product, when they use it wrong, what the system does to help them either do it right or do it wrong really well. and then take what they've done when they've done it wrong and make your system better because of it. And then you've got this you get like an unsurmountable network effect where if you're flexible enough to allow people to use things in ways you didn't expect, you will see the ways that they use it be surprised and be able to capitalize on that really fast if you stay agile and flexible. And then you'll be looking at a system that can flex, it can adapt, it can adjust without falling apart. So thinking in the terms of our user content teams, some days you might want to work top down. You might want to go from having a brief having uh having a brief, writing an outline, shooting it, editing it, publishing it, go through the exact process, step, step. other days which like this this is the one that happens to me more often than not is like I'll just get a spurt of inspiration want to make something talk about something and I don't want to have to go through the entire process that I'd normally go through and that might be like finding a specific point in a video you've already put up there and wanting to clip it and reframe it in some way remixing something old, reusing something, repackaging something and you just want to skip ahead to like you might want to skip and just record, publish. You don't want to do any of the other stuff. You don't want to write anything. You just want to get the video up and get the publish out. And that is entirely well and good to just do just do yourself if you're by yourself. If you are just one person doing it, obviously there's no problem with just doing that. Just making something, chucking it up there, great. But if you start working with a team, if you have producers, if you have editors, if you have um researchers, strategists that need to go back and look at how things performed, how they were built, where they came from. Essentially, you need like a really good paper trail to manage this content business, then if you haven't put it through the same system, you're going to encounter issues time and again, you're going to see that, oh, that that was just an ad hoc one. That was one time, and I don't need to worry about that. And the thing is the the desire to skip the systems and skip the processes is always going to be incredibly strong. People are always going to want to do it. Uh because friction and effort like you want to reduce that as much as possible. Now if our software or your software in this case only supports one workflow. You've got to think about your product isn't something that people really want to use. They want to get a job done. They want to get it done as fast as possible. And if they can get it faster without using anything, even though long-term that might be bad for them, they'll probably revert to that if there's too much friction to do it. So if our software only supported the one workflow and you had to go through and create project and it was difficult to create project and you had to go through a bunch of checks and balances and tick a whole bunch of things, set everything up, right? People would just not use it. And then the value of having everything in one place is going to fall apart really fast. And then you'll have people like fighting the fighting the system or not using the system which is not good for anybody. And if you've if your software only supports that one workflow, you've turned it into a source of friction. You're not going to have good user adoption. But what we design for and what I think everyone should really be designing for is optionality. So you want to have clear defaults, clear paths. You want to have an opinion on what the path of the user should be, but you need to give them clear, viable alternatives. And you want to give them room to maneuver and do the wrong things slightly outside of this picture you've got in your head of what exactly how the user wants to work because you're almost always going to be wrong about that anyway. And that freedom and room to maneuver is going to be everything when things go sideways for your user. And it can mean the difference between them staying a user or abandoning you entirely. So optionality and putting it into your system is it's essentially going to be a bet that you make that having rigid control is not as good as having adaptive range. And adaptive range is you work within the things that the user wants to do as opposed to telling the user how they're supposed to do something. And a lot of systems these days seem to just tell you that you have to do something in a certain way. You have to go edit this here. you have to go through this step to reach this part. I think and realistically one of the reasons that that's been so prevalent for so long is it costs a lot to build. It's always cost a lot to build software and it's always been difficult to ensure a good user experience if you have many paths to do the same thing. Whereas much easier if you force everyone down the same path. You can make sure this button always works, the state of it always works, all of these things as technology gets more flexible, products will get more flexible because more people will be building things in more ways and more people will expect the latest and greatest in every piece of software where you're going to have to get more comfortable with optionality. Even though it means you can't necessarily write the best user docs all the time. You can't necessarily always guide people through the perfect step or use a wizard setup which tick tick tick tick tick and tells you exactly where everything is and how to do it because there is a future where UI takes a backseat to what the product is doing and trying to help users do. And that might look like you just talk to AI. Personally, I believe that there's always going to be want to be a desire to look at something visually see it on a screen, but also like components of your UI might get pulled into chat LLMs as well. So, imagine a future where there isn't much UI or people don't go into the UI much or maybe one type of user who is a component of a team who needs your product goes into the system, everyone else interacts with it just by asking an LLM questions. It's entirely possible in those cases. The system has to have optionality built in because you will never know not only the way someone will ask a question and the way someone will ask for something to be done, but generative AI being non-deterministic, you don't know if they're actually going to send you the message of how what they want to do in the system the right way. If you don't have the flexibility and the breathing room or the bumpers around like what success looks like for the user, all of the ways they can achieve it, you're just not going to be able to build a resilient system, one that can survive through this. So an example in Clipflow is we don't force content must flow this way by any specific model. This is something we learned building the last software we built is you have to give people multiple paths and in a lot of cases it means more work because it means um oh I want them to be able to edit it from here but if they first come into a list page over here I want them to be able to edit it and then I need to be able to show this over here this over here this over here and it gets real spaghetti western complex gets really difficult to implement um because there's so much variability and it also gets hard to make like good decisions because you're Um, I don't know if we need to show that here. Don't know if we need to show that here. You've got to constantly be making decisions. And it's not as easy to clone stamp the development process because there is critical thinking that's needed. So, you can't necessarily just rely on having like people who aren't that familiar with the whole system to build stuff, which can get quite complicated, which can make things a bit harder because you have to train people up more. You have to explain things way more. the system might um they might add a feature in and just completely miss that there's a complete other path that they have to go through that they can go through to get to this same thing. You've got to make sure your models are creating things in a safe way that it isn't just happening in one page. It's all sort of extrapolated out in a really healthy way for this adaptable system anyway. So, we've got creators who would like maybe batch record content on a Friday. We've got people who come in and write on a Tuesday. We've got people who come in a little bit every day and do little bits and pieces. Some people just do some AI clips and run it through it. Some agencies run their entire business through it where they've got like hundreds of shorts going out every week. There's not one single way to get from nothing to a video being made and published out there. And I don't think there ever will be. Everyone is going to have a different way of doing it. All you have to do is watch YouTube to and like analyze what the videos are to realize just how different all of these videos are. You might have people who just set out, they go out in the morning and they record themselves talking while they walk. That's probably 15 minutes of recording and whether or not they edit it is questionable. They may even upload it straight from their phone. They never touch anything else. Then you'll have people who will shoot something that takes three years to do, like say a car restoration that takes three years and they're filming daily bits and pieces and they're putting it all into one video or they're making weekly videos, whatever it might be. And then you've got the more like sort of business-minded creators who are creating maybe just educational pieces and they need weekly educational pieces and they have a someone to write and research for them and then they just come in and shoot and then they hand off the media to get edited by someone or they have a team come in and film it. Um and then someone else entirely repurposes all of the long stuff into short form. These are all perfectly acceptable paths to make really great content. And a system with really rigid control about how you have to create is never going to work in this landscape. Personally, I don't think so. And so, we need to make sure that every path the user might take feels coherent. Anything we do, we try and make sure that it works in a way that is familiar no matter what path you come from. So we can't rely on a user first landing on an empty project for example and show them a blank state because there are plenty of cases where a new user might come in and only come into already completed like already filled in project. So if you relied on a user walk through on the splash page of first coming into a project, they might never see it because they might never come into an empty project and you might not be able to do that same welcoming onboarding with a complete like halfway through project. Everything you explain might not be relevant to them because you have people in very different roles. And like I said, there are positives and negatives to doing this. It can make it much more difficult to build. It can make it more difficult for the users. Like it can increase friction where people need things explained to him. But it's kind of nice because then you get forced to um make what you're building clear enough without any instruction like if you really fight for that that can have a good net benefit to the entire product. So we have essentially traded the rigid control for a really high range high adaptive range. And one of the things that I think one of the things that I think is really important and everyone needs to think of is that as the market shifts, technology shifts, competition moves around, the way people make things changes and people start using your product wrong. the range and adaptability becomes the superpower of the system because we can not only let people do things in the way that they want to do them, but we can see people doing things in different ways that we weren't aware of that we didn't even know would be a good idea. Realize that we need to find a better way of ingesting that into the system and then rising tide lifts all ships. Everyone in the system gets the benefits of what the best performers are doing as well. And by the end of the day, you didn't build a system that was perfect in any way whatsoever, but you built one that can't die easily. It is adaptable. It is usable for everyone. And it's very hard to kill something that is that adaptable. And that ingrained in people's workflows. So the idea is you have an asymmetric upside to this optionality. The optionality gives you this asymmetric upside where the the benefits are potentially limitless because say for example someone does something in the system you weren't expecting and it has ridiculous outsiz results for the work that they did. You you integrate the similar concepts into the system and they're worth a hell of a lot of money. You could you could find products by being this adaptable. You can find products you didn't know existed that you can sell into the market and make tons of money from it because it can be a really high value thing that all you have to do is do what you're good at, which is make the system work for that flow and then package it, sell it as this is a thing that you can do. It costs this much money because it's worth this much money. People will just be beating down your door. And this has come in the system without you having to come up with it. Obviously, you have to do your due diligence. you have to think about if it's right for the vision of the product and everything, but you didn't have to come up with that new way of working. And not only that, but you can see the person who did it and did it really well and you've got a case study of like why this product is going to be so good for everybody. The important thing there is to be watching for the opportunities, keeping an eye on the users, identifying the signals from the right users of what they're doing, and using that to guide what you build. Question for the week. If you're building software, if you're building a product, is is there any way that you're forcing your users down one narrow road when they might need the option to do things in another way? Can you go and offer multiple ways to reach the same outcome? That might be different entry points, different exit points without sacrificing the clarity or the quality of what the the user story, the user journey might be. Is there anywhere that you can make room for this flexibility without creating too much chaos? Even just testing, getting little runs on the board of getting a bit more comfortable of not having complete control over the way the user works um is going to be good practice because you'll get better and better at it over time. And that's the game is just get better at this. And the payoff for introducing optionality if you can find a way to do it in your business is going to be that you don't have to be right all the time. You don't have to get it right. You don't have to say this is the way it's going to be and if it's wrong everything breaks. You just need the system to be able to handle being wrong in the first place. See you next time.