Why Most Surveying Firms Get Technology Selection Completely Wrong | The Surveying Shift Ep. 7

What really costs more, buying software, building it in-house, or sticking with the processes you already know? In this episode of The Surveying Shift, Louis Blaxill is joined by Aiden Flood, Director for Digital Transformation at Turner & Townsend, for a practical conversation on technology selection, digital transformation, and the real trade-offs behind buy versus build decisions in surveying and beyond.

Aiden breaks down how firms should think about workflow fit, hands-on testing, stakeholder buy-in, support costs, speed to market, and total cost of ownership before making a technology decision. From off-the-shelf software and heavy customization to Excel-based tools, vendor lock-in, and AI-driven development, this episode explores what actually makes a solution work in the real world.

If you work in building surveying, proptech, digital operations, or business transformation, this episode offers a grounded look at how to choose technology with more clarity, less hype, and a much better understanding of the risks, costs, and opportunities involved.

Learn more about GoReport

Stay ahead of industry change, explore digital tools, and hear stories from leaders shaping the future of surveying.

📐 New episodes of The Surveying Shift drop every month.
🎧 Listen on Spotify, Apple Podcasts, or your favorite podcast app.

• LinkedIn
• Instagram
• Facebook

If this episode gave you value, please like, comment, and share it with a colleague.

This podcast has been brought to you by APodcastGeek.

Transcript

Coming up...

Aiden Flood 0:00

If you're looking at a technology, hands-on first, it can save so many headaches. Sometimes it's better to buy off the shelf, sometimes it's better to build. Often enterprises, particularly on the scale that I usually work in, come to a sort of middle ground of saying, well, buy off the shelf and then heavily customize.

What tells a firm it is time to buy, build, or stay put?

Louis Blaxill 0:18

The moment that firms typically look at either buying technology, building technology themselves, or continuing with the processes that they have and making them more sophisticated with the tools at hand. And I mean, without wanting to elaborate too much on your camera, that that feels, and from conversations that we've had in the past, that feels like what's being pitched to you all the time. And a good place to start, I suppose, would be, you know, even before you're taking that into consideration. What is it that sparks people to come to you in the organization that you're in at the moment and have been previously? To when is a good time to think, buy, build, carry on as we are?

Aiden Flood 0:58

Yeah, always a topic that comes up across every industry, across every organization. So typically people just come to you with an idea, a concept, and then very quickly across every every organization, the discussion turns into we could just build that ourselves. Someone will come to you with something they've seen on recently. It's TikTok. Like, I've seen this on TikTok. Can we go and buy that? So it's a conversation that comes up a lot, and you have to start just taking a really mutual analysis and say, like, well, what are you actually trying to get after? What is the business benefit? What are the detractors? What's the negatives for the business? You know, what is your base skill? So if you're a Google and someone comes and says, we need a new technology, I would 100% presume you can just build that. I've worked in businesses where you're not a technology company. You are a producer of something. Um, you are a service provider in something else, you're a consultancy, you're not a technology provider. So you've always got to make that balanced decision of do we have the necessary skills to do that? Are the costs going to escalate? And I have to run all that through my mind before giving like a relatively quick answer because everyone always expects an immediate answer of what are we doing? So you have to consider all of those things and then come to a pretty quick considered opinion. And it's not ever one size fits all. Um, sometimes it's better to buy off the shelf, sometimes it's better to build. Often enterprises, uh particularly on the scale that I usually work in, come to a sort of middle ground of saying, well, buy off the shelf and then heavily customize because you're always looking for what's your business advantage versus someone else. When you get down to the small, medium kind of levels, it's gonna, it's a different balance. Well, when you're at the large global internationals, you know, everyone has similar challenges, but then different sets of tools that you can use to get out of the

Is more control worth reshaping your workflow?

Aiden Flood 2:48

problem.

Louis Blaxill 2:48

Yeah, and I suppose that's that's a a reason to consider building, right? And quite often one that comes up in conversation is control or level of control. And I suppose in a in a multinational organization in particular, the ability to wholesale change processes to suit a piece of technology becomes that much more painful. Whereas you could be a little bit more agile if you're in a smaller company and go, right, we'll we'll just change the way that we do that because that's fundamentally the way that the system is set up.

Aiden Flood 3:16

Is that a consideration? That one's a particularly interesting uh one because it can have a bit of nuance in there. People sometimes want to buy a technology that doesn't actually fit your workflows, and then it becomes a bit of a fight off against tradition, the way we do things, the way we actually have to operate versus how the tool operates. And sometimes maybe the tool's got best practices in it. So it's like actually involved to use the tools, or sometimes it's just square peg round hole, and it it's the wrong tool for the job. So the first thing I always try, any organization I'm working in, I'm always trying to say, if you're looking at a technology, hands-on first, it can save so many headaches. Have you tried to all? If you're looking for an app, I had previously people saying, you know, I want to use an app for X process. And then when you actually get hands-on, they're like, oh, an app doesn't work in this process. It's it's always yeah, just best ideas. Like the demonstration goes only so far, hands-on really gives you an idea of how's that going to work. The number of times over the years I've had people say, like, I want something on an iPad, and then you get them an iPad and they're like, Oh, I don't want to carry around an iPad. You're like, Well, that's that's a big double invested.

Louis Blaxill 4:33

Yeah, yeah.

Aiden Flood 4:34

Yeah. So if you consider like a small enterprise, you know, maybe five, 10 people, if they're looking at something that requires an iPad, you've got the investment in buying the iPad, then you have to carry around an iPad and it might run out of batteries. So you've got a lot of things you need to consider before you even say, I'm gonna go for a mobile workflow. It's like, actually, you know, does that fit with your work? Years ago, iPads were heavy, and in oil and gas, we had to wrap them in a steel case to make it explosion proof. And as soon as you do that, you're suddenly like, hey, you've got and you're like, Do you want to carry that around now? And it's like, no, so that workflow idea is just a complete non-starter. Let's go back to the drawing board. So hands-on and a real life pilot of the type of workflow that it's gonna actually lead to. I'd say get that as early on as you can. Because otherwise, you might end up two, three years down a conversation or something if it's going that long for a large enterprise purchase. You could be working on it for years. If you haven't tried it out and got it in the field, it could actually turn out to be a complete waste of time. So it's like try it in the field. At a smaller firm, so much easier, you can act quickly. Uh you can go out and trial stuff and get demos a lot easier. So, you know, the quicker you can get that hand on, the better it's gonna be.

Louis Blaxill 5:52

It's interesting. I think from a, you know, obviously got thousands of surveyors using our platform. When we have been through that collaborative process, the firms that get the most from it are those that really attack it as well. I think there's an interesting one. Even before the trial process, people go, right, I'm gonna give Go report a go, but then don't advocate the correct time, don't think about how they're gonna test it, don't you know have an idea of what they're gonna do to make sure that it fits their workflow. So I think when analyzing it, have a concerted effort to do it in a relatively short period of time to go, let's either continue with this or let's let's

Why do teams underestimate software selection so badly?

Louis Blaxill 6:28

not.

Aiden Flood 6:28

I'd say that's one of the most often underlooked considerations when people across any industry I've worked in, it's always a consistent underestimation of the effort that it's going to take. Uh, people often consider I can just buy something off the shelf. So the same aspect people say, let's just build something from scratch. Like both of these things carry a lot of back-end analysis. There's business analysis processes, you can read books on that. There's a whole framework around how to choose a technology, if it's off the shelf or if it's bought. And it will take time from the surveyor. So if you're a small surveying practice, it will take your time to go and do a proper selection, at least probably a couple of hours, maybe like preferably, preferably longer. It's something you will be working on, you'll be probably paying a reasonable amount of money for. So you should really consider it properly. It's not just a case of I'm gonna buy that and I'll have it tomorrow and I'll crack on, I'll use it. You need to make sure you understand the processes, what benefits you're getting from it. There's quite a lot of work in there that people don't appreciate. And I've seen across many different projects, many different stakeholders over the years of a stakeholder not quite realizing that they'll have to put their own effort into a selection. And it can cause quite a bit of difficulty with getting a project over the line, because at the end of the day, they need to be involved in like requirements gathering. If you're a smaller firm, you don't necessarily have to go through all of those formal processes, but you should still consider that if I'm going to buy a product off the shelf, I should still put some consideration into this. And maybe that's a couple of days, which can become a bit of an issue if you're a small firm and you've got really tight margins. Can you take a couple of days out to go and do a proper technology selection? You will most likely get benefits out of that, but there's that short-term pain. And in this type of industry where time well literally converts to money because it's a very like consultation-driven type workflow. Can you effectively sacrifice some revenue for a technology selection? Yeah. Yeah, it's like short-term pain, long-term benefits, but people don't go into a process immediately considering that. You can make a quick decision, but a quick decision doesn't necessarily mean the right decision. There's multiple tools for any job. The only time you don't really make a selection is when you buy a laptop. Mostly people just go for Microsoft, but you could make that initial decision of am I going Microsoft? Am I going Apple? You know, am I going Linux? People don't tend well on that. They'll just go, hey, you know, I've used Microsoft before, I'll use that. When you get into technology to improve a business process, there's very few areas where there's like one flavor. There's multiple flavors. Have you considered all of them? Have you considered what fits your processes best? Which part you like? Is there a roadmap in behind the technology that you really get on board with? So there's several things you can do to select. If you're a small enterprise of two or three local surveyors, maybe you're not really too bothered about the roadmap, but you're going to be bothered about the commercials. There's things to consider basically that people don't necessarily go in thinking, oh, I'll think through these. It's just like I'm going to go buy milk, I'll just buy the first milk I see on the shelf. It's not quite that simple. Yeah. But it's just if you're going to do a technology selection, consider can I put a week into this? You know, if you've got a small amount of time, that's fine.

Louis Blaxill 10:00

But question for you, playing playing on the theme that you mentioned there around, you know, trial it, get a feel for whether it works and fits within your process. I think one really key element is having the idea of what good looks like, right? And what you're trying to achieve and making sure that you're always referring back to, you know, does it achieve the the kind of success criteria that we're hoping for? I'm curious, in your experience, and I'm sure you will have had this a fair bit, how how do you see the wood for the trees in terms of people don't like change, right? So there's a fundamental kind of this is different from what I was doing before. And in some some people will go, that's great, this is fantastic. Others will go, it's just different and that feels odd. How do you delineate between this is different and it feels odd, and the this is different and fundamentally it doesn't fit with the way that we work? How do you broader advice for how people that perhaps aren't in a kind of transformation role? How do you analyze that and how do you kind of sort those two different types of complaint?

What happens when the tool is fine, but people resist change?

Aiden Flood 10:59

Even if you do the best possible selection, you map out all processes and you consider all viewpoints, there will be someone that fundamentally doesn't want to change. I don't think I've encountered an organization where everyone just goes, awesome, let's get on board with that and make a change. And the size of the team doesn't really matter. It might be a two-man team and one of them likes it, one of them doesn't. It might be a 300-man team and it's like half of them don't like it, or two or three. And even the smallest number of people who don't like something will often cause the most noise. Like you get two types, either people really like something and they're very vocally supportive, or people really don't like something, and then more vocally against something. So change management is always the difficult part, it just takes time. And that's, I think, again, with the part of have you spent enough time selecting your tool? Have you had hands-on? Have you allocated enough time for the change to actually happen? There's lots of different theory about like emotional change curves. So I won't dwell on that particular topic, but it's an area of there's a lot of research material in that space. And they it all it holds out true regardless of the change. And it's, you know, three to six months might be the time required for even a small change to really embed, even if you're doing it to yourself, just two or three of you. Will you be comfortable with the new processes immediately? No. It's going to take some time. If you've chosen it yourself, you're going to get on board quicker. But if it's like you and two other people or something, one of them might take a little bit longer. When you get to large-scale business change on like significantly large scales, you might be looking at 12 months of maybe not everybody's on board with a change. It's a really difficult one, and you can only try your best to get everybody engaged from the start. Uh the book theory all says, you know, get everybody involved as early as possible, get them involved in the change, build a sense of ownership. So if you're making this type of change and you are like a small firm, get everybody's opinion and let them feel heard and try and just realize what your process is and what you're trying to move to. So as you said, start with where is it we think we're going to get, and then test every tool against that end position. If you think it's going to fully automate end-to-end, does it actually deliver that? Or are there some bits that don't quite work and then play it off against different tools in the marketplace? Say, hey, that one didn't quite deliver on part X. That one delivers on A and B, but still X isn't there. Like there's you have to plan out what you want to get out of a tool and go in with a shopping list. You know, write down the things that are actually important to you and then go shopping. Otherwise, you're just going to be completely bombarded by all these shiny things and you're going out, oh, I'll just buy the first one I've seen, and it might not actually fit your processes. And then that change is not going to work because other people at your business will be saying, Why did you choose that one? You know, it doesn't do these things and they're really important to me. So you need to, you know, get your team together, have a chat about what's important, make that your shopping list, and then go and see if there's a tool that fits it.

Louis Blaxill 14:14

It really resonates with with me as well in the way that we talk to people looking at Buy and Go report in the sense that you know the the people who are most likely to go through and commit to it are those who have a really clear reason as to why they're they're adopting it and what they want from it. You know, some people will come in and and have a broader, which is which is completely understandable in terms of information gathering, but the clearer they are on what they're really trying to achieve, the the more likely the adoption and the ultimate rollback is uh likely to be successful.

Aiden Flood 14:43

So yeah, absolutely. And I think if you were, you know, if you're a small firm, you've got to consider like what are you actually, what's the core value proposition that you're trying to support? It's probably going to be, you know, as many reports as we can fit in. What's going to get us that speed and the turnaround? You need to look at your local competitors. Like, are you competing with anyone in your local constituency? Yeah. What are they doing? Is it just fighting for like time? I can respond quicker, I can get to site quicker, I can turn around and report quicker. That gives you your value drivers. If you've got some kind of other market value you're going to, which is when you get to larger enterprises, you're competing in slightly different value areas. So you might be competing against insights, customer experience, that type of thing. So you're choosing tool selection not just on efficiency, but on some other thing that's important to clients. As you go down in scales, you're most likely competing on maybe a revenue change. But you've really got to understand what is it we're trying to achieve here? Is it like quick turnarounds? Then, no, that's that's a really key one for us. Is it whatever it might be for you in your business? Consider that and then make sure you're choosing the right tool that enables that particular change. And that's one, yeah, it circles back again to just understand why you're doing it. I've worked with people before who had a really big project and I thought they were challenging like industry norms. And this was in like the energy sector. I thought, hey, they're challenging industry norms, they're challenging safety cultures. Like, why are there such safe restrictions, restrictions on what you can use in like dangerous sites? It turned out what they actually wanted was a justification to buy new iPhones for their team. Like, oh, your reason for doing the project was actually, I want the new mobile firing. You know, that I slightly lost interest in it, but it's you know, make sure you're aligned on what it is that you're trying to get your purchase out of your project.

Louis Blaxill 16:39

Yeah.

When does building in-house actually make sense?

Louis Blaxill 16:40

Okay. And I think that's a nice kind of backdrop to discussion that we can now go into, which is, you know, let's start with build what's a situation in which you know people it's conducive to build a product. And again, we'll overlay a bit of a lens because I appreciate that the main thing that changes is available budget when you go up and down the scale of the organization size, but what's conducive to people going, right? This is worth us, us building at this point.

Aiden Flood 17:07

And again, this will have like this probably more of a big company lens on it. I'll try and think through a few different layers. When you get to large corporates, again, just like across all industries, you're trying to look for what is my strategic angle, what's the value I'm presenting, is it differentiated from our competitors? Do we need to develop something or can we buy off the shelf? That's a different driver to, and you can afford to do that because you will have money, you'll have skilled teams. When you go down the scales, you're probably less able to say, hey, we'll throw a million pounds behind development. So you've got to consider do you have the money? Do you have the time? Do you have the skill set? If you don't have the skill set already, you need to buy it. That carries with it business overheads. And if you build something, you need to run it and support it. I remember on my graduate scheme, way back when that was fundamentally drilled into us of say, if you are running a project to buy technology or to build technology, consider the next three to five years of OpEx.

Louis Blaxill 18:11

Yeah.

Aiden Flood 18:12

Because historically everything the true cost.

Louis Blaxill 18:14

Yeah.

Aiden Flood 18:14

Many industries. Yeah. And then people would go, oh, wait, it's now we've built something, we now have it. And now we've handed it over to the IT support team, and they're saying, well, we don't have £100,000 to pay for the support of this tool. That wasn't considered. So when you buy something, you need to consider the support costs. When you build it, you need to consider do you have a team that can support it? That's a massive investment that, again, isn't necessarily considered. Just in the last few weeks, I've had conversations with people saying, now there's this massive change in the AI background across the world, challenging organizations. Can we just use AI to build some stuff? And that is one of the biggest challenges I get across, again, most businesses that I've worked in is people just saying, can we just build it? And you end up with Excel models, because mostly what people think of as a tool is an Excel model. And the number of times I've been talking to a business where they say, Here's our fundamental-based tool that we've built, and it's an Excel sheet. And that's got so many issues. Like, what if the person who built it retires, leaves the company, is sick for a few weeks, and that's part of a critical process and it breaks. Are you in a position where you can support that? That's one of the benefits of going external, is you pay to outsource that risk. They have to provide a support team to support that. But you know, if you pay a little bit more and you're buying something that is maybe the same as all of your competitors are using, if you need to differentiate and provide a specific value to market, that really pushes you towards you're going to have to look to build something internally, which then carries all that additional overhead of you need to develop, like build a tech team if you don't have one, you need to pay for them in the future. You need to make a whole load of technical choices over what tool are we building in, what's our technical architecture? There's a reason IT exists in corporations because that's not an easy answer. That can be expensive. So you've really got to choose is it worth building something and taking on that overhead? Is that going to give us that strategic differentiation from our competitors that's going to help us stay relevant in the marketplace? If not, you're most likely inclined to just say, we'll buy off the shelf. And I think a really interesting one that's happened in the last, I think, the last few months was Apple saying, actually, we're going to kind of buy Google AI. And in the back end of Siri, there's going to be Google. So that's someone at Apple making a very interesting choice of saying, oh, maybe Apple isn't as far ahead as Google in this space. And typically they're massive competitors, but and I haven't read the ends and outside of the personal deal. Yeah. But saying our competitor might be better than we are at this. So we're actually going to put them in the core of our service, which I don't think I've ever seen before.

Louis Blaxill 21:09

It's interesting. You mentioned AI in particular. And you touched on it there as well. You know, you've got the cost of maintenance, you've got the cost of security and uh kind of having a reliable solution. And then another thing in our experience that's often overlooked is that continual development and the disruption that AI brings in terms of, you know, you have a figure in your head and a vision of where you want to go from a product perspective, but then the idea of constantly iterating it and the cost associated with that, particularly in a world that's moving and updating so frequently. You know, one, you're then reliant on yourselves coming up with the ideas, and two, you're going to have to foot the bill for that, uh, rather than service providers crowdsourcing and being able to draw on numerous subscriptions.

Aiden Flood 21:53

That's a really interesting one because yeah, you're outsourcing not just you know the skill set and the the Need to like maintain a team. You're outsourcing the roadmap, the development, the need to stay on top of the latest technology standards. And you're outsourcing the risk of whatever that tool is becoming obsolete, almost. You're sort of able to play the market and say, actually, whatever we've got, and I would it's been drilled into me since I was a graduate of avoid vendor lock-in. So that's something I'm always looking for is is it easy to drop whatever technology you've got in? Uh you're buying something off the shelf. What if next year a technology comes along that makes that product obsolete, or that business doesn't react as quickly? They don't, in the modern world, maybe they don't embrace AI as quickly as one of their competitors. Can you bail out of that one and go into the next one? So you outsource the risk, you give yourself additional options, and playing the market allows you to stay on top of the latest developments. And that company that you're buying a tool from, they take on all of that cost of RD, of innovation, of new developments, new releases. Is the tool secure? You outsource all of that onto the company that you're buying from. So that can be really effective. If you are a small company, are you going to be able to pay someone to keep on top of the latest technology security guidance? Are you going to be able to say we are patched to the latest security things? Very unlikely. That's like really difficult, quickly moving space. If you outsource that onto the technology vendor, they're very unlikely selling to just you. They've got multiple streams of revenue. So they've got a pot of investment money that they can use to stay on top of these things. So that's a real benefit of going to market. You don't have to take on that headache. You wouldn't have to hire someone like me to lead your technology team and say, right, what are we doing to respond to the market threats? How are we innovating? Has someone made sure they've patched that server last week? Real conversations that happen across even large organizations, it's a difficult thing to keep on top of. You can outsource all of that risk, which, you know, if you're a again, if you're a small firm, that's probably a really, really alluring option that you might not have considered. And when someone says, Don't worry, I'll just build it in Excel, I'll use some macros. That's one of the biggest, biggest fears I have when someone says, Don't worry, I'm just putting together a macro. I've got a 700-line macro. It's great. You know, a little bit of fear comes with that of is that okay? Is it scalable? Is it safe? Is it secure? Is it gonna work when it actually needs to because we've got a crucial client delivery tomorrow? Again, the benefit of outsourcing that is you just get on the phone and say, My pool's broken, I need it immediately fixed. And there will be a support team on the end of the phone that'll say, sure, we'll get on that. So there's a whole load of risk that you outsource. Again, if it's your strategic driver, then you can take that internal.

Louis Blaxill 24:54

We've talked a lot about buying in software and the conditions in which you might consider doing that. If you bring to life a really specific example, redacting all the necessary details where building in-house has provided a strategic advantage and actually the conditions that were in place for you to be able to do that, I think that'd

Could Excel and Power BI replace a costly platform?

Louis Blaxill 25:13

be really interesting.

Aiden Flood 25:47

Yeah, and this one's not a new one, but it's still very relevant, and it's got everybody's favorite tools involved in it of Excel and Power BI. So it doesn't necessarily sound like the most technologically advanced solution, but at the heart of their tech stack, Microsoft have built some really useful tools. So whilst I'll often shy away from telling anyone to use Excel to build products, sometimes it's the most effective thing that you can use. So if you're a small firm and you're thinking, you know, in this particular instance, it was half a million pounds of license subscription for a planning tool. When we really looked at it, we determined we could build plans in Excel and use the automation behind like Power BI, which had now been like the Power BI Fab Microsoft Fabric universe, but back then that didn't really exist. And you can use the automation behind those tools to pull together multiple spreadsheets, and we could run planning effectively from a Power BI sat on top of like a hundred spreadsheets, which could then be sent off to individual project leads. And it became a tool that allowed us to actually stop paying for that half million pounds of license fees a year. So you can be inventive, you can use the tools that you already have in your organization, particularly if you're at the smaller end, if you're you've got a two or three-person consultancy or you know, a hundred or so. You will have Microsoft Excel, you will have access to things like Power BI. If you can take the time to do it right, and again, it comes back to that time. Do you know what you're aiming for? Do you have the skills? You can, I use the word cobble together because I feel like that's effectively what it is. You can pull together an effective tool. But again, you've built something internally. It might give you that short-term relief. It might avoid spending all that money on an external tool, but you've now taken on a tech burden. You have put yourself in a position where you are supporting that. That was fine. The team we had at the time, we could just hand it over to the IT support team, actually. It was like, hey, business builds something internally, not particularly complex, but effective. And actually, we could hand that over to a support team. Not everyone is in that position. So again, whilst I say you can really build something that is effective and it can save a load of money, you have to really consider is it the strategic sound option for you? Because you've now taken on this burden. I know a lot of small firms like build complex Excel models, and particularly across our industry and commercial real estate, you'll have things like the facade modeling teams or like fire modeling teams who build like complex Excel sheets. Like, cool. But they take on that burden themselves. It's very infrequent that that'll be done well. Yeah. And if you're a small firm doing that type of thing, you know what you're doing, you're taking on that burden. But you'll probably have one person who's doing that. And it's like, what if they're what if they're out on holiday? What if they're off sick? What if your model software breaks and your software in that case is an Excel sheet? There are modeling systems available on the market. Maybe one of those would be an offset to that risk. But you've really got to think of like, what is the risk of that happening? Are we okay if it happens? If not, then you'd be more inclined to look to the market or somehow try and bring in a IT consultant specializing in like Excel support to look into that. But it's yeah, it comes back to that risk every single time of like, if you develop something internally, that can be a risk that you now need to take on and support. Are you in a position to do that? If not, maybe it's best to exhaust it. If we take buying a car as an example, if you buy a car up front, you take on all the liability for that. You need to insure it. If it breaks, you've got to fix it. If you lease a car, which would almost be the equivalent of buying like a SaaS product or something, there are things that the company you're leasing off will now come and take care of for you. Like, oh, you need replacement tires. Don't worry, we've got it sorted. You need a replacement windscreen, don't worry, we can fix that. The car's completely broken down. We'll take it away and we'll give you something else to get you by once we fix it. And that's almost the comparison of interesting example. Yeah, yeah. That breaks, that's on you. You buy it off the shelf, that breaks, that's on them. And at the end of the day, if they can't fix it, you go, cool, we'll go and buy the other one because they probably can fix it. And again, that gives you the almost the benefit. When you're shopping, you get to shop around. Um so it can be a really nice position to be in where you say, actually, we've got the power here, we can shop around, we can look for things. This won't be helpful to you, but from my perspective, when you've got multiple different vendors working in a space, your negotiation power is a little bit higher. So it can be not necessarily from a complete like neutral advisory perspective, which is what I'm pushing here, you've got a little bit of wiggle room there if you're going to the market and buying off the market. It's not an immediate this is going to be really expensive, but you will get the benefits of I'm outsourcing that risk. And you most likely can get a better price than list price. So for anyone listening that's not already trying to do that, it's worth looking across the market. Yeah. That's really yeah, the benefits. Like consider it in that do I want to own the car or do I just want someone else to take care of it and I just get in and drive it wherever I need to? That is an interesting analogy.

Louis Blaxill 31:40

And in relation to, I think the only thing that we haven't touched on is

How much does speed to market change the decision?

Louis Blaxill 31:45

speed as well. That's something that often we have conversations around, you know, and perhaps people underestimate the the time required to develop your own or develop in-house or build. Is that kind of okay? You know, what not only what are we trying to achieve, but also how quickly are we trying to get there? Because there is elements you're absolutely right in terms of onboarding, but then there's a we're gonna build, and then you're three years down the line and you're going, we're still playing catch up almost because technology's moved on by the time we get there. And look, that doesn't always happen, but it's something we see fairly frequently, which is you know, it's a great vision.

Aiden Flood 32:20

Yeah, it's another one of those like massive things. So like we've talked about risk and we're talking about cost, building your own internal team, speed to market 100%. Like, even if you decide, hey, I'm gonna build this is a strategic differentiator, and I should build it internal. Cool, made the decision. Go and hire someone. That's that's immediately if you don't already have a team, you're gonna take like three months to hire someone. Then they have to build it, you have to do the requirements building. By the time you hired someone, chosen the technology, built a minimum viable product, like something that works, the company that you avoided buying something from in the market, that's six months further down the line. Um, they're unlikely to be sitting still. So that's a really it's a difficult one to determine. Like when you're a large corporation trying to figure out you know what's what's the best way to play that, that's that can be quite a difficult conversation. If you're a smaller firm, it almost becomes a no-brainer of saying like you either need something within the next month or you know, where when do you need it? So that's that's a massive one to consider. By the time you've got everything together and you're playing, everyone else is further along the line. Yeah. And are you in a position to be able to take people away from the market? If we again play on the AI space, who's winning the AI race? You know, we'll we'll say Google, Meta, Amazon. If Joe Co. startup technology limited decides we're gonna play in the AI space, are they going to be able to hire the best people? Or are they competing with the million pound pay packet that Google's offering? Like, are you gonna be able to get the the technology skills for it? Are you gonna be competitive? That's that's a real decision that global firms have to go through. I've seen at previous firms people get poached from like Uber. You're like, okay, you can play in that game. You can poach someone from a significantly large company. If you're a small firm, are you gonna be able to do that? Are you gonna be able to get the right skills to come in and fix everything? You're unlikely to be able to get what we'd call a unicorn, someone who's gonna come in, figure out your business problem, tell you what you need to build, build it and support it and run it. That's quite a lot of skills in one person. You're probably gonna need three or four. Yeah, it's like if you don't have that capability already, you have to build a team and you're immediately like, let's just buy off the shelf. In that position, you would be very, and I'm just gonna presume a small firm with five people is gonna immediately just say, I'm not in a position to build. Your incentives to buy just far outweigh anything. When you go up the scale as an organization, it becomes a really difficult conversation. And it's not just as nuanced to say, you know, we're a massive global organization. Of course, we'll build everything internally. I've worked at corporations in the past where, you know, they they've tried both models, they float in, they float out, and you end up in a halfway house of we'll build some things and we'll buy other things off the shelf. If you go to a shop, even a large international chain, do they have their own brand of tools or do they just buy one off the shelf? So, like, we're not gonna differentiate basically. Yeah, you know, people need to be able to buy things, but we don't differentiate off that. But we will have you know something else in the store that gives that brand feel. Yeah, you've got to pick your battles and say, what's just a tool that does the job that everybody uses, that everyone needs, and that's okay. And what gives us a specific different slant? And if you're a smaller firm, maybe you don't need the tool to be the specific slant. Maybe your slant is we answer the phone and we turn up when we say we will. That can be that could be a very specific business value. Yeah, differentiators, especially when you're looking at like you know, building surveying around the UK, you know, just being able to answer the phone, pick it up, and turn it up to site, then do the reports quickly and hand that over to the client. That could be a differentiator against all of your local firms. And if you can get that to market quicker than everyone else, you know, that'd lead you down the let's just go and buy something off the shelf.

Louis Blaxill 36:42

It's an interesting one within a microcosm within Go report. We see that on a fairly frequent basis when surveyors are making the decision between, okay, do we really want to bespoke of a specific report? And is this our differentiator? Is it the way that we present the information that's going to set us aside in the market? Or actually, you know, it's a simple snagging report. Actually, that's fine. We can just, you know, use a slightly more generic report. So yeah, we we see that even within Go Report itself, which is quite interesting.

Aiden Flood 37:07

Yeah, if you look to AI guidance, but the RICS have published guidance about AI, which almost crosses over into just general technology selection. Um, if there's any surveyors out there who haven't read the RICS AI guidance, it's a wealth of information for things other than AI. It outlines how to do technology selection, how to consider what you actually need within your business. So if you haven't read that and you're a surveyor and charted by the RICS or just anyone in the industry, it's got some interesting, useful tips around there of just how to consider procurement, how to take a sensible, logical approach to a need to buy a technology. They've got that framework kind of built out in their AI guidance, which you might not have read because you're thinking, I don't need an AI technology, I just want something to speed up my end-to-end delivery. It's got some tips in there about how to procure things. So, and while you're there, the RICS also has like a tech partners listing. They've got guidance on lots of different things. So if you're in the space of building in the building sector, have a look around the RICS. They've got some really good, really good tips in there that'll help you figure out what to do.

Louis Blaxill 38:19

It's a good, good resource. Uh, I'm I'm pleased you've allowed me the opportunity now to ask a potentially antagonistic

Has AI really changed buy versus build?

Louis Blaxill 38:25

question because no doubt you get answers on that one. Does the introduction uh look, we're we're working on AI embedded solutions within Go report, but does the introduction of AI at this stage fundamentally change the question of should I buy, should I build? You know, you hear fairly frequently the oh, you could vibe code this and you could build this and stand this up really easily yourself. I'm assuming there are people uh in all walks of life that have come to you for your advice on you know how much that's going to change things.

Aiden Flood 38:53

Yeah, so the question of AI changing the discussions immediately in the last couple of weeks, since the latest developments in AI, discussions from the office through to just hanging out over a coffee with mates, the discussion has all changed towards can you now just vibe code it? Or not even vibe code, what they're now calling like vibe engineering, I think. Using just agents, can you just tell it this is what I want and it'll go and build it? So yeah, it has changed the game a little bit, but it still edges back to that initial discussion we were having of you're then taking on a bit of a risk there. If you're sitting down with a co-pilot agent or a Claude, like one of the big main players, and you've developed something, are you sure it's doing the right thing? Is there quality behind that? Have you got your QA checks in? To reference the RITS AI guidance again. That's one of the prevalent themes throughout that report is have you got controls? Are you sure that the output is correct? Is the tool doing what you expect it to do? And is it doing it consistently, accurately, et cetera, et cetera? So it does become a bit of an interesting, it changes the game, but you've still got the same buy versus build issues that you had before. But people potentially able to build more. Um, and something we're always concerned about across every organization is stealth IT, people doing things that you don't really know about. These type of tools increase people's ability and give them confidence to say, oh, I've just built a new digital tool to do X, Y, and Z. It's like, have you? People I know that our developers are saying the game has changed for them from coding and developing to QA. Like the AI agents can do a, they can build something, but when you look under the hood, is it going to be clean? Unlikely. And do you need to double check it and make sure it's not doing anything really risky? If you're at a large enterprise, that's a major concern of data security, data privacy, GDPR. If you're operating across borders, if you're operating across Europe, you've got real issues with data residency, with data protection. When you get to a small firm, you're potentially just putting yourself in a painful position of we built something. It's the new version of I've made a massive macro. Now I haven't made a macro. The AI has made a macro. Cool. Is it working? So is it changing the game? It's making it quicker to make yourself an issue. Sort of. It's sort of changing the game. It gives us more interesting options. In the vendor space, it means we might have more demands on the market if we're saying, right, can your tool do this? If not, we want it in two days' time. Like it might change the expectations on the market. Is it going to change competition across the market? I would highly anticipate it will. Anyone that is offering a technology product on the market is now under that additional stress of coding a new feature has gone from a week to you know a few minutes. But you've got that same pressure of making sure it's good, making sure it's it's safe, it's accurate. Again, on that risk outsourcing, instead of taking that internally and saying I've built a super macro, it's great. You're outsourcing all of that risk onto uh onto the market. So in a roundabout way, it doesn't really change anything. But it does it does really generate some opportunities in the surveying space. Anyone that's even looking in this area needs to read the RICS AI guidance because that's got very clear rules and guidance that if you want to retain your chartership, you need to be abiding by that. That puts some controls in place, but it yeah, it means we're going to be challenging the market more to say, are you going quicker? At the same time as me saying it doesn't really change anything, it does mean it's quicker to build stuff internally, but only if you have the skills to support it. If you've got the skills to check it, make sure it's good quality, then you know you've got that in-house capability, you can generate new products so quickly. You can look at insights super quickly. But you need those control and governance mechanisms in place to do that in a safe way. Otherwise, you end up delivering something to the market that is of dubious quality. And there are some there's some recent not horror stories in there, but there's some big four type activity where a large firm has delivered something and it's been found to have been generated with AI, it's got spurious results in there, it's hallucinated something, and that comes back in a fine. If you're a building surveyor, you probably don't want that. You probably want to make sure it's like safe and secure and compliant, repeatable, you're not opening yourself up to liabilities. Again, if you're a small firm, that's such a headache. It's you're probably going to be better off just saying that's too much. We're going to go to market and we're going to give that headache to someone else. And if something goes wrong, we're going to make sure that NDAs and our legal contracts with that company cover us for it. Which is something if you are a building surveyor in the space and you're signing contracts, are you looking At like liability caps. That's a big topic of discussion. I've been at lunches with like lawyers and big four type firms. The discussions come back to like liability. Is your PI on the line? What happens if that third party gets hacked? Or now if their AI generates spurious results, as a charter today, you're going to be potentially on the hook for that. Are you going to get in trouble? And in trouble means a whole heap of different things. So those are the modern risks of it's easier and quicker to get into hot water than ever before. Make sure you're reading your paperwork. Make sure you understand what the paperwork is saying. People often think procurement of IT services is really easy. They just say, hey, I'll just ask for a contract and I'll sign it and it'll be fine. I have had to inject clauses into service agreements that say, you know, if this breaks, we will fix it, because that wasn't already in the service agreement. Yeah. I've seen NDAs that have wide open gaps in there where you're like, right, well, that doesn't really cover anyone for anything. So if you are a surveyor and you're going to procure some software from the third from a third party, make sure you've read the paperwork. If you don't have the skills for it to realize what it's or to really appreciate what it's saying, you know, get guidance. AI can help give you that guidance, but don't rely on that as a fundamental legal advice. But it can at least help you spot gaping flaws in it. So if you're in the space and you're going to procurement and you don't have like a lawyer on hand that understands IT procurement because it is a speciality, you know, you can use AI agents to at least give you a bit of an idea of what it is. It's not legal guidance, but it'll maybe give you a few ideas what to discuss with your third party. A couple of most inquiry. Yeah, yeah, absolutely.

Louis Blaxill 46:25

Very good. I mean, we've we've covered a hell of a lot there. It'll be difficult for me to summarize it, but if I if I can give it a go, I think, you know, the the fundamental you started with was why consider any of this at all? It's when you've got a problem and you're trying to solve a problem, right? That's that's the key at time where you want to start looking at actually, is now when we should consider buying, when we should consider building. I think the the message that came across loud and clear were timelines and true cost of ownership. If you are looking to build it in-house and whether it is something that's going to give you a strategic advantage. And are you prepared to take the speed to market uh hit that that comes with building in in-house? Then I think you've covered off a whole host of good points, but uh the really important things from my perspective when you're looking at a software provider are absolutely what you just said there around security MSAE. So, what agreement do you have with them, really understanding what your liability is and what uh liability they're taking on, understanding what you can configure, what you can customize within their solution to make it your own, understanding also what input you can have into their roadmap as well and what their roadmap looks like to make sure that it's aligned to your future uh ambitions for your business, but a host of other things that I'm afraid I can't uh can't necessarily recall in a summary version. But thank you very much for coming on. It was a really interesting conversation and appreciate it. No problem. Thanks for having me, Lou. If you enjoyed today's episodes and/or it gave you some food for thoughts, be sure to follow our show on your preferred podcast platform. To learn more about what we do at GoReports, visit goreport.com. The links are also in the bio. Until next time.