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

Build vs Buy with Maria Pervova Transcript 

Maria [00:00:01]: Yeah. This is huge. We left the best for last. If your team built it, then you know how to use it, and it will be easy for everyone to use it. We go through an annual SOC 2 audit where a third-party auditor comes in. I think that we’re just going to see more and more examples like that popping up.

 Marta [00:00:22]: 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. 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. And just to share upfront, the idea is not to make a case whether one thing is better than the other, but it’s just about sharing our experience and our insights about these very common beliefs that we have been hearing from users, from prospective users. So, it’s mainly about our experience and angle on this discussion. 

Welcome Maria.

Maria [00:01:29]:  Hi, Martha. 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 5 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.

Marta [00:02:09]:  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.”

Maria [00:02:34]:  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.

Marta [00:03:34]:  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. Because, usually, internally, these companies 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 functionalities 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 usually have a gatekeeper. We have a product manager. We have a product road map, 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 that 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 service; it’s your example. There are plenty of others, I’m sure. We have field plug-ins, 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.

Maria [00:05:39]:  Yeah. So in that example, if you find that your technical requirements from a data collection perspective, how you want to manage security, integrations, etc, 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. They’re more of an open system where you can do something such as a field plug-in, or you can leverage integrations and focus your IT team’s time on those aspects. So, I wanna 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 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 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 and 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.

Marta [00:07:44]:  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’s needs are 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 have processes to make sure that they are evolving, to make sure they have a dynamic product road map. So, it’s a more dynamic environment for these organizations.

Maria [00:08:37]:  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 software, you need to manage the hosting, whether it’s going to be cloud-based hosting, or whether you’re going to pay for the hosting and manage it yourself. There’s also security monitoring features, building security into the platform, and 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 plug-ins, 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 SurveyCTO, as an example, we have thousands of users, and so we focus on those foundational basics that maybe are 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, we previously had a very energy-expensive digestive system. Like, 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 get those nutrients out of those leaves. And this hypothesis states that “As we began to eat more nutrient-dense, calorie-dense foods, our digestive system shrank, and our brain increased.” And that is one of the things that makes us different from any other animal in the kingdom, right, is how big and robust our brain functioning is, our human intelligence. And so this connects with opportunity cost because there’s a certain amount of energy available for the organism, for the body. But how are we gonna 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, that has enabled us to actually change the way 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 in 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 wanna work on?

Marta [00:11:29]:  Yeah. I like that. I really like that perspective. I think I just wanted to share one more thing under this point. And this is also related to 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 that, 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 you just have a bunch of different datasets that are a mess to merge and 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 prebuilt 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 it’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.

Maria [00:13:19]:  Yeah. That’s a really good point, Marta. And I think many conferences that you and I have both attended, data silos seem to be a common theme. There’s at least one session at most conferences we 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 gonna be using. So, considering integrations is so important. And I was just filling out a proposal, actually, for our 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 SurveyCTO, it’s probably not the only tool you’re gonna use, and we encourage you to build it in and make those connections so that you can actually accomplish your goals, which way you require more than one tool.

Marta [00:14:14]:  Okay. I think we are ready to move on to the second common belief. 

Maria [00:14:18]:   Let’s do it. 

Marta [00:14:19]:  Let’s do it. So, the second one is “In-house is less complex to operate because we built it.”

Maria [00:14:28]:  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 is going to be developers. It’s gonna 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. We’re good. You know, we’re going off on vacation. You have to be able to maintain it. So, fixing bugs, taking internal support requests, and hopefully innovating. That’s the whole point of building your own tool, right, is having the space and the time and energy to create something new that doesn’t exist. And then if you’re also gonna 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 increase drastically.

Marta [00:15:54]:  Yeah. And to add to that, I think this comment might be very general. Obviously, it’s not the case for everybody. But in general, software in-house, I would say, the user interface and 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 also know that going to a SaaS platform also requires a learning curve. Absolutely. If you are adopting any new software that requires a learning curve. But you can consider platforms that already have good training materials online. You can consider platforms that have services that can provide you with tailored support, good support, and responsive support. It can also tailor private training 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.

Maria [00:17:37]:  Yes. I completely agree. As oftentimes, that may be something else that is not considered in 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. And, 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. 

Marta [00:18:16]:   Anything else to add about this common belief? 

Maria [00:18:17]:  I think maybe something else to keep in mind is the flexibility, as if you build your own in-house tool. You know, maybe some advantages of that may be that you can customize everything. The front-facing team, the end users, 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 platforms, they are intuitive to use and flexible, so that things are not hard-coded. You know, if we call something one thing, if we call this a banana, but we actually wanna talk about plantains, we don’t have to put in a request to 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, which is what if you have to make changes throughout and how frequently do you have to make changes? What if you wanna experiment with new workflows, new business models, or new projects? How long will it take you to get those off the ground?

Marta [00:19:18]:  That’s a great point. Moving to the third common belief, “In-house is more secure because we control it.”

Maria [00:19:27]:  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, like most of these points, it’s about what do you wanna take ownership of or what do you want to hand off. And oftentimes with security, this is a technical question. Are you building 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 SOC 2 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, etc. And this takes several team members, maybe 3 to 4 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 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.

Marta [00:21:43]:  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.

Maria [00:22:11]:  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 may 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 offer At Rest and In Transit. That’s just a 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 a 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 the SaaS platform or if you’re building in-house, those may be some points to keep on your list.

Marta [00:23:19]:  OK. The fourth common belief is “In-house is cheaper.” And I would say this is a big one. Right, Maria?

Maria [00:23:28]:  Yeah. This is huge. We left the best for last, but 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 gonna 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 gonna build your own tool, it’s the building. How long is this gonna take? How many developers do we need? But then there is maintenance. 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, and 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 may have support requests. They may have troubleshooting technical support that they need, training, putting in bugs and feature requests. It’s just a lot beneath the iceberg to consider 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. 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 natural, but it’s not on you because it’s not your house.

Marta [00:25:13]:  100%. So, to conclude our discussion, I think now, maybe just to summarize what we have laid out so far, let’s then think about an organization or a company that is listening to us today, and it’s currently debating about it. Should I build software in-house? Should I buy or subscribe to a SaaS platform? What do you think? I think we already did a pretty good job at laying out all the considerations. Like, as a summary, what do you think are the quick questions for these organizations to make that decision?

Maria [00:25:57]:  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 5-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 that 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. Just 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 fun stuff at the top. I’ve also used an ice cream metaphor, 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, you know, 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, it could be faster.

Marta [00:28:45]:  And if we look ahead into the future, do you think that this conversation, this build versus buy conversation, will look different even in 5 years from now, for example?

Maria [00:28:58]:  Oh, I think it will. As innovations with AI, as we’ve been discussing, things are changing very quickly. And, hopefully, over time, it’s gonna 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 non-profits, 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 Niaka, and they essentially built an EMR mechanism using SurveyCTO. So, in that conversation, it could be to buy an existing EMR tool because there are tools on the market that are EMR platforms. The other option could be to build one custom in-house from scratch, but Niaka is a very small organization, a small non-profit 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 SurveyCTO, 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 SurveyCTO 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.

Marta [00:30:50]:  Definitely. Thank you so much, Maria, for joining me. It was a pleasure discussing this with you.

Maria [00:30:56]:  Thank you, Marta. Likewise. It was fun.

Marta [00:30:59]:  It wraps up today’s conversation with my colleague, Maria. Today, we broke down four common beliefs around the build versus buy divide. 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 cost beneath the service. Check out the show notes for links to resources, and don’t forget to subscribe. 

Outro [00:31:44]:  Thanks for listening to Survey and Beyond, the data collection podcast by SurveyCTO. If you want to learn more about how SurveyCTO helps organizations collect reliable, secure, and scalable data anywhere in the world, visit www.surveycto.com. And if you are a fan of Survey and 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 SurveyCTO team, thanks again for joining us, and we will see you next time.