S1E16 - Podio Deep Dive 2b: "Building SaaS That Businesses Can Rely On - Part 2"

Gil Roberts: 0:03

Welcome to the podio solutions podcast, season one, episode 16. I'm Gil Roberts and with me today is our lead developer here at Brick Bridge, Alex Shull. And our principal consultant, Jarett Duker. This podcast is about the design and development on the Citrix podio platform on at Podio, podio.com. We use this podcast to discuss your own experiences with podio as well as other interesting topics from the podio developers community, your podio designer and developer working at an agency, small business or enterprise. You should immediately hit that subscribe button if you have already. Thank you so much for your support. Lastly, before we dive into today's topic, if you have a topic, issue, solution, problem or anything else you would like us discuss , uh , send us an email or a message to podcast@brickbridgeconsulting.com or hit us up on our linkedin, Facebook, Twitter and other accounts. Today's topic is the continuation of our two part series here with Alex, um buildings sass that businesses can rely on , um, just wanted to , uh , I know last time we reviewed a couple of episodes back just some basic concepts and we're going to take those basic concepts and kind of Polish those out.

Alex Shull: 1:22

Yeah, we were referencing them as we discuss some of the principles that I think are important for , um , someone who wants to deliver software as a service. Today I'm using a lot of the modern tools that are available. And so this, this is not aimed at a technical audience. Um, are , we're really trying to, speaking to the people who use podio to , um, develop , um, software or other tools like it , um, and um, are not necessarily, you know, writing , um , code in c sharp or Java script the way that we do or Java or whatever. Um, but , but maybe you, you need some of that as well. And so this is , um, really reflects the way that we develop software for our clients. And I think it's just the trend of the way that the , um, the, the newest , um, available systems are being put together. Um, so as a, for the threat of the big picture , um, I want to say that the , the very first thing that you need to do if you want to , um, produce software as a service using these tools is that you need to choose what you call it , your system of record. Now this isn't a concept that we covered last time cause there's not really a cloud computing concept. It's really just a software concept and a system of record means that this is the system your best copy of the data is going to reside. It's where you rely on to have the accurate data. Some people refer to that as your golden record. And if you can imagine when you have all these integrations with podio that podio sends , um, you know, an event out in some system calls the API and gets a copy of the client record. If you go in and edit that record and that system doesn't become aware of it, then those are out of sync. So which one is accurate? Is it podio or is it the system that is now , um , different than podio? And you have to make a principal decision at the outset to say that you're going to have a single system of record. Do not design your system to where you have to pull in elements of data from multiple systems back together to understand what's actually happening. And so podio is our system of record. Um, there are a lot of other ones you can use. Salesforce is a very popular one. Um, and um, a lot of people are used to having just a database like sequel server or um, a lot of people start off excel . And a lot of very good software starts in excel. There's no doubt about it.

Gil Roberts: 4:14

In older days you'd add Microsoft access and little program.

Alex Shull: 4:17

Exactly, exactly. And so you're , your , you designed your, you choose your system of record. Um, and then that's the central position where your, your software that you deliver is going to be a satellite systems that surround that system of record. But you have to choose a system of record and you have to preserve that as a system of record. And , and I'll, I'll , we'll address them , um , ways that, that introduces itself later on . But what I want to say is, if you don't choose podio, then keep some things in mind when you do choose a system of record. Um, first of all, it must meet your availability requirements and that's different industry by industry. There, there are some cases where , um, you know, if you are doing , um, large orders that take months to fulfill, you probably don't need something that you know, is , um, responsive by the millisecond, you know, delivering every single piece of data. And, you know,

Gil Roberts: 5:18

You need to understand the scale you're working at.

Alex Shull: 5:21

Yeah, yeah. And, and you have to understand that the, the cost of higher availability and reliability is a real, and it scales out. And so , um, podio is, is good enough for 99% of cases in our experience. Um, if I were going to build a hospital , um, I might not use podio. I might want to have a system of record that's not even in the cloud at all for that matter because you have sensitive data that you really don't want to lose access to , um, cause it could affect the health of your patients. Um, and there are other cases , um , dealing with, you know, highly secure systems or um, stock market trades milliseconds, cost millions, you know, right . In that industry . Yeah. And so it's a matter of we're, we're talking about the vast majority of cases, retail businesses, service businesses , uh, ones that were , um, worst case scenario. If there's, you know, some eats out for an hour, you have a way to get around it. You have to be able to accommodate and understand how to get around it if those systems go down. And that we, there are strategies for doing that. But it's not just about podio either. Your Internet can go out either all sorts of ways where you can lose access to your system that has nothing to do with podio itself. And so , um, keep, keep those things in mind. If you choose something that has a much higher availability than Podio, you know that , not that you can get that much higher . Um, but if you were to insist on that, we'll then you're going to have to have, you know, two Internet connections because one might go down and so on. So, so keep that in mind.

Gil Roberts: 7:07

There's a cost to it, right?

Alex Shull: 7:08

Definitely. Definitely. And , and you will bear that cost. And if you're selling the software, your clients will go to that cost. So make sure you're , you're , you're choosing the one that's appropriate. Um, also, I, you should choose a system of record that offers direct API integration. Last time we talked about APIs and , um, services , um, the, the, I would say preferably a rest style of API. And that's just because the broad support that's available , um, for integrating using rest API keys . And so if there, again, you can go forward and use excel, but excel doesn't provide those integration capabilities. It has a lot of advantages for people. People really , um, rely on it and it's all, it's all on their computer, but it's not connected. And so you miss out on those advantages of cloud. Um, unless you choose a system that is out there offering the direct API integrations just like podio does. And the , the, the third point I'll make when you're choosing a system of record is that you really need to have something where it's very easy to export all of your key data. And it's not because you want to offer someone an easy way to get out of your product. But without that, there are a lot of customers you're not going to get into your product in the first place. Customers really want to own their data and they deserve to own their data. And if you can show them that what you're delivering to them, lets them get their data out and have it locally whenever they want. And it really increases their confidence that they're not being bound in that they're going to be, they're going to stay with you because of the quality and the value that your software provides. Not because it's hard to get your data out. So there are plenty of systems I've worked with where you can get it out, but it's, it's burdensome. Podio is beautiful because you get it out and it goes right into excel . It goes right into any other system. It's, you can import it into another system. You can import into podio very easily. So it really meets these three criteria , um, very, very well. And um, in our experience , um, there's not another system that , um, is more affordable and meets these criteria any better. So

Gil Roberts: 9:23

I want to make a quick point on that. Data affordability. I think that's from a sales perspective, we always have our clients ask for that. Cause I think that especially over the last probably 10 years, people don't understand that kind of hostage game that once you move your stuff into a particular database, particularly these software that they kind of have, you can't do it . So they are to move. It's just like I'm moving into an apartment and then being able to keep all your stuff, you leave early. Right. That's not a good deal. So this is it . This is reportability of the data of both in and out of Podio is, is a, is vastly superior in a lot of places.

Alex Shull: 9:59

Yeah. And that , that even goes, so I would go so far as to, you know , say that even tools like Facebook which have become very popular for businesses , um, for just outreach in the social media, maybe it's irreplaceable, but if you're using it to create events and you're using it to actually distribute content, then , um, I would, I would dissuade you from that strategy. You might use it as a , um, create that data in podio and then push it out to Facebook. But make sure you have a copy of that data non Facebook because Facebook doesn't make it easy to , um, actually own your data today in my experience. Um, there are a lot of examples like that. And so a on a case by case basis , um, you know, the, the importance of that , um, varies. But it's a very good principle I think to , to use when , when looking at your system of record especially. So the next point I would say , um, is that in developing software as a service today, you actually want to avoid writing any custom software if possible. Uh , that sounds counterintuitive, but what I'm saying, writing custom software, what I really mean is we were at last , um , podcast, we were referring to the modern runtimes. Whether you're getting a VM, a virtual machine in AWS, or whether you have a data center with your own servers or like us, you're using AWS lambda or Azure functions. Yeah,

Gil Roberts: 11:34

they're pure cloud.

Alex Shull: 11:35

Some, some weird there to actually run the code. That's what I'm talking about. That's what I mean by custom software. In this case, it's your, your, you are selling a software system as a software as a service, which is... Yes. That's good. So your solution is a custom solution, which might have elements of custom code in one of these r un t imes, b ut you really want to avoid bringing in one of these run times if you can. If you can do it i n podio. Again, we have t o w rite custom code because we e nded up integrating with systems, u m, that don't provide native, podio support. U m, b ut we have, you know, y ou talked to the HUD agency using soap for one of our main products and that's not something that can be done without, u m, code writing in i t a nd a customer.

Gil Roberts: 12:28

Yeah , we tried to pin those highly custom intends to be integration. Right. And it tends to fall on the integration side of things, not really the , the workflow side of things. Um, but we try to keep those as limited as possible and because they do require some investment, right, that there was an investment to get that operational and keep it operational. Right. Cause you have maintenance and other thing that's, that's going to happen with that. So limiting what you build. Like I would say off platform.

Alex Shull: 13:00

Yeah, that's a good point. I mean, in our case, we have our Sassafras platform. You know, we're , we're a pretty technical company , um, compared to who I really speaking to in this case because you can use globiflow and podio and you can do a lot of amazing things. And you will never have to have a, your own run time out in the cloud. And so when we build Sassafras that's really equivalent to globiflow, we , we have a very standard model for maintaining and running our code, that environment and it's become our platform. So we're, we're, we're the vendor but um, it , we really use it just like you, we would suggest you use globiflow. Yeah . Um, so, and, but more to the point, the reason, another way to think about this is that writing custom software is usually not the way that you're going to differentiate your product from other products. What's going to make you special is how you design your work processes and your business methods. And those have to do with the entire flow of the data. Those have to do with your, how you engage with your customers, that those have to do with , um, how you , um, maybe follow up with your customers and , um, um, cross sell and , and things like that. Um, it , it's something that you can take those processes and methods and you can put them into the solution. Um, you need to think about those processes and methods and your solution. Not an not in terms of the custom code that , um , enables them. Um, and that's a , that's a confusing point, but for this is something that Jared really does when we're engaging with is that really walks them through the entire work process, walks them through the design, asks them a lot of questions about how and why and gets those ideas down. And once you map those out and you see them all and you break them down into their elements, you find everything that you can do without having to write custom software and you, you have to be almost maniacal about it. And sometimes, you know , you get into a situation where, and I , we've been kind of a few people , um, like us who said, well, I figured out how to submit this works on Podio, but it's kind of a hack, you know? Right . Like you have to, you know , um, throw together, you know, hundreds of lines of PHP and the globiflow, or you have to pack a whole lot of Java script into a calculation field. And I don't know if I would put it in globiflow. It may not like me encouraging that, but it's the honest truth is that that if you this the fastest path to getting your functional software and to get your vision created, even if it is a hack, it is a better way to move forward into the feature delivery than writing custom software because the first thing that you need to do is get the test from the client anyway from the, from the users anyway and more often than not you'll either have to change it or modify it so when you write custom software you really have to have a commitment where it's going to be leveraged a lot. The last thing you want to do is write custom software that doesn't get used. That's very, very expensive

Gil Roberts: 16:29

foreign investment .

Jarrett Duker: 16:31

An interesting thing is the only situations where I come across that really requires that custom software touch, even if the solution is a little bit hacky is one. When speaking about government compliance, if you're trying to integrate with a long established system, almost always government, it seems to be that just they are inflexible and you have to meet their standards. You've got to go custom. I don't, I don't think you're getting around that almost in every case. And the other one is when , uh , there's an element in the equation that is again, just completely inflexible. This has frequently to do with custom reporting. They want things just so, and they're not willing to change their process any to accommodate a quicker solution. Uh , it has to be just like this. No compromises, no changes, no alterations to formatting or anything else. You're probably looking at a custom solution. But if everyone is able to maintain a little flexibility and keep their eyes on , uh , effective and quick workflow and not necessarily on the way things used to be, or it must be this way for well , frequently legal reasons, you rarely need to dive deep into a custom build.

Alex Shull: 17:45

Yeah, I agree. And that's something that , um, as a software developer , um, you will find a lot of people will say, Oh , I can do that. I can write that and they can write it. But you have to ask yourself, does it really make sense? And in vast majority of cases, if there's a way to do it without writing custom software, it's better to try that first. And again, the, there are principles for putting that software in podio or globiflow where the functionality is actually very well I'll say encapsulated in a single flow for instance, where you have um, a certain, you know, set of flows that are triggered by an event on one application in your solution. And you can have a lot of kind of hacky pieces in there. Well, the, from the standpoint of software design, that's actually very beautiful because you can then replace that. Should you need to in the future, you can replace that and just tie it into that same event where you had that software responding anyway . And so there there's this design principles that let you approach it this way without creating risks for the future of your software. And it really has to do with um, the application look , the solution level design of your workspaces and your applications. It really comes it from that level where in terms of , um, where are those custom pieces come into play? As an example, when we have an integration with um, a government agency , um, our podio system creates all of the entity , manages all the data, it's our system of record and then we have a dedicated module that is responsible for um , making the request to their external system to say we're ready for the integration. The external software comes in and pulls the data . It needs out and performance integration and reports back to that custom model. So everything that happens for that custom integration has been interfaced through a single module responsible for that integration. Now, if we had been able to hack it through and not I custom software, we still would have gone through this custom module because it isolates the complexity behind a single small portion of your system. And then you can replace it later and the rest of your system is preserved. That's the, that's the idea. Um, so again, you , you want to , um, take your, the differentiation of your software, which is your process in your methods and you want to build it into your entire solution around those key events that , um, drive the business. Yeah, exactly. Um, that the , um , the next point I'm gonna make is , um, actually somebody I was reading about recently , um, I'm , I'll , I'll go say the principal is this only integrate with systems that support synchronization. And by synchronization, I mean that data can go both ways. Um, what I mean by this is , um, if you are going to, let's say have a , um , payment through stripe. And so you have to , um , build an integration that lets you , um, have people pay by credit card after you pay by credit card stripe pass to make that a data available to you to bring back into your system of record. If you find yourself , um, integrating with a system where the data goes out of important events in your business happen and you can't get that data back into Podio, well then you just violated your system of record. You, you've made it to where you have to go look at that system and podio in order to know what's actually going on with your business. And that's, that's, you should avoid that at all costs. And the recent example that was in the news is , um , Shopify, which is a very, very , um, popular, maybe the most popular u commerce platform today , um, recently banned MailChimp from there . Um, add on store, whatever they call it . And if you , if you read into it, a lot of people were upset. It's very, mail chimp is very popular. Um, but the reasoning behind it was they're , they have new requirements that the Shopify, Shopify has new requirements that an add on. If, if you send data out, then it has in, it changes the data, the data changes, then that service needs to send the data back to Shopify. And for whatever reason, I don't know, MailChimp wouldn't comply with that. And that, you know, MailChimp is a huge business. They probably didn't care.

Gil Roberts: 22:36

Yeah, I just looked out. MailChimp is you to statement a last night , they're kind of like throwing shaded each other a little bit. It looks like they've been attempting to negotiate and mail chimps stance, a privacy stance for home for their users to have complete control over their data.

Alex Shull: 22:53

But see that, and I'm not on their side in this case and I would really avoid relying on a company like MailChimp in this case because as the business , um, and as someone who is selling software to another business, the integrity of your system of record is more important than whatever they're addressing because it's still your data. And if they're not respecting that it's your data, then I don't think they're , there are a partner that you should rely on. And in the case with Shopify, it actually has to do with the do not subscribe issue that if someone gets marketing email from MailChimp and they say, do not subscribe, Shopify doesn't know that. And so if you use multiple systems from Shopify to send out marketing email, they , that you had a compliance yeah, you can be in violation, you and GDR and things like that or, or you know, very , very serious , um, you know, issues and

Gil Roberts: 23:47

governments need money. They're going to pursue it.

Alex Shull: 23:50

Yeah. Yeah.

Gil Roberts: 23:51

Especially companies that large . Look what they're doing to Facebook and some of these other companies got hit with a large one recently.

Alex Shull: 23:59

Absolutely. So that's the, the specific case for Shopify. But as a principle , if you just think about it as your system of record, you do not want to let a third system modify the data and it in a very important way and not get the results of that back to your system of record. Um, and you know, there a lot of cases, if you're pushing out a report, you're sending out, you know, a mailer, whether there's no modification of data because all you've done is you , you know, you might call an API and say, send this customer a gift card. Well that's fine. You know, there your hardships and, and , um , that , that's probably adequate. But if you know, it sends out a form and your customer fills out the form and you don't get that data back into podio, that's probably not the approach you should take. So that's the , uh , the , the third principle that I wanted to, to share. Um, the, the next , um, principal , um, it has to go back to when you do need custom code cause cause you will need custom code in certain instances. It's, it's, it's, it's true and that , but the key is to try to make a run on demand as much as you possibly can. Just like the way Zapier. Um , just like , um, most of the podio runs on demand when things happen, events are picked up by the API and code is executed and those automations in globiflow. That's just how they happen. Well, lambda is the same way. Lambda, when you integrate it correctly with Podio, a little event goes off from podio. When an item is created, you can get your lambda to um, handle that code and then when it stops running, you start paying for it. That's the main principle is that you don't want to have to pay for servers. Um, you don't want to have to pay for infrastructure. You don't want to have to pay for the network and all those pieces unless you're actively using them. And this is a, this is an initial phase one . Once you have a million customers, then you can hire a team to reduce your costs by building out some infrastructure. But when you're building your software , when you're designing, you at the outset made sure that you can run your code on demand. Um, and that way it's not only is it scalable, but you have very, very good cost controls and you also have a very, very good agile development cycle where you can iterate without worrying about , um, blowing up infrastructure costs or without having to replicate multiple environments. It's , um, it's a , it's a great new technology and um, really need to take advantage of it. Um, if you do require custom code.

Gil Roberts: 26:47

Yeah, I've seen it , uh , just, just in our practice over the couple years that we've instituted, I mean, the cost savings is when it comes to maintenance or stuff that runs on it . I just, just for that alone is a , is a good reason to take a serious look at it.

Alex Shull: 27:02

Absolutely. And you know, the another interesting point, I was talking to a developer , um, in this area who works for another company recently and he , and he was telling me that I was asking, you know, talking about we use lambda and um , and I was asking whether their software is in the cloud. And he said, no, we have around data center. And I thought, well , have you ever thought about moving to the cloud? And um, he said no because their CEO , um, was , um, put off by the costs . And I thought that was really curious. But then when , when it came down to it as they had already sunk a lot of money into a data center and they had extra capacity. And so it was, it was to the, in the mind of the CEO, it was free to use the data center they all already had. But you know, he's ignoring the operating costs. He's ignoring the op salaries. Yeah. And also the productivity of the developers who have to worry about, you know, network issues and, and on and on. But at the same time, that's, that's an , that's a very common mindset. And , um, if you are in a situation where those are your constraints, then you probably have to just work, work with them. Um, but at the same time , uh, the guy I was talking to and he said, truth be told, if we were starting from scratch today, that's absolutely the direction we would go. But once we set off in this direction, investing this money in hardware, he couldn't get a CEO to pull back from

Gil Roberts: 28:37

I , he's got that , he's gotta justify some type of return . So here in five odd years and then, then that's the next, right .

Alex Shull: 28:45

Cause there a depreciating costs. They're looking at it as a, as a capital investment, which doesn't make me , and your business isn't any more successful. It's a way of like, you know, you can do some, there are some tax benefits and things like that, but if you want to really scale things up massively, then you're at a disadvantage....

Gil Roberts: 29:03

Right. This is the , this is the way things used to be. And there's still, there's still a lot of that.

Alex Shull: 29:09

Yeah. And , and you know, no fault to them. They're there , they have a very successful business and , um, they, they know how to, how they're doing things. But at the same time, if you have a choice of the outset, you want to avoid going the direction you want to have as light a touch on infrastructure as you possibly can because maintenance of infrastructure is, is a, is a cost to your business and it's a threat to your agility as well. Um, so , um, the, the run on demand opportunity , um, makes it much more possible for you to compete against these people who have some costs in infrastructure. Who cannot find a , a way to justify moving into the modern, you know, world of cloud computing. So take advantage of that. You know, the, they have the, what is it called, the late mover advantage. Right? Um, and what I would say beyond that though, is that if there is a situation where you have to invest in and structure into infrastructure that isn't on demand. As for an example, we have , um, aggregate reporting capabilities , um , for , um, some of our solutions that are not directly supported by podio. And , uh, so we have to maintain databases and our clients pay those costs directly. We are not attempting to , um, meter out those costs into a monthly pay as you go. We , we pass those costs on wholly to say, we developed this software for you and here's your infrastructure bill. Um, they're there . The convenience of that from the standpoint of you as a, as a software , um , seller is to first of all, make sure that your clients know where certain costs are coming from. And, but , but second of all, it's , um, you know , it's a way of protecting your own. Um, you know, expenses because if you, if you attempt to do the , the, the metering and the estimation, you can get a wildly wrong, you've or you might, you end up , um, disappointing your , your customer's expectations. Um, and then obviously if you invest a lot in , in the engineering and you can work around those issues, but for the , the people that we're talking to , um, you really don't want to, you don't want those complications. What you want is you want to differentiate yourself, differentiate yourself based upon your processes and your methods. You don't want to differentiate yourself on the basis of having an infrastructure investment because guess what, there are lots of people who are better at that than you are. It's not, it's really not where you're, you're, you're making your , um, your value. Um, so that those are , um, the four main points. And the , the last point is a , a very , um , different direction. But I think it's a very important one to anyone who's in the software business and anyone who is reads tech news or is aware of what's going on on the Internet. Um, which is basically you are not a security expert and you have to be very afraid of hackers and that, that , you know, not to be alarmist, but you have to have the mindset that your systems are under threat and that shouldn't lead you to not develop software. What it should lead you to do is to consider some of the other things in terms of the , um, the principles we've outlined using the system of record that is on podio gives you a lot of comfort in terms of your security exposure. You, podio has, you know, Citrix behind them. They have a security team who has , you know, top notch. They are always making sure that. And they know way more security about me and they're there . That is their job and they have to invest all those efforts in securing the whole system. There . Any time that , um, you stop relying upon their expertise, you're creating an exposure that really doesn't provide you a benefit. And so, but beyond that, the , the way that this really applies is when you start looking at those properties for the entire solution that sit outside of that platform. Because again, don't write custom software and unless you really need to buy , you know, by extension, that means that you're going to be either using integrated services or podio to implement that functionality. And so that kind of addresses the security concerns. But when you do have to step outside of that, you have to be very afraid and you have to make sure that you're not moving data around unnecessarily. You're not storing data unnecessarily. And beyond that, that , um, your business , um, in a , in any software as a service , um , scenario should be associated with a very well known domain name. And that means that when your customers are receiving email from you, when your customers are , um, clicking on links to your site, when , um, your customers are , um, you know, getting updates about , um, you know , uh , other, other things that are happening, you really want them to have a strong association back to the domain name that you own. The , your ownership of that domain name is one of the only ways in which your , um, software property becomes , um, you know, reliably identified on the Internet. And the, the, the, the, the corollary to that is that in all those cases, everything should be , um , secured under SSL and that means it's https, not http . Um, this is something that has changed in the past five to 10 years where it used to be that on Google. Some other , um, elements would come over just HDP like images and some other things in a page because it's slightly faster to do http and https.

Gil Roberts: 35:29

You don't have to clear the security part.

: 35:31

Yeah. And so it's easier, but Google moved away from that. You're not going to find any anything on that doesn't go variation https . Now it's all secured. And the reason is that as a principal , if you secure everything , um , you're just in a stronger position because one of the easiest things to do is to confuse those two connections and then suddenly you're leaking data over a non-secured connection. And that, I don't want to get into the technical aspects of how that's done or what that can expose. But if you're a first principle is that at all times people are going against a secure connection. You eliminate that at the outset. And that means even on a marketing site, when someone is not logged in, when they're just going through and , um, you know, looking at what features your product offers and then they're clicking a link that says, yes, I'm interested, or something very innocuous like that. If you don't have that secured , um, then there are all sorts of ways that , um, that initial connection can be exploited to then , um, learn information about your clients or about you or about your systems. That could either be exposing access tokens or , or other keys data. And even if you, even if it's not today, as your product evolves, you might make a mistake later and then inadvertently exposed something. So if you just go SSL at the outset, over everything, then you don't really have to address that question. It's just a good first principle to say you owned your domain name and it's all a secure. Um, and that they're the one that their aspect I would say about , um , the marketing site that I think is irrelevant. Um, and I , I believe Jarett, um, spoke recently about the aspect of building a marketing site for , um, you know , um, putting , uh , a , um, solution out of podio that you can sell and how important that is to the, you know, building a software business. But one of the things I would say is that wherever you host your site, the host is the one who's running it for you on the Internet. Um, you have to make sure host is, has a very good practice of keeping their servers patched and secure. Patches are regularly really now , um, you might have plugins on wordpress site, you might have , um, just wordpress has vulnerabilities that itself, your, your host has to keep those things secure and you can go and you can um , find their , their policies. You might have , uh , some local , um, um, one team that does hosting for you. You need to ask them about their , about their patching practices. You need to make sure that they're keeping things secure because when those exploits come out on the Internet, the hackers know about them before you and they will attempt to exploit them as soon as they know about them. And you have to get your site patched critically within days at a minimum.

Gil Roberts: 38:45

Well, the hackers know that they only have so much time, right , because they know that people are going to start patching.

Alex Shull: 38:51

Yeah. And what would the zero day exploit where there has been , um, where the vendor of the of the technology is learning about the exploit at the same time as everyone else on the Internet. There's this mad rush to find a way to secure things before they get exploited. Well in the case of wordpress or some other technologies, I'm not picking out wordpress only because it's extremely popular. That's the only reason I mention it. It's a great platform. No offense wordpress, it's just because you're so successful. Um , but the, the, the idea is that a hacker can write a program that just scans the Internet looking for a vulnerable systems and they don't even have to know who you are and what your name is. If they find that you're , you have a vulnerable wordpress site and they can exploit it, suddenly they can inject a back door into your server. And whenever someone comes onto your site, they, they're able to , um, insert code onto your client's machine. And it's not your fault, but it's your customer. And if your customer ties that back to you, they're not going to care that it wasn't your fault. And so it's your reputation that you're protecting. And so if you take the time to make sure you're picking a hosting provider that has really good patching practices and is always like, I'm applying the latest, then it's really gonna pay off over time. Um, the last thing I would suggest doing is trying to host your own site. It's, it sounds like it's a good idea. He used to be a great idea. It's just not a great idea anymore. That's not your business. So look for a provider who , um, patches their , their servers, patches everything regularly and um, you will rest easier and your business will be better for it.

Gil Roberts: 40:44

I know just performance and the call , the performance has gone up so much now and the costs gone so low, it's just kind of ridiculous. Yeah . I mean not to, unless you're just a hobbyist or something like that, which in that case, you know, you're gonna run into scale issues at some point as well. Alex has a lot of information today. I just kind of want you chew through it. I think this has been very valuable for listeners that are trying to wrap their mind around how they should make the product stable and the way that they should choose the route that they achieve. That stability, uh , so that build solutions that people can rely on and do their daily work. Uh , through that. Uh , is there anything else you'd like to add?

Alex Shull: 41:31

Well, I, I, a lot of the thoughts that I'm , I'm trying to introduce , um, in today's podcast are ones that , um, I will be returning to in the future. So it's , it's really a , an important context to understand how we think about software and not some of our design decisions. So , um, hopefully in the future when you know, we, we speak to the system of record or security concerns or you know, the, the decision to add custom software, these principles are ones that , um, people can keep in mind and understand why , um, why, why we espouse these principles. Um, it really has to do with understanding the, the, the nature of the entire solution you're delivering and where you can deliver value. So

Gil Roberts: 42:20

interesting . Bookmark this one and part one. We need to revisit some of this as we continue to do our podio deep dives on the technical side. Thank you so much for relaying a lot of excellent expert knowledge that you have today for our listeners, Alex. Uh , you did give away a little spoiler. We're going to be doing a Jaretts next episode with us talking about the packaging and the market.

Alex Shull: 42:43

Oh, there you go.

Gil Roberts: 42:44

So we're releasing that next week. Yeah, that'll be a , that'll be on episode 17. We're gonna dive into a podio product packaging talking about. What's podio sellable solution? You know, website, the docs or documentation, those types of things. So, but that does it for us today. Remember, if you have not already, please, please, please subscribe to our podcast . It helps us more than you know , um, and if you are a podio designer or developer , uh , we're still, looking for more podio gaps . We've got another gaps episode coming up, here shortly. So get those in , uh , if you haven't already. Also check out our social media on Linkedin, Facebook, Twitter, and like otherwise in that, that'll wrap us up for the week. So thanks fellas.

Alex Shull: 43:31

Thank you.