Should You Build or Buy Your Data Collection Software? With Maria Pervova of SurveyCTO

Yeah, I think this one goes to potentially a fallacy of believing that if your team built it, then you know how to use it and it will be easy for everyone to use it. But one thing to consider is that who is building it and who is using it are usually different teams, right? The team that is building it, they're going to be developers, it's going to be the IT team. But who are the end users? Those are the people actually running the projects. Those are data collectors of some kind, potentially on the ground, if you're collecting data in the field. And so there needs to be a transfer of knowledge either way. So even if your dev team knows the system in and out, there needs to be training, there needs to be capacity building and development. Regardless. In today's episode, we will discuss one of the most important decisions that organizations and companies usually make when they are building their tech stacks for data collection. Whether they should build their software in house or create their data collection workflows using a software as a Service or a SaaS platform. I have a lot of conversations with organizations today where I see them debating the pros and cons of building versus buying a solution, to the point where I thought, hey, let's have a conversation around this. Because sometimes the decisions that teams make can be nuanced, but other times they can be boiled down to things like human psychology and this perception of control. So I think this is a really interesting topic. And so to kick off this discussion, I invited my colleague Maria to go over some common beliefs around this topic and have a conversation about building versus buying. Welcome, Maria. Hi Marta. It's nice to be here and it's nice to meet everyone else who may be listening. I'm Maria Pervova, I lead our business development team and I have been leading our team for the past five years. So I'm excited to have this conversation because every day I'm speaking to organizations that are navigating the trade offs between whether they would like to build their own internal tool or leverage existing platforms. And they're oftentimes considering the scale, sustainability and impact that could result from either one of those decisions. And what I've seen in my conversations is that it's oftentimes not a one size fits all approach. So I'm excited to dig into some of those common beliefs with you. Marta. Perfect. And we put together four different common beliefs. So my suggestion would be to go over each one of them. I will kick off with a common belief, you can react to it, and then we can just have a conversation about each of them and the first one would be in house. So software in house is going to give us exactly what we want. This is really interesting, especially the wording of exactly what we want. And so in conversations that I've had, and I know you've had similar conversations as well, Marta, I think an important question to ask is what is it that you want and how unique is it? Has nobody else ever considered possible solutions to it? One thing is the software and the technical requirements. How unique are those technical requirements? Because how you may actually end up using the software, I bet is going to be incredibly unique to your organization and your organization's mission. But in terms of the technical requirements, where are we on the scale, would you say? If you were to look at it Honestly, is it 80% unique or is it 20% in terms of existing solutions on the market? Because that will really affect the downstream decision making of whether or not you really feel it is worthwhile to invest your precious internal resources, your IT team's time into building that tool in house. That's a great point. And I would say I was just thinking about an organization that I've been working with and they built an in house software because that's what they thought. They had a very unique use case, they needed a very unique set of features. And in a way that's true. But what I have realized is, and I wanted to create a terminology for this and I was brainstorming with AI and we named it the Frankenstein effect, if that makes sense. So because usually internally, these companies, they want so many different things, they think they want something unique because they want so many different things. They have so many internal stakeholders that require so many different functionality and features and they want to try to accommodate every tiny bit. And it can become problematic in the long term. I would say that's what I have seen. And with a SaaS platform, we have usually a gatekeeper, we have a product manager, we have a product roadmap and that allows SaaS platforms to set boundaries and to set priorities and to say no to things, to look at the big picture. So there would be a downside that I've noticed about this uniqueness. And to add to that, the other thing that I would Say is some SaaS platforms allow you to customize things. So there are features available in some platforms that would allow you to customize a few things to your needs if you have a more tech savvy team. Well, I only remember our specific SurveyCity example. There are plenty others, I'm sure we have field plugins. And this allows people to not only use our native functionality, but to build on top of the native functionality and to customize to their own requirements. So I think that's also important to that point. Yeah, so that example, if you find that your technical requirements, from a data collection perspective, how you want to manage security, integrations, et cetera, could be managed by an existing platform, but maybe there's 20 or 15% that you would like to customize. Something that may be valuable is exploring platforms that allow you to do that, that are more of an open system where you can do something such as a field plugin, or you can leverage integrations and focus your IT team's time on those aspects. So I want to go back to that surveycto example you mentioned. I think we may be thinking of the same organization. So it's an organization that works broadly with thousands of hospitals. And I think it's really interesting to think through or just share just a little bit about the their process in an anonymized way, as we haven't officially published any documentation with them. But at some point maybe you'll hear more details about this story. But I thought it was particularly interesting to me that it was the CTO or the CIO of the organization that reached out to us. So that person is the person that leads the team of developers, their technical team, in house, and they had been building their own custom tool and they even shared with us that they had recently invested in remodeling and revamping it, a significant investment. And at that point, this person and their team, they came to the realization that maybe one way that we can actually take our organization forward is seeing innovation as refinement and building on top of an existing platform that will allow us to scale much further. Like I think of this interesting quote from Henry Ford. I invented nothing new. I simply assembled the discoveries of other men. And I think that's maybe the way to think of innovation. It'll allow you to go so much further if you build upon what exists already instead of building it and finding ways to manage it in house long term, which is the service that software As a service, SaaS companies provide you so that you can leverage that creativity you have internally. Further, that is specific to your organization. Absolutely. And not only that, but a lot of times when you think about building in house, you are thinking about today, you are not thinking so much about the long term. And in so many ways maybe it can be. Well, I wouldn't say easy, but it's possible to Build something today, but you need to know how to maintain it and not become static. Technology is evolving rapidly. Not only technology, but even your organization or company needs is evolving. So it's something you need to assess from time to time and see what needs to be adjusted or what needs to be improved. And that's something that we all know that SaaS platforms, they have processes to make sure that they are evolving, to make sure they have a dynamic product roadmap. So it's a more dynamic environment for these organizations. Absolutely. Maybe it would be helpful to even consider naming a few of those things that are essential for any software tool that you're going to use. But for an organization to consider whether they want to be the ones to manage that or whether it makes sense to leverage an existing solution for some of those things. So for example, for a software, you need to manage the hosting, whether it's going to be cloud based hosting, whether you're going to pay for the hosting and manage it yourself. There's also the security monitoring features, building security into the platform, constantly fixing bugs. All those things are aspects for you to consider whether or not that's something that you want to spend your time on. Or perhaps it's the integrations or the field plugins, which, at least within the Survey CTO system, these are ways to be very creative in customizing the look and feel from a user's perspective. So that's something different that can sit on top of this foundational layer that is already taken care of. At Survey CTO as an example, we have thousands of users and so we focus on those foundational basics that may be not the things that come to mind when you're originally thinking about building your own platform or leveraging an existing one. And this makes me think a lot about opportunity cost. And I even thought about an example from evolution and how humans have evolved. There's an idea called the expensive tissue hypothesis that throughout human evolution, previously we had a very energy, expensive digestive system. Even if you think about a gorilla, a gorilla spends a lot of time eating a lot of leaves. And that's because it requires a lot of digestion to nutrients out of those leaves. And this hypothesis states that as we began to eat more nutrient dense, calorie dense foods, our digestive system shrunk and our brain increased. And that is one of the things that makes us different to any other animal in the kingdom, is how big and robust our brain functioning is our human intelligence. And so this connects with opportunity costs because there's a certain amount of Energy available for the organism, for the body, but how are we going to use it? We could spend all of our energy digesting and digesting, but if we eat better food since we discovered fire and we're able to cook with it, has enabled us to actually change the way where energy is spent. And you could think of any organization in the same way you have a certain amount of energy and intelligence available to you based on the people that are working within the company and the number of hours that they work and the work week, and what do you want them to spend their energy on? What is the most creative use of their time and also what would make them excited to come to work, what problems do they want to work on? I really like that perspective. I think I just wanted to share one more thing under this point. And this is also related with the fact that more commonly, organizations are creating a tech stack. So you usually don't think about your data collection as something that requires a single software. It depends on your needs and requirements. But usually you need to integrate a data collection tool, maybe with a marketing tool, maybe with a BI tool for data visualization, maybe a data analysis tool. So you need to think about an ecosystem in a way. And what I would say is from my experience, I have noticed that a common problem of organizations is creating data silos so you can collect a lot of data, but then it becomes impossible for you to use that data efficiently because it just have a bunch of different data sets that it's a mess to merge them and to analyze them together. And so to that point I would say consider this when analyzing whether to build or to buy. And consider SaaS platforms that already have a lot of pre built integrations that would make your job much easier. And I know that maybe one of the bright sides of building is that you are building for a specific data architecture of your organization and company. And that's wonderful, but you also need to think about the ecosystem. You don't want to have an island, you want things to be connected and to work together. Yeah, that's a really good point, Marta. And I think many conferences that you and I have both attended, data silos seems to be a common theme. There's at least one session at most conferences we've attended talking about this problem. Because building software is one thing, whether you build or you buy, but it's probably not the only tool you're going to be using. So considering integrations is so important. And I was just filling out a proposal actually for a prospective client and I thought one of their questions was amusing because they were asking, are you open to integrating with other platforms? And my response is absolutely. We encourage it, we make it easy. We have been expanding our API functionality for that reason because we understand how it works. Even if you decide to use Survey cto, it's probably not the only tool you're going to use. And we encourage you to build it in and make those connections so that you can actually accomplish your goals, which may require more than one tool. Okay, I think we are ready to move on to the second common belief. Let's do it, let's do it. So the second one is in house is less complex to operate because we built it. Yeah. I think this one goes to potentially a fallacy of believing that if your team built it, then you know how to use it and it will be easy for everyone to use it. But one thing to consider is that who is building it and who is using it are usually different teams. Right? The team that is building it, they're going to be developers, it's going to be the IT team. But who are the end users? Those are the people actually running the projects. Those are data collectors of some kind, potentially on the ground, if you're collecting data in the field. And so there needs to be a transfer of knowledge either way. So even if your dev team knows the system in and out, there needs to be training, there needs to be capacity building and development regardless. And that's the other thing about the finite resources. If this dev team is building this tool, then they have a lot of responsibilities. It's not a set it and forget it. We're built for good, we're going off on vacation. You have to be able to maintain it. So fixing bugs, taking internal support requests, hopefully innovating, that's the whole point of building your own tool is having the space and the time and the energy to create something new that doesn't exist. And then if you're also going to be taking that team's time or somebody else's team's time in relation to this IT team to train others too, then the operational aspects of the day to day function, it increases drastically. Yeah, and to add that, and I think this comment might be very general, obviously it's not the case for everybody, but in general, a software in house, I would say the user interface and the user experience is less intuitive. And this is very much in general for sure. So that requires another layer of more documentation, more capacity building just to ensure that if the lead developer leaves, people are not lost. And to this point, what I would suggest to organizations is to even consider SaaS platforms that include services, professional services to support you. Not only that would help you. And we know that going to a SAS platform also requires a learning curve. Absolutely. If you are adopting any new software that requires a learning curve, but you can consider platforms already have good training materials online. You can consider platforms that have services that can provide you with tailored support and good supports, responsive supports. It can also tailor private trainings just for you from time to time. And it can also allow you to scale up with consultancy services too. And I think that goes to your point about resources using resources efficiently. If you are outsourcing that to professional teams from SaaS platforms, it can be easier to scale up for sure. Yes, I completely agree. As oftentimes that may be something else that is not considered into the equation of building versus buying is that change management is something you have to deal with regardless, at any level. So it's something to consider. Yes, and ensure that you have the support internally or support you can rely on externally that will get you there because it definitely requires the whole village, everybody on board in order to make those changes. And it's just if it's important to build your tool in house, but then the team that is doing the building also has to support with training. It really makes their lives much more challenging. Anything else to add about this common belief? I think maybe something else to keep in mind is the flexibility as if you build your own in house tool. Maybe some advantages of that may be that you can customize everything. The front facing team, the end users, they can put in requests to their dev team to make changes. But it's all about the time of how long it will take to make those changes. Whereas oftentimes with SaaS platform they are intuitive to use and flexible so that things are not hard coded. If we call something one thing, if we call this a banana, but we actually want to talk about plantains. We don't have to put in a request into the dev team. It's something that you can do already and you make those changes. So the flexibility may add to this point about operating the tool is what if you have to make changes throughout and how frequently do you have to make changes? What if you want to experiment with new workflows, new business models or new projects? How long will it take you to get those off the ground? That's a great point. Moving to the third common in house is more secure because we control it. This one almost feels psychological in some way. You can Adapt this feeling to anything else. But when you feel like you control it, then you know what's happening, you know what's going on. And so you have this sense of security because maybe you're relying on yourself. But again, most of these points it's about what do you want to take ownership of or what do you want to hand off? And oftentimes with security. This is a technical question. Are you building in security measures into your infrastructure, into your policies and practices? But if you are building a tool in house and then you have partners or collaborators, funders, donors, government agencies that have an interest in your software, in the way that you are conducting your projects, not only do you have to actually ensuring that their security has been built in and thought through in the way that you've built your platform, but you also have to prove it. And that is an incredible compliance burden. Because you might think like internally we are doing it, we've considered this deeply. But oftentimes you actually have to jump through the hoops to go through the compliance audits and show people that you are certified, whether that's SoC2 or ISO or any kind of certification that yes, believe us, we did it. And that's a whole other level. And that probably costs a lot of time from a different team. We can even share our own example. Internally. We go through an annual SOC 2 audit where a third party auditor comes in, we welcome them in so that they can check everything under the hood and ensure that we are doing the best in terms of industry standards for data security, availability, maintainability, et cetera. And this takes several team members maybe three to four months out of the year, every year just devoted to this practice of not only are we actually maintaining those practices, but we need to prove it, somebody needs to verify it. So that's something to keep in mind. And we're able to do this and invest in it because we have thousands of users that are all relying on this and in care to know that this is being done. And the calculation internally may be different if it's your in house platform and you're just supporting your organization. Again, it would depend on how big your organization is and whether that is worthwhile for you. Yeah, and data privacy laws are becoming more and more aggressive over time. So I think that's also important to note. Okay, this is not becoming easier, quite the opposite. So it's becoming more costly and it's becoming more important because of the data breaches and so many other things that are so important. If you are collecting sensitive data and personalized data. So definitely an important point to consider. So if you are considering SaaS platforms or leveraging SaaS platforms and you're interested in knowing about their data security, maybe a few things to keep in mind, of course, is you might be interested to know which kind of audits they undergo, what are their compliance regulations that they follow. Some other aspects to consider would be about their hosting. Do they offer GDPR compliance? For example, do they offer hosting in several locations that you feel comfortable with? Something else that is really important to keep in mind is something we've prioritized as a company is end to end encryption. Where most software platforms on the market right now they offer at rest and in transit. That's the baseline standard. I think you can't be missing at rest and in transit encryption in this day and age. But we offer another layer which is end to end encryption. We enable you to create both a public and private key, which is a long string of letters and numbers, and without it, nobody in the world can access your data. So those are some things to consider whether you're going with a SaaS platform or if you're building in house. Those may be some points to keep on your list. The fourth common belief in house is cheaper. And I would say this is a big one, right, Maria? Yeah, this is huge. We left the best for last. And I often think it's the first thing that people ask about and they think about. And at the company and with organizations that we speak with, we're often discussing the idea of the true cost of ownership, which is like an iceberg. Everybody can see a few things when they consider whether they're going to build or buy at the top of the iceberg. But people don't realize there's so much beneath it at the top. If you're going to build your own tool, it's the building. How long is this going to take? How many developers do we need? But then there is maintaining, as we were discussing. It's not a set and forget it. This is a living tool that's going to grow and evolve. And even if it doesn't grow and evolve, at least to maintain it, the developers need to consider things like OS updates, browser compatibility, performance and scaling, server reliability. We have to make sure the system is online and that the end users can actually use it as well as support the internal team members. They may have support requests, they may have troubleshooting, technical support that they need, training, putting in bugs and feature requests. There's just a lot beneath the iceberg to consider of what it means to take this on. And aside from an iceberg, oftentimes they're also discussing how it can be similar to the question of buying or renting a house. If you decide to build your own tool, it's like buying a house because if there's an issue with the toilet and things are flooding, it's on you. You need to get the support, you need to fix it. There's if you're renting, you're renting, you're using it. You get to enjoy the service of somebody coming in and fixing those issues whenever they may arise because they're normal. And n it's not on you because it's not your house 100%. So to conclude our discussion, I think now maybe just to summarize what we have laid out so far, let's think about an organization or a company that is listening us today and it's currently debating about this. Should I build the software in house? Should I buy or subscribe to a SaaS platform? What do you think? I know, I think we already did a pretty good job at laying out all the considerations. But like as a summary, what do you think are the quick questions for these organizations to make that decision? I think the first question is one that we haven't explicitly discussed, but it is what is your organization's mission? What is your mission in general? What is your vision for this year? Three or five years down the line? If you were to envision that you had this software tool, this functionality, whether you build it yourself internally or you leverage an existing tool, how is it helping you get closer to accomplishing that mission or your five year vision down the line? What are those bigger goals? And then from there you can go further to assess some of the questions that we were discussing. How do the bigger goals feed into the technical requirements that are needed? How unique are those technical requirements? Who do we have on staff? What do we want to leverage their expertise for? Do we need to hire more people? If we hire those people, what do we want them to do? How do we ensure that they enjoy being at the company and we're all working together towards the same goals? What are the end users requirements? And just thinking through the long term consequences, downstream effects that we've been discussing about maintaining it, what is it worthwhile for us to maintain? And I think at the very end really this conversation is about build versus buy. But that's a false dichotomy. It's not a zero sum game as you can only do one or the other. As in this day and age, vibe coding is getting really popular. There's so many AI innovations that are enabling people and democratizing the process of being able to build your own platforms. Really what we're seeing is that people are not reinventing the wheel from scratch. And that's the smart way to do it. Build upon what already exists and customize it to that extent. And that will enable you to go further because it answers the question of the long term maintenance of where is this being hosted, who is managing IT, security compliance, etc. Whereas you get to play with the functionality stuff at the top. I've also used an ice cream metaphor of like an ice cream sundae. If you're making an ice cream sundae at home, one thing you can do is you could actually make the ice cream from scratch. You could if you wanted to, but if you have kids and if you're short on time, probably the fastest, most fun way to do it is to get amazing ice cream from a place that does it all the time, bring it home, and then have fun with the toppings, the whipped cream, the sprinkles, chocolate, fruit, whatever you want. But that can be what you do with vibe coding, that can be what you do with your in house team. Because not only is it maybe the fun, shiny, original stuff that isn't already being done, but it could be a really incredible new innovation. And not only that, is it could be faster. And if we look ahead into the future, do you think that this build versus buy conversation will look different even in five years from now, for example? I think it will. As innovations with AI, as we've been discussing, things are changing very quickly and hopefully over time it's going to be even more flexible or nuanced. Of a discussion of it's not so black and white as it has been for the past couple of decades, but it will be more nuanced. And I'm excited to see what new creative innovations we see in our space and organizations that are looking to make an impact, whether those are nonprofits, research institutions, market research institutions, all kinds. So I have been really impressed and amazed with the innovations that we've seen. So I think one example we can mention publicly because they've also shared it in another podcast episode. You can listen to that one after this one is with an organization called Nyaka and they essentially built an EMR mechanism using survey cto. So in that conversation it could be buy an existing EMR tool because there are tools on the market that are EMR platforms. The other option could be build one custom in house from scratch. But Nyaka is a very small organization, small nonprofit that's conducting health and clinical trials for women and children across Uganda. And so with their small team and their resources, they chose the happy medium they chose. Let's leverage Survey cto. But we will build our workflows that will match what an EMR system would provide us, because even buying an existing EMR system, those are quite expensive. And so that was really incredible that they chose to make the system make the mechanism within Survey CTO itself, and it has empowered their projects at a reasonable price in a sustainable way. So I think that we're just going to see more and more examples like that popping up. Definitely. Thank you so much, Maria for joining me. It was a pleasure discussing this with you. Thank you, Marta. Likewise. It was fun. That wraps up today's conversation with my colleague Maria. Today we broke down four common beliefs around the build versus Buy debate in House gives us exactly what we want. Why chasing 100% uniqueness might not lead to streamlined innovation in House is less complex. The reality of knowledge transfer and the ongoing burden of maintenance in House is more secure. The massive compliance and audit hurdles required to prove your data is truly safe in House is cheaper, unpacking the iceberg of ownership and the hidden costs beneath the service. Check out the show notes for links to resources and don't forget to subscribe. Thanks for listening to Survey and Beyond the Data Collection podcast by Survey cto. If you want to learn more about how Survey CTO helps organizations collect reliable, secure and scalable data anywhere in the world, visit www.surveycto.com. and if you are a fan of SurveyNP beyond, consider leaving us a rating or review on your favorite podcast app. Your feedback helps more listeners discover these conversations and stay connected to the latest thinking in data collection. Don't forget to follow us on Apple Podcasts, Spotify or wherever you get your podcasts so you never miss an episode. On behalf of the entire Survey CTO team, thanks again for joining us and we will see you next time.