This week’s episode is the first in a three-part series about custom web applications for today. Justin Bantuelle, Chief Operating Officer & Web Technology Director at Health Connective, breaks down how to know when it’s the right time to build something new vs. using an application that’s already available. In this episode, you’ll learn how existing solutions can provide a head start, and what people fail to account for in building custom apps.
Engage With Us
How to listen: shows.pippa.io/paradigm-shift-of-healthcare/howto
Follow on Twitter: https://twitter.com/hlthconnective
Full Transcript
Announcer: It’s time to think differently about healthcare. But how do we keep up? The days of yesterday’s medicine are long gone, and we’re left trying to figure out where to go from here. With all the talk about politics and technology, it can be easy to forget that healthcare is still all about humans, and many of those humans have unbelievable stories to tell. Here, we leave the policy debates to the other guys, and focus instead on the people and ideas that are changing the way we address our health. It’s time to navigate the new landscape of healthcare together, and hear some amazing stories along the way. Ready for a breath of fresh air? It’s time for your Paradigm Shift.
Michael: Welcome to the Paradigm Shift of Healthcare, and thank you for listening. I’m Michael Roberts here today with cohosts Scott Zeitzer and Jared Johnson. Today’s episode is the first in a three-part series about custom web applications. We’ll be breaking it down into three key questions: when does it make sense to develop a custom application, what should the application do, and how should it be developed? In this series, we’re pleased to be joined by Justin Bantuelle. He’s our Chief Operating Officer and Web Technology Director here at Health Connective. Justin, thank you so much for joining us today.
Justin: Yeah. Thanks for having me.
Michael: Awesome. So, we talk about a lot of stuff in healthcare, which you’ve heard, because I’m sure you’ve listened to every episode we’ve ever put out, Justin, so it’s all good. But we’ve had these talks, you know, in our directors meetings and a lot of conversations that we have as staff, and we talk about all the things that we’re doing here on the podcast, and we talk about the different kinds of conversations we have with clients and customers. And you are obviously a big part of those conversations, especially when it gets into working with our clients. So, you know, before we get into all the details on that, and before we get into all the specifics, let’s just start with just sort of that, just sort of a fun ice breaker, you know. Can you tell us about a web application that you helped develop that you’re most proud of, you know, from any point in your career?
Justin: Sure. There’s a board game that had a web version of it that was very unofficial, that I really enjoyed, and they produced an official version that was quite expensive, and took down the unofficial version, and I kind of decided, well, I could just recreate that. So, I went ahead and wrote this online web application version of the game. And that was kind of new for me. I hadn’t really had any experience with the specific considerations that go into game development. And all the rules were established, but it was a fairly complex set of interactions, and I picked a new tech stack that seemed well-suited to that, and it just ended up being a very rewarding experience.
Michael: That’s awesome. So, the complexities of, like, creating a game, there’s obviously going to be a lot of different choices, like, all the way through the process. Can you give us just, like, a little bit of the mechanics around that? Like, what kinds of things did you have to consider when you were going into that?
Justin: Yeah. A lot of it was just how to represent everything correctly, and create the user interface for it, and constrain that properly. This in particular was a card game, and each card had specific rules, and the interactions between different cards could get very complicated. So you needed to really drill down into all the possible avenues of what could happen, and make sure that the game considered that, or it would just break horribly with anything that you overlooked. So, I would say modelling that was very challenging.
I ended up going through two different rewrites before I got to something that I’m really, really happy with, and those rewrites were very painful and significant because of early decisions I made, assumptions about how the game would work, and then realizing, oh, this particular card completely ruins the assumption that I made, and I really had to just start from the ground up to rebuild with that addressed. And I think there’s a lot of analog to that with a lot of other work. It’s super common to build something and then the first one is the one you want to throw in the trash, and then you go again with everything you’ve learned and all the mistakes you made, to get something that’s actually rock-solid the second time around, but it almost never works that way. But with a personal project, I had the luxury of doing whatever I wanted, because the only budget was my time.
Michael: Sure. Sure. So, let’s talk about that from a, I think a lot of the comparisons that you’re making, a lot of the statements that you’re making, are definitely things that we’ve, as a team, talked about. The experiences of the user, there’s a new, you know, expectation that was completely unaccounted for maybe early on, some of those kinds of things that we’ll definitely kind of dig into more. But let’s kind of talk more about, like, custom web applications, and I’d like to hear some about, also about, like, what some of the best work that you’re most proud of as a developer, as an application programmer, but also, like, if you could kind of give us an example of, hey, this is one I really liked, I really liked this process and how it came together? Probably you’d have to do it without client names and all that fun stuff, but if you can just give us kind of a walkthrough on that. But then also kind of give us an idea of, like, the types of applications that you work with kind of on a regular, you and your team, get to work with on a regular basis.
Justin: Sure. I guess over the years, there’s been a wide array. We’ve obviously predominantly always had a focus on the healthcare space, but we’ve built some things outside of that as well. And the applications really completely range from fairly simplistic to wildly complicated. It all just depends on the use case. I think one of the first things I ever started with was forecasting applications for orthopedic instruments. So, with manufacturing, you obviously need to have an idea of how many you’re going to need to make in order to plan properly, because there’s a lot that goes into the manufacturing of this. So, we built out forecasting tools that held the different lines of products, we created it where it will capture it, capture the information, who you were, how many you anticipated for your specific market, and we collated all that data and then surfaced that for the people who needed to be the decision makers.
And that was a pretty basic one, when it came down to it, because it looked a lot like a glorified spreadsheet, and that’s what they used to use, was spreadsheets. But the spreadsheet, somebody has to go collate that data, but that’s something that a computer is very, very good at. So, if you grab that online, you can save it, you can digest in different ways, perform analysis on it, send emails to the right people. It takes this very manual process and automates a tremendous amount of it, and makes it much more painless. We also were able to, by that, we were able to remember data from year to year and pull that in. So, that’s on the simpler side. We’ve done things… At the end of the day, mostly what web applications do is model some kind of business need.
An example of a much more complicated one was a banking system. It was for tuition lending for banks. So, parents would be able to take out loans… That ended up being one of the most complicated ones that we built, because we actually had to interface with the bank system. They’ve got pretty strict security requirements, they have very specific data formats that you need to capture things in, so we’d have to create these file exports that they could just load into their banking system, for payments from checking accounts, from capturing credit cards, all the loan details. We needed to read information back in from them and they had very specific file formats they could provide to us. So that was a lot of work on that side. And then you had the schools that needed to be able to review all of their data, search through it. I’d say that’s one of the most complicated ones that I’ve done within my career that I was hands-on for most of the coding on.
Michael: Right on. Right on. And when we talk about the length of your career and everything, that’s pretty much been at this company, right? So, you’ve worked straight with what used to be Mudbug Media and is now Health Connective the whole time, right?
Justin: Yeah, yeah. I started as an intern while I was in my last semester of college, and just continued since.
Michael: You just kept on. Keep going. Keep going. So, let’s talk about, I was first going to make a comparison for all of the folks that are out there that may be, like, more the marketing side of things than full-on programming and full-on, like, knowing when you need to get these applications. Like, if you’ve ever played around, and this is a grossly simplified comparison, but if you’ve ever played around in Zapier, and, you know, you’ve tried to send data out into some sort of system, just trying to grab some system, and grab some information and throw it into your CRM and then watch how horribly wrong it can go if you didn’t account for everything to go right, it’s kind of a glimpse into some of what Justin and his team get to deal with all the time.
But let’s talk about that, Justin. Like, there are these kind of, like, little shortcuts and these little things that may help you bridge data from one system to the next, may help with some of those kind of, like, edge cases, where the thing that’s out there that you can go buy, whether it’s Salesforce or whether it’s some other kind of tool, it just doesn’t do enough, and there’s always that kind of question of, like, okay, is it time to start building a system? Is this now when we have to switch over? And, like, how do you advise companies on, like, when it’s time to start that process, and whether it’s worth the investment to go ahead with that application?
Justin: Sure. That’s a really good question. Something that stuck with me from a book I read several years ago on microservice architecture, which doesn’t really have anything to do with this, but in the introduction, there was something they mentioned that was along the lines of, if your problem is a problem that every company faces, or every company within your industry, then it’s probably not a good thing to pay for custom development on, because there’s no way that every company out there does a completely bespoke solution for this common problem. A clear example is things like HR software. Every company needs HR in some capacity, right? However simple it is to however complex it is, and I’ve seen and worked on systems from both sides of that. It’s not a good investment to build your own HR solution.
We actually worked for a company that had made that decision, and it was an absolute nightmare for them, and it was very, very expensive and very painful to move out of it. So, they finally bit the bullet and did that, and it was a huge win for them, but they made a bad decision at the start because they felt that it would be cheaper to have these couple of developers they had on staff build it out, because the HR systems for companies that large have very significant licensing fees and those are monthly, like, you’re paying routinely. Like, it’s a cost you’re never escaping from once you lock yourself into that. But there’s a whole bunch of hidden costs to building an app, paying somebody to build it, paying somebody to maintain it, and then having it not even be as feature-rich a lot of times, because you don’t have unique problems in that space.
So, I’d say that that is a primary question that should be asked right up front is whether your problem is genuinely unique enough to warrant a custom solution. The trade-off is obviously you cede a lot of control when you use somebody else’s system. I think you were touching on some of that, like, with Zapier. You can’t move…if your data doesn’t move cleanly, you’re kind of out of luck. But if it does do what you need, or if it does 80% of what you need, and you can get your work done, and then the other 20% maybe is manual, you still save quite a bit, and maybe that custom solution would have been exponentially larger. So, if you can get away with operating in somebody else’s sandbox, then you’re really fine. If you can’t, if you know that your business cannot function without it, or that next step in growth is not happening unless you can really meet this unique need, you should be looking for a custom solution.
Michael: Everybody, I always appreciate that you tune in, that you’re listening to the show here. I wanted to let you know that we have set up a new newsletter that you can get to at paradigmshift.health. That’s paradigmshift.health. You can go there, and the reason that we’ve got this newsletter is that we like to send out a few extra pieces of information with the show. We also have the full transcript for every single episode that we do, and we can let you know that through email, we can let you know also if we have, like, a good quote card to be able to show for every episode. So, check that out if you’d like, paradigmshift.health. Thanks so much.
Scott: …you’re not thinking about all the pitfalls here. Can we walk through that and see if you’re still comfortable moving forward, because sometimes, you know, the solution is more costly than you think. But sometimes also, you know, custom, an existing solution can help you, from a next step perspective, in terms of getting a head start on custom apps. So, if you do decide to make the jump, how can some existing solutions help out?
Justin: So, what do you mean by existing solutions? Do you mean certain, like, tool sets, or like something that actually feels like it’s analogous to the custom solution?
Scott: Maybe a little bit of both. We could go down both pathways. You know, sometimes, you know, there’s an app out there that is taking care of maybe one part of a problem, but this particular company has, it’s multi-pronged, and it’s only solving one of the things. I think getting away from platforms, but really focusing more on the application side, we can follow up on the platform side, but on the application side, hey, it’s doing X, but I really need Y and Z as well. Maybe focus on the application side.
Justin: Sure. On the application side, I think that it’s rare that existing solutions can give you a head start on a custom app. But that being said, sometimes an existing solution, an off-the-shelf solution, is the right decision to initially get off the ground with your business. Maybe you’re trying to even, like, prove to investors or something that this is viable at all, and you use something off-the-shelf and it gets you established enough that you then are ready to switch to a custom app that does some of the more unique things that you need. But this is something we run into a lot. A lot of times, people hope or expect that that existing solution can be repurposed or reused, and a lot of times, that’s not the case. And even if you’re paying for a custom solution, if you pay for the wrong custom solution, there’s this feeling that you sunk money into this, and it should be able to be updated to now meet your new needs, but if that existing dev team is no longer around, there’s a very good chance that it’s not going to be usable, and you’re going to have to just start over.
And so, I think that’s a pitfall a lot of people fall into, because they have this expectation that it’s easy to bolt something on, or that something that somebody else built is going to be easy for someone coming in new to maintain, and that’s rarely the case. The knowledge transfer is exceedingly difficult when you have everyone on board and you can actually take the time to train a new person on it. When there’s no opportunity for knowledge transfer and somebody’s coming in completely blind, it’s very rare that that really succeeds the way people hope. You end up spending so much money getting somebody to just learn about a system that’s not even doing what you want, and you’re really better off starting over.
Scott: We’ve run into that quite a bit over the years, where a particular company will work with a developer. They got a, they picked a particular developer because, A, it was the least expensive of the different proposals that came in, and then it just didn’t work. “So, can you come in and just fix it for a little bit more?” And you and I are always looking at each other like, “Yeah, this is a recipe for failure. It’s not gonna work. And here’s why.” That type of thing. I know that that can certainly be an issue, you know what I mean?
Justin: Yeah. It’s the desire to hold on to what you have. Like, that may have been the right business decision, getting bootstrapped with something that was cheap and quick. It can absolutely be a good idea.
Jared: So Justin, when you talk about the entire process of building out a custom application, I think there are definitely a lot of different levels of expectations, to say the least. What do people fail to account for when there’s a custom application being built? What are some of the most common things you see that you just, you either have to explain a little extra, more about, or, you know, people just don’t, they don’t realize, that they just think it just happens automatically? Like, what are some of those things people fail to account for?
Justin: I think probably the biggest pitfall is believing that you buy it, it’s built, it’s done, and then that’s it. And that just doesn’t end up being the case. No product is built exactly to spec the first time around. You think you know what you need, you try to communicate your requirements clearly, it gets built, and then you realize that, oh, I really needed it to do this also, or bugs emerge that weren’t found in testing, and you need to maintain the system and make updates to address those concerns. You have emerging needs, where, oh, now I need to do this other thing, or hey, this tech stack is no longer secure, because a vulnerability was found, and now we need to update to a newer version of the software. The maintenance component of it is often overlooked and underestimated in cost. So, if something is essential enough that you really needed to build out a custom application for it, you need to plan for the maintenance of it and future development on it. And without budgeting for that, it can leave you in a really bad spot.
Scott: I couldn’t agree more, Justin. It’s so often, you talk about even, like, simple web applications, where there’s no maintenance at all and then, you know, they come out with iPhone 75, 76, and 77, and they’re wondering why it doesn’t work on that, and it’s like, well, we built it for the iPhone 4. So, I’m not sure how you expect it to work on whatever iPhone it’s up to now. And the other thing, I think you mentioned the word “tech stack.” For people who are not familiar with that, it’s like, you know, sometimes, something is it, it is the craze. It’s always been out there, where a particular type of application development tool, etc. is picked, and then, for whatever reason, those developers don’t pick up on it, and it doesn’t get updated, and people figure out how to hack into that system, and all of a sudden, it’s just not secure, or it’s just not modern enough, right?
Justin: Yeah. That can absolutely happen where, I mean, there’s a myriad reasons why something becomes outdated. It is the nature of web application in particular, but really, any kind of development. Things will just age out, and not achieve what you need them to achieve anymore. Like you mentioned, new devices is a huge consideration within the web space, but a lot of times, performance is a big issue, new standards emerge for accessibility, so that’s often a big consideration, where maybe somebody can’t read a website on a screen reader, and new standards come out, and in order to make sure that you’re meeting accessibility criteria, you do have to go back in and update it and meet the new standards. And these are all good things that you’re keeping it updated, but they do cost time and money. So, not being prepared for that, like I said, can really hurt you.
Scott: Yeah. It’s always going to be a balance, for everybody who’s listening, you know, there’s this balance of, I made it just for me, and it’s doing what I need it to do and that’s great, but you gotta take the time to really dive deep enough into it to make sure you understand what you’re getting out of it, set the expectations in that first year and then ongoing years, that it’s going to continue to take time. We’ve made some great apps over the years, but they’re never just made and, you know, and then off you go, you’re good now forever. It’s just not going to happen like that.
Justin: Yeah. And just to add on to that, I’ve also seen where the maintenance is put off until something is, like, impossible to ignore. So now, there’s a major security vulnerability or, oh, the database that we were using is not even supported, and now we can’t even update the system until we, like, we can’t make changes to the system until we perform this upgrade. We’ve pushed it off as far as we can, and now things are just actually broken. And then, now you’ve got a very large unplanned cost to do a one-time maintenance there, and you’re trying to upgrade, like, two to three years’ worth of upgrades all at once, and you inject a lot of uncertainty and risk in your solution still working afterwards. The odds of introducing bugs are way higher when you’re trying to race through years of updates all at once. It’s just not a secure way to do it, it’s not a, it just doesn’t help, when it comes down to it. So, you end up spending more than you would have if you’d done the incremental updates all the way through, and you have a much more stable product that you’re much more confident about meeting your needs.
Scott: Yeah. And that can happen, you know, not even just, you know, not just on custom apps, like bespoke apps, but how many times, J, have we been on the phone with a client that is still using, I’m just being silly now, IE 1, because they never updated this huge amount of software, you know, because the licensing costs are so high. And so, they’re forced to use these old browsers because it’s the only way that the system will work is on some old browser, so they have to have multiple versions of different browsers in place. So all of the [crosstalk 00:21:22]
Justin: Yeah, and then, if you’re paying somebody to build to very outdated technology stacks, the documentation is very poor, the range of tools that are available are much more limited, because everyone’s building to the new standards, so you can’t use a lot of these same tools anymore. So, that’s often a way that, it’s not even about the custom app itself, it’s about their internal IT systems being outmoded, and needing to build to an outdated standard. So, that is quite expensive as well.
Scott: No doubt.
Michael: So guys, I think that we could go on with all the different things that companies could and should be doing around this kind of stuff, and we’ll definitely get into this more in some future episodes. But for now, everybody, thanks for listening today. Have a great week.
Announcer: Thanks again for tuning in to the Paradigm Shift of Healthcare. This program is brought to you by Health Connective. Custom marketing solutions for med-tech and pharma. Subscribe on Apple Podcasts, Google Play, or anywhere you listen to podcasts.