SaaS (Software as a Service) and its benefits

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we're getting back into interviews. This is actually part two of an interview with Irina Podobnaya of Track Mage. In episode one, or in part one really, which is also episode one, we got to know Irina a little bit and how she got to the concept and sort of the early ideas in the creation of Track Mage. And now this episode, we're going to continue that discussion and start off with really more of a focus on software as a service, why they chose it, some of the benefits. There's really not a lot of cons, mostly pros in this conversation. And then we get into a nice little bit of a sidetrack, almost we digress a little bit, it feels, but in a very, I think, useful way because we start talking a little bit about sort of like debugging problem solving and getting the right information from your users or the proper feedback to be able to properly track down a bug or an issue and then solving the actual problem as opposed to maybe a Band-Aid approach or something like that is actually getting to the source of the problem and fixing that as opposed to other ways that we may essentially try to use duct tape and bailing wire to make something work rather than fix it at the source as it were. So that being said, I think it's a good time to get back into our conversation with Irina and we'll talk to you at the end of this. Yeah, that'll be great. Something like that, it's always great to be able to tack that on and give them, like I said, especially because it's small businesses, they don't need an enterprise warehouse management. They really just need to do simple inventory and make sure that they can pick something off it or virtually pick something off a shelf, ship it. Just one thing that I've been really like, I find this really funny because when I opened some solutions to really understand like how do they handle inventory and I opened SAP, it's a whole world of new vocabulary. Like I don't even understand what we're talking about in their documentation. They're like, what? People actually use it. That's probably the same approach that Shopify took compared to all the other enterprise e-commerce platforms. They just simplified it to the point where it's usable. Yes. Do you need to be technically savvy to use it? No. We are going the same route. So that's why right now I'm probably on the fourth redesign of the admin panel. So we're going to be way more user friendly going forward. Yeah. That's something else I found with a lot of the SaaS solutions is that because it has that entry level that's essentially zero, like a company just starting out, so it doesn't have maybe even a lot of business experience in whatever that area is, catering to them also gives them not only something that's a low cost, but easy to understand. It's like we're not going to flood you with all of this information that you would need if you're a multi-billion dollar industry, because you don't need it. You don't need to know all that terminology. You don't need to have all of those bells and whistles. You just need to be able to sell your product, market your product, sell your product, ship your product, and then customer support. Yeah. I guess the most sophisticated business logic solution is the actual Excel spreadsheet. Because in Excel spreadsheet, you can create whatever logic or whatever structure you need. The problems, they start when you need to maintain it. I guess the solutions, they need to have the functionality or the majority of use cases, but all the edge cases, that's why those enterprise softwares, they are so complex and they have a lot of functionality that typical users don't even need or use or know about. Because they handle all those special cases. They had, let's say, 400 customers with different use cases, and they just implemented every one of those 400. But for a typical user, it would be like one or two. Yeah, that's true. If you don't get into, if a lot of your customers aren't edge cases, you don't even need all that kind of stuff. You can get that 80-20 rule, get most of your customers, and then if you're small enough, you never actually get out of that comfort zone, basically, of a solution. Or if you do, you will regret it because maintaining that code, writing those unit tests, like, come on, we don't need to get to conflict. That's true. I think there's been a few of those where people have been in those situations. People say, if we could get rid of this one customer, our life would be so much easier. Yeah, on a related note, at some point, we were considering how we're going to scale the solution and we were getting into this like sharding the database, putting it on different servers, pulling in Kubernetes, like all this stuff. And then we just realized, like, but wait, we just don't have that kind of load yet. Atlassian did it only when they were on the market for 16 years already. And we were considering it from the get-go. I said, like, OK, guys, guys, guys, let's let's chill and we don't need scaling yet. We need probably just to handle the same customers. That'll be great, but not yet. Yeah, that's great. So we talked a little bit about why it which which makes a lot of sense to me, too, is why you almost never really consider it anything other than, you know, SaaS is your solution. So for those that are because I think a lot of people do that, particularly in the developer world, there's a lot of if you're doing a little side hustle or something like that and you're technical, it makes sense, I think, because then you've got a platform that's easier to support. You don't have to install. You don't have you just point people to your website and you're off. And and you don't have to deal with hardware errors because hardware like let's let's just be honest, like not all the hardware is the same. And we have way too many phones on the market and way too many laptops or different like different solutions. So like creating something that is like OS based, that's always a risk. It's almost like you are always running after like special cases for like different phones or for special cases for different laptops. Yeah, yeah. And I've seen that I've even seen companies that do boot camps where they want to have all the students have the same thing and they struggle to just get, you know, 20 of the same laptops set up the same way and still make those work. So, you know, it's even worse when you start when you don't control your your customers at all. They can be anywhere doing anything. So with that, what is that sort of give you like a this a compare and contrast, you can start with one or the other is what is maybe something where we're especially once you got launched, you said, wow, this was it helped us so much. We're so happy we took the SAS approach. And then sort of the flip side, is there something that was either either something that you said, wow, this was really a weakness that we didn't expect or maybe a big challenge in getting the SAS platform launched? Yeah, well, one challenge that we didn't anticipate originally was that we need good design. So we were just developing the gorgeous getting stuff done. The features worked. It looked awful, but it worked. That's ideal. Then you get back and developers designing the interface. You're already like you're already preparing yourself for a design because they just they just put the button wherever they feel like a button should be, which is like next to the other button. And then you have like button, button, button, button, button, button, button. And like, OK, how do I communicate that you need to press this button first, this button next, and then this button? Like when we were just brainstorming, we didn't even do a wireframes. And it was a huge challenge to hire the first designer, because whenever you explain designer business logic to the designer, they just don't have the mind for it. They just draw something that's beautiful, but totally not usable. So we had to go through like trial and error, iterations upon iterations. When we figured out like, OK, somebody who knows the business logic draws the wireframe like literally like pencil to paper wireframe, gives it to the designer. They make it beautiful. Then we give it back to the developers and explain like, oh, this is how it's going to work. This is what worked like only this these three steps. Like if you go any other way, you usually either try to make the designers work like developers so that you actually try to teach them basically about functionality or the business logic, or you get the developers working as designers and they say like, well, it doesn't look beautiful enough. Like it works. It works. Right. But it works. Yes. That's that's the beauty about you mentioned wireframes. That's always been the beauty of having that sort of that middle road where you can say, here's something that developers can see. Oh, I have to, you know, I have to have these buttons or this navigation. And then the designer, I think they see it with a different point of view. Anyways, they see all the things they can they can hang and make that wireframe look pretty and sort of gives you that, you know, something they can talk back and forth to a little bit and allows you to to to build it with that kind of stuff in mind as opposed to, yeah, if you do it either the other way, I've found I've run into some really fun challenges where the developers do everything and the designers are really hard pressed to make it look good because there's just there's just too much functionality or it's just not well, you know, well designed in general. Or if the designers do it where the developers like, there's no way we can make that technically occur. You know, it's stuff like we can't just, you know, create unicorns and racemodes by writing code. It's like we there has to be a there's a reality behind that. Yeah, that's a that's a great lesson to learn. A typical example would be the drop downs like on the mobile version, like everything needs to collapse into the beautiful like drop down menu. But where do you put that menu? What kind of element is going to be on the desktop version? Like the designers, they have no idea. And sometimes we have this interesting conversation, like the designer gives us the design. When I come to the developer, like, is it possible? And they say like, no, like designer remake it. Because like for the designer, it's just like, oh, yeah, well, OK. Yeah, I'll move it here. And for the developer, it's a huge deal. Like it needs to be in this deal. It needs to have this styling and on the desktop and this like I, I cannot make it appear somewhere unless I duplicate the elements, which is already a bad practice. So like, yeah, it's fun conversations. A little immediate. But it keeps it energy, energy entertaining, at least. OK, we're going to go to OK, so I guess this one and then I actually want to swing back around a little bit to the implementation. But this is sort of a forward thinking thing because you're looking at the track marriage website. A lot of what you do is we and you mentioned it like, you know, that since it's normally transactional, now you have these high open rates and there's a possibility that you can you can essentially you've got an opportunity to sell if you're thinking, you know, building your customers, improving their experience, then you can use these touch points. We know that you actually have their attention. And since your focus is on physical shipped products and then tracking that delivery, are there any of those concepts? Or maybe there's some that you can share that that you have translated for TrackMage itself, how you build your customers and maybe get improved or increase sales from from your customers. Yeah, so you're talking about the marketing for for the customers of TrackMage. OK, like software as a service marketing and stuff. I would say it's just like we always have to figure out what the customers actually want, because when you build a feature, it doesn't necessarily translate into them using it. So what we've been doing, we've been literally just stocking those customers. So we use we use a thing called post hog. I don't know why they called themselves like that. It just doesn't have anything to do with post or hogs. It's about behavioral tracking. And it's the alternative to hot jar. It's an open source solution where you see what people are doing in your software. This way, we caught a lot of a lot of people wandering in the interface like, oh, we're looking for a button. Which button we are looking for. So we've been literally discovering some needs and something like we have a lot of opportunities for the customers to actually reach out to us through customer support widget, through some integration suggestions and et cetera. And people often reach out. They just literally say like, OK, I need this to work with this platform. This is my business logic. Like we always jump on a call and do like very in-depth dive into very business logic to really understand like, what's the use case? Do you have like, do you really struggle with it? Because otherwise, when we build something, there is nobody who's using it. And like I understand that sometimes I just had to like take some leaps of faith with the functionality, because I understand. I understood from my previous experience as a fulfillment center operator or something like that, I understood what functionality is actually required. So the customers, they typically don't know what is required. I've been in the trenches, I know. But the thing was that we couldn't implement everything I wanted. We had to settle for some sliver of the functionality that we actually need. And the initial platform literally just did the shipment tracking. Really good shipment tracking with a like table with all the tracking numbers. We didn't even have the concept of a shipment without a tracking number, because we assumed that every shipment has a tracking number. That cost us a lot because refactoring and breaking everything and like building it back together. It was it was really a hard earned lesson. So, yeah, where was I? We we always communicate with the customers and sometimes we do some like trend research or like Facebook groups discovery, because people are frequently asking questions or moaning about their problem on social media, and that's how we just see like, oh, this is what we should do. And our most interesting use case was that our current customer and they were not a customer at that point. They posted a YouTube video complaining about their supply chain issues. But actually, they were not complaining about supply chain issues. They were complaining about customers reaching out to them five times on different platforms and overloading their inbox with the same question. Where is my order? But the problem was it wasn't just that they were not providing those like email notification. It's like the problem, the actual problem was that people, then they were filling in their orders. They provided incorrect emails. They made typos in emails. And that's why they didn't receive those notifications. That's why we added in trackmage, we added a script that you can put on any input form on your website and it validates email addresses and make sure that there are no typos and even suggests like, OK, you're spelling GMAPE. Did you mean Gmail? So it literally suggests the typos. And that really dramatically increased the deliverability, the decrease, the bounce rate to zero. So all the customers are currently receiving the messages just with a simple validation. And when we were initially developing it, we had to go through iterations. So first message was like invalid email, like, OK, developers, step aside. We need to use some copyright. Like, oh, please check your spelling. That didn't work. So, oh, did you mean Gmail.com? And like, ah, ah, that's when people started noticing that. Oh, there was a typo. It just it's not saying that my email is invalid. It's saying that I made a typo and I need to check it. So, yeah, that just made all the change. Oh, that's a that's an excellent. That's an excellent little story right there, because it's it's amazing how many of those things where you think you look in one direction for your problem and you realize it's something completely different like that. It's just, oh, it was just a typo. And all of these systems that are set up and work and send notifications out and all that kind of stuff, all of those good things. It doesn't happen if you don't have a valid, you know, valid target. And I actually I was just talking to somebody the other day. It was the same kind of thing where there was this complaint that our notification system doesn't work for this system. And they started chasing stuff down and they found out that it was it's essentially the same thing is that those the notifications were all going out, but they were getting blocked. It was one of those that they weren't that part of it. Once once you send the notification out, you know, it's it's something else can do something with it. And that's what happens. There's a difference between you put something in your mailbox. And if it doesn't get to somebody else, it's not because you didn't put it in the mailbox, it's because, you know, something haven't got lost in transit or something like that. So those are great lessons to learn. And that seems like a good place to wrap up this episode. We get into a couple more topics before we're done. This will probably be, I would say, at least a four parter as we're working our way through it. And there's some really good gems that get dropped along the way. Hopefully you caught a few of those from this episode. Again, some of that will be in the show notes. Try and throw some links where I can. So that you maybe even just Google searches in some cases so that you can take a look into some of these products and some of the things that they use there at TrackMage to make everything work, to, you know, to smooth out some of the rough edges of software development and to properly communicate both internally and externally. That being said, we'll just wrap this one up. We'll keep it as short as possible, I guess. And we'll come back next time and continue our discussion with Irina. But as always, go out there and have yourself a great day, a great week. And we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go. Develop-a-Noor Podcast and Site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us be great if you go out to developer.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.