Does Your Business Need a Custom API? | Episode 13
[Kelson Erwin] (0:00 - 0:14)
Yeah, I think that more businesses are going to want to have APIs. It's very similar to how we move to the web, where before a lot of businesses were running their business on paper or spreadsheets, and now everybody wants to be on an online system.
[David Guthrie] (0:14 - 0:57)
If it wasn't worth more than 500 bucks a month, never would have built it in the first place. It wouldn't have been worth it in the first place. Okay, welcome to the podcast.
I'm here with Kelsin Erwin, the CEO at Ksense Technology Group. On this podcast, what we do is we talk about technology, business technology and strategy. And today we're answering a really common question, something that a lot of you have asked about, which is developing a custom API.
So we're going to talk about what an API is, we're going to talk about what they're used for, and hopefully address some of the common questions or give you a framework for how to move forward if this is something that you need for your business. So thanks so much for joining me today, Kelsin.
[Kelson Erwin] (0:58 - 1:09)
Yeah, no problem. We're going to try to provide a very comprehensive overview, but if you do have any questions, you're welcome to email them in or leave a comment below.
[David Guthrie] (1:09 - 1:34)
Yeah, yeah, leave us comments. Let us know what you'd like to see, what sort of questions you have, and that's what we'll address next. Awesome.
So let's first just do a little bit of definition. Can you tell us about APIs? Give us maybe some context on why they're important and why it's becoming more and more popular for businesses to develop their own API.
[Kelson Erwin] (1:34 - 3:23)
Yeah, so the definition of an API, it's actually an acronym for Application Programming Interface. And a lot of times it's what allows software or a software system to communicate with another software system. So you can think of it like an under the hood middleman that sends messages back and forth between different systems.
Generally, people are building these to facilitate communication between two different platforms. For example, maybe you have a mobile application that you're developing and you want to pull some data from a third party data source, or you have a web application that you're developing and you want to have it sent text messages. Or perhaps you want to allow vendors or your customers to have access to your information or a subset of your information, or you want to set up automations around different business processes that you have.
It's kind of the glue or the nervous system that kind of connects all your data. And so that's kind of what it is. There's a lot of benefits.
Obviously, it allows you to make high level decisions. It increases your increases client satisfaction and it allows people to have access to data or allows you to have access to somebody else's data. So that's kind of a general overview of what it is and how works and why it's important.
[David Guthrie] (3:24 - 3:34)
Yeah, like the common terminology that we hear from people is I need this app to talk to that app, right? So the API is how they talk. It's how you get data back and forth, right?
[Kelson Erwin] (3:35 - 4:20)
Yeah, the API is like the rules around how they are supposed to talk. So you have a couple of different tech terms of the different types of APIs. There are you have like graph APIs, you have RESTful APIs, you have SOAP APIs.
And essentially, those definitions outline exactly how the process works, the types of rules that the technology is supposed to follow and how it's supposed to be set up. But at the end of the day, really, you can think of it like a more advanced way of sending messages. Somebody requests something and to request something, they send a message in and then the software system sends a message back with their results.
You know, it's just it's just an advanced messaging system that happens under the hood for apps.
[David Guthrie] (4:20 - 4:28)
Let's talk about why you would need a custom API versus just going with off the shelf solutions out there.
[Kelson Erwin] (4:28 - 8:00)
Yeah, so there's, you know, a lot of off the shelf solutions that exist. You're probably using right. So you might have like CRMs and you might have, you know, ERP systems and they expose different APIs to the user, but there's a lot of issues with with that.
And one of the primary issues that people come to us to fix is that the data is not centralized or they want to provide data, but they don't want to give access to a vendor or or to some third party access to all of the data. They want re redacted data of some sort. So, you know, generally when a business owner is coming in there, you know, they come to us and they're trying to make a decision.
A lot of times they're looking they're comparing either the off the shelf like their CRM API and giving access to that. Or they've decided that that's not going to work. So then they're looking at kind of a drag and drop code lists or low code tool.
There's a bunch of those out there. There's like Zapier or make.com and then, you know, and then they're comparing that to the custom route and they're trying to decide, you know, which one's best and, you know, the answer to that question can be pretty challenging. I think, especially if people don't know the drawbacks, you know, that they may think that the off the shelf system or Zapier or make.com is going to be cheaper because they don't need technical staff to set it up. But then as they scale, they see the costs really start to hit them. So to kind of break it down, let's to compare like make.com or Zapier, which I'd say those are like the off the shelf integrators, I call them, versus a custom solution, really what you'd see is the ability for non-technical staff to be able to set this up, maintain it, which reduces upfront cost. But then the way that they charge you is by charging on the transaction.
So, you know how we were talking about messages, every message is a charge. So even though it costs less to set up because you don't need a technical staff or you don't need to hire an agency, you know, as the usage goes up, you end up paying a lot more for it. Whereas, you know, we could set up an API for somebody and have millions of different requests going through that API.
And the cost is the same for us. That those are kind of some of the drawbacks. My suggestion to somebody would be to really understand what their needs are and then understand what the usage is going to look like.
Because, you know, a lot of times somebody might come to us with a very complicated make into integration and they're lost in it because it's so large and they don't make it really easy to troubleshoot it. So the, you know, even though it started as like a very simple integration, it's now a very complex integration, which takes a lot more time to troubleshoot than a traditional API written code. And then they also start paying a lot of money for it.
And then they find out, oh, actually make doesn't integrate with the new system that we're moving to. It ends up being kind of a lost cause when all is said and done. So it's, it's important to kind of evaluate the options, understand the lack of flexibility with the low code tools, understand the scalability costs and kind of weigh the pros and cons yourself.
[David Guthrie] (8:01 - 8:52)
You're not really creating an API at that point. You're just using prebuilt connectors, right? You're if Zapier has already built a connection between this app and that app, then you can use it to build out a flow of how you want to automate things.
But if they haven't, you're kind of out of luck. You've got to, you know, just hope that, you know, maybe they, they develop one in the future or you've got to get started on a custom solution and just build exactly what you need. Um, so yeah, that's, that's, that's a big drawback.
I mean, that's probably the biggest in my mind is just like, you might pay for a tool like this. You might be using it for some things, but then you're going to hit those limitations, like you were talking about, and maybe a key piece of your tech stack, isn't going to be possible to actually include in that, you know, that process that you're trying to automate.
[Kelson Erwin] (8:53 - 10:18)
Another thing that isn't a lot of times considered is that yeah, make.com Zapier. They'll allow you to set up integrations between your own internal systems. So you could say, when this happens in my system, then I want to send a text message, but it's not going to allow you to provide an API to third party developers so that they can integrate and work with your data.
Um, it's just not something that it's, you know, it's an integration tool. It's, it's not going to allow third parties to, to utilize your data in any way. So if you have like, say, for example, you're an e-commerce store and you have a list of products that's in the products are always changing and you have a vendor who wants to display those products on their mobile app, the same products that you're offering.
You're not going to be able to do that with make. You're going to need to set up your own API. And what's going to happen is the, we're going to have an endpoint, which is basically URL.
We're going to give them that endpoint, give them the authentication for the endpoint, and then they're going to hit it. And it's going to go to your system, grab the data out, redact the data. You don't want them to have and send it back in the format that, that their software is expecting.
You can't do that with make. So yeah, it'll work to integrate between your own systems, but it's, it's not a custom API in the, in the sense that I'm really talking about where, where you can kind of get the data, centralize the data and expose the data to third parties.
[David Guthrie] (10:19 - 11:07)
Yeah. I remember the first time I ever used Zapier. I was so excited.
And it is a really cool concept, you know, and it's very useful for exactly what you were talking about, where it's a smaller scale and you're kind of figuring out your first prototype of the automation that you want. But yeah, I remember just being disappointed when I realized what exactly what you said. Every action that you take is a charge and you'll go through your credits pretty quick.
If you're trying to use this at scale, if you're trying to use it for all of your customer interactions or transactions, it's just not the way to go. Especially as you scale up, let's, let's talk about a specific example. Can you think of any examples of a client of yours where you've created a custom API for them and how that transformed their workflow or what sort of benefits they got from that?
[Kelson Erwin] (11:08 - 15:12)
Yeah, I mean, I have a bunch of them. You know, we do a lot of API development. So an example is we have an organization that we work with and they do pest control referrals.
So somebody has a pest ants or something like that, and they will find a pest control provider in the area. So nationwide, somebody can, you know, go into their application online. Say I'm in this area, this is the pest that I'm dealing with, and it'll, it'll refer somebody that deals with that type of pet in that region.
And what they wanted was they wanted to have a phone system where you could actually call in and it would say, a robot would say, please type in your zip code. Please tell us the pest problem that you're dealing with. And it would send them a text message with the referral and also, you know, tell them that referral on the phone.
And the way that that system worked was by setting up an API and then connecting it to Twilio's IVR and then having that IVR hit their API and their API goes to the database and grab that data and brings it back. And so that opened up a whole new side of the business where now you could get a pest control referral without even having to log into the online system. So that revolutionized the business because before that you had to do it on a desktop.
So that was one of them. Another one that comes to mind is we had a client who, they had third parties doing sales for them. And the third party organization that was doing the sales and marketing, they wanted to know how many sales they made, who made these sales and all of the data was going into a CRM.
And that organization also had their own sales team data going into that CRM. So the company wanted to have a redacted version of an API that we could provide them so that they could see all of the data that we're okay with giving them. We built this API, we gave it to them.
They were able to integrate it with one of their systems, some data warehouse or something like that. I'm not sure what they did with it exactly, but they were able to grab all of the data excluding the internal data of all of the clients, the existing clients and stuff that had nothing to do with the third party marketing and sales tools. And then the last one that I'm thinking of is pretty simple.
We set up a, it's more of a webhook, but let's just call it an API because it's essentially what it is. It's for a lumber, it's like a lumber manufacturer and they manufacture lumber. So I think they get the logs, they cut them and then they ship them.
And they wanted their customers to know where in the process, their vendors and customers to know where in the process a given delivery was at. And so we set up an API that all of their customers could use and they could plug that into their own systems so that they could see and improve the logistics on their end because now they know when that lumber is going to arrive so they can plan everything based on that within their own systems. But we also were able to automate it so that it would send notifications out, automated notification.
So all the customers were pretty happy about that because it improved communication and transparency with where each shipment was in the process. So there's a whole lot that you can do with these API systems. Going back to the basics, why would somebody want to do this?
They're trying to improve the customer experience. They're trying to centralize the data, provide, or provide access to it, or they're trying to automate is generally why somebody would build one.
[David Guthrie] (15:13 - 16:36)
Yeah. So that's, I mean, that's a pretty wide breadth of use cases. Like, and I think that's what a lot of people don't realize is that APIs, you use APIs for pretty much everything when you need to work between multiple systems, right?
So with that example, you're using what are called API calls, right? Which is just, you're pinging that API. You're saying, hey, here's who I am.
Here's my authentication. I'm allowed to get this data. Here's the data I want.
And then it replies. And you could also do sort of a two-way type deal where you not only can you get data out, but you can also put data in. You can update or create new data.
So for situations like after every order, I want my financial system to be updated over there as well so that I don't need somebody to manually go through my POS and write down every transaction so that my accountants have it, right? Everything. There's so many different use cases for every business.
So I guess, what are the situations where you would not want an API is what kind of comes to my mind because it sounds like every business needs this type of stuff. Is there a business out there that you think doesn't need an API? And what would that look like, you think?
[Kelson Erwin] (16:37 - 18:55)
Not every business needs custom APIs set up for them. There's a lot of traditional businesses that have really good off-the-shelf software solutions where it just doesn't make sense to create a custom API yourself. They already have it very well established.
If you want custom notifications, just go into the system and check the checkbox and now you have all your custom automations. A lot of times, the businesses that are really pushing to do different API work, they feel a pain where they want access to a bunch of information in one place or they have software solutions that are kind of working for them and they want to improve how they work. They want to extract data or they want to provide data to a third party or the automations that are set up in the off-the-shelf software that's just not cutting it or they want to innovate on top of it.
There's even the use that I didn't really think about until now, but the ability to monetize your data that you have. If you have a ton of data, especially valuable data, you can build somebody for usage of your API. We see that all the time when somebody has a really massive database.
For example, imagine you have a database with all of the home values. You got all this data from the MLS and you have all this home data. You could set up the API to allow others to use that data that you've piled and they will pay for every request.
It's another way you could make a little bit of money. Also, really small businesses probably don't need it. It's probably not a priority for a really small business.
There's probably larger priorities. So while it is incredibly valuable and I think most businesses could use an API, in fact, I would recommend that most businesses start considering where they can implement custom AIs into their business. It's also, you got to evaluate your overall business health, the size, and ask yourself what problems would it solve?
Are those problems priorities in the organization?
[David Guthrie] (18:57 - 20:53)
Yeah, to your point, what problems is it going to solve? You really have to define what people do in the API. What sort of information you want them to be able to get, what sort of information they should be able to write to your system, and what those use cases are in general.
And that's something I've noticed too, is that there's a wide range of how well developed or how sophisticated an API is. Sometimes there's a huge list of things that you can do and so you can come up with really creative ways to use that. If you want to take data, modify it with data from somewhere else, and then update that again in the original system, you can do that.
And then there are some APIs where they're just very basic and they don't allow you to change anything. You can only read things and only specific things. So for example, an email system, maybe it allows you to see how many leads or how many contacts are within a certain email campaign, but it doesn't allow you to see which ones.
So that's an example where it's like, you might have a really good idea in your head of what you want to build, some sort of automation or some sort of app that uses this API, but you need a developer to go in there, read the documentation, look at what's possible to see what you can actually do. And so that's one of the main reasons to develop a custom API is to make sure that all of the use cases that are really important to your business are possible. You actually have the control to say, this is going to be important for my customers or my partners, my vendors, whatever it might be.
This is how they need to be able to interact with my data. So what are some misconceptions that people have about APIs? When they're starting projects like this or they're coming to you with questions, what are some things you've noticed that people just don't quite understand?
[Kelson Erwin] (20:54 - 23:18)
A lot of times they don't understand that they need a custom API. They think that the off-the-shelf solution, we can just use the API that's built into that a lot of times and just give that to their clients or their vendors or whatever, which isn't always true or another common misconception is that they can use Zapier or Make and they don't find out until later that that's not really going to be possible for them or it's going to be cost prohibitive to do that. A couple more that people have is that custom APIs are something that only tech companies build and we find that businesses outside of the tech sector that develop and maintain custom APIs generally have quite an edge.
They're able to integrate with different systems and they're able to have a more centralized data warehouse which helps them make important decisions about their business but that is definitely a misconception. Another misconception that people have is that they're way too expensive to build and I think that that misconception kind of comes from the fact that they used to be a lot more expensive to build than they are now. There's a lot of tools and developer tooling that's come out over the last five, 10 years that makes it so it's a lot easier to set up APIs and then there's a lot of standardization around how they work.
So it's a lot, it's quite a bit easier than it used to be to set them up, get them hosted and maintain them and then maintaining them is also something that can be a misconception. They do need ongoing maintenance done by technical staff but there are a lot of things that a lot of benefits that non-technical staff have. So I guess it might be a misconception that they think, oh, I mostly have non-technical staff so let's not build an API.
A lot of organizations want to build APIs to empower their non-technical staff to do more than they're doing today. So yeah, you might need somebody technical to set it up and to maintain it but it'll pay dividends with all your non-technical staff because they'll be able to utilize it. Maybe they won't be writing, using it in code, they won't be adding it with the code but they'll be able to benefit based on that data centralization or the automation side of things.
[David Guthrie] (23:19 - 23:29)
So let's get into kind of what people expect or should expect from the process. What are some practical expectations around developing an API?
[Kelson Erwin] (23:30 - 23:34)
Yeah, you mean just like building it, like how do you build it? What's the process look like for that?
[David Guthrie] (23:35 - 23:45)
Yeah, like if somebody's coming to you for a new API, what should I expect? What does that process look like for them as a client and also for you? What should people expect?
[Kelson Erwin] (23:46 - 26:07)
Yeah, so I think that first expectation that I would try to outline is that building software is different from building a house. It's a lot more iterative than building a home. So what we like to do is gather the project requirements initially.
What are your pain points? What are your objectives? And then build the smallest piece we can and deliver it to you.
And then get your opinion and get your opinions, get your thoughts, your vision, and then continue to iterate on that. A lot more like if you were to hire somebody, maybe to do some art or to write a book for you. So the process would be a little bit different for it.
We would do those iterative cycles and you'd have working software in your hands pretty quickly within weeks. You'd have some piece, some working software. The other thing is the ongoing nature, adding more and more features and functionalities is something that we see all the time where we're able to deliver a lot of value with the custom API initially.
And so the scope of the API will continue to increase and the API will be more and more powerful over time. And that's just something to expect as well. You know, don't go into it thinking, oh yeah, this is the requirements that I have and once it's done, it's done.
As soon as you get started, you'll realize that there's so much value that these things can provide your business and you'll have more and more ideas. So it's really good to stay focused on the goals and not add too many bells and whistles. But at the same time, going into the project thinking it's going to be a flat rate project and the scope's not going to change.
It's going to change. It always does. So and then I guess the last thing is there is some maintenance that doesn't need to be done.
Software is always changing and all the tools that the software built on, the tools that help us get it off the ground quickly, they need to be updated. Security patches come out and somebody needs to go in and fix those. But that's, you know, a fraction of the cost.
You know, it's relatively small how much you'll be paying for that compared to the overall build. So most people they for them, it's they don't even blink when I tell them how much is it going to cost for maintenance because it's such a small number. But it depends on the size of the API, obviously.
[David Guthrie] (26:08 - 26:18)
I mean, obviously it varies, right? Every project is going to be unique and they're going to have different needs. But in general, how long does it take to stand something like this up for a business?
[Kelson Erwin] (26:18 - 27:02)
Yeah, it totally depends on the project requirements. And it's something that what we would do is we'd gather all the requirements. So we'd say, all right, we have our list of requirements.
We understand the pain points and how we're going to solve them. And then from there, we're able to give very detailed timelines and costs that are associated with it. And sometimes, you know, sometimes it's really quick where we can get the whole project done in just a couple of weeks.
And other times, you know, it's an API that will be developing for a year. So, you know, it just depends on the requirements. But it's definitely worth it to have a call.
We offer free consultations where we're going to where we can do some discovery and give you some all part numbers right off the bat.
[David Guthrie] (27:03 - 27:08)
Yeah, so I guess that it is too varied to just kind of give a general answer.
[Kelson Erwin] (27:08 - 27:23)
Yeah, it's like asking how much how much a house is going to cost to build. It's like, well, it depends, man. Are you going to put in granite flooring or, you know, is this going to be in LA or is this going to be in Ohio, right?
[David Guthrie] (27:23 - 27:42)
Tell me about how a custom API fits into a company's broader technology strategy. You know, we hear a lot about digital transformation. That's something a lot of businesses are focused on to get more more flexible, more agile, more adaptable.
How does an API fit into all of that?
[Kelson Erwin] (27:43 - 29:56)
Yeah, I mean, it is definitely part of that process, right? You know, a lot of people over the last 5-10 years had been focusing on moving away from paper systems or, you know, even better moving away from spreadsheet based systems where they were previously running their business office spreadsheets. You can think of it, the custom API is one step further than that, where now you have a central nervous system for all of your applications where we can query it, we can ask it questions, we can provide access to that to different individuals that may need it, different organizations that you work with.
And really what it allows us to do is it allows us to move a lot more quickly to be very agile, to set up automations and stay ahead of your competitors. But it also allows us to make data-based decisions. Since you have all the data at your fingertips, we're able to analyze it and, you know, view it in charts and, you know, overlay it with other pieces of data and really make good business decisions that are difficult to make without the data all in one place.
And then, you know, the automation side of things and everything that it allows you to do with enabling your staff and enabling your team and improving your customer satisfaction really allows you to scale your business operations without having to hire more people. You know, for example, the phone system that I was talking about earlier, the traditional way that a business may have set that up would be to have actual people answering the phone and they would type it into the system and they would say, okay, I found a referral for you. Here's the name of the company here's their phone number.
But having it built out as an API allows an unlimited amount of phone calls to that system with no additional staff being added. So you can see, you know, that's a great example of how these types of APIs allow an organization to really scale. It's a key component, I think, to a digital strategy that all businesses should be considering making whether they need it or not is something they should think about.
[David Guthrie] (29:56 - 30:18)
Yeah, and so if people are thinking about it, if they're considering getting an API, what sort of stuff should they be thinking about? What sort of questions should they be asking, you know, maybe their own team? What should they ask potential vendors or developers about APIs?
What are those questions? How did somebody prepare for a project like that?
[Kelson Erwin] (30:18 - 31:55)
Yeah, the biggest question is what problem are they trying to solve? You know, you don't want to build an API if you don't have a problem. If your data is already completely centralized, everything's automated, you know, your customer satisfaction is through the roof and there's no way you can improve it, then it probably doesn't make sense.
Or if your business is really small and, you know, maybe you can't afford the development, then it's probably better to go with some off-the-shelf solution to do this integration. So it's important to ask, like, what can it solve? What systems are we going to integrate?
How are we going to do the integration? You know, what information do we want to have? And then try to measure, you know, find a way to measure the return on investment.
Get some ballpark pricing and say, all right, how much money can we expect to make by building this out? You know, if our customers are able to call in and instead of talking to a human, they can, you know, type in a zip code on their phone and it gives them a pest control provider in that area. You know, what...
Let's say we have 10% of people doing this instead of using the online system. How much money are we going to make compared to the traditional way of doing it and figure out a way to measure the ROI. You know, maybe that's not the best example for your business, but there's generally always a way that you can measure what the ROI is going to look like.
So it's important to measure it because we don't want to build something that, you know, isn't worth it for you.
[David Guthrie] (31:55 - 32:19)
Do you feel like that happens a lot? I mean, it seems like by the time people get to this point, they probably are feeling the pain of some problem that's prompting them to do this. So there's probably usually a return on investment, but have you seen people, you know, regret something that they developed, that they spent time and money to build and then realize that it just wasn't important?
[Kelson Erwin] (32:20 - 34:02)
Yeah, I mean, you see people want to build things that are important all the time. Like there's a tendency to over-automate and, you know, as a leader in technology, it's important for me to stress that we need to try to avoid over-automating things. We need to really evaluate the return on investment before we build.
A lot of times businesses will come to us with the problem that they have and they know that there's ROI there. But once the project starts rolling, there definitely is a tendency to over-automate. And so we definitely, we try our best to push back and really try to evaluate, okay, what's the ROI on this?
Maybe some people aren't going to believe me, but the reason for that is because there's always some ROI, there's always some value that I can provide in terms of automating business systems in one way or another. And so I am truly honest with my client saying, all right, it doesn't look like this is going to be worth it. Maybe it's better to just have this stay as a manual process because I know that I can provide that value somewhere else in terms of software and automation and centralizing data.
There's always some where I can provide value. So we try really hard to not over-automate. It's happened before.
It's very rare that somebody comes to us with a custom API with custom API requirements and then it ends up not being worth it for them. That's pretty rare. If we build it, it's almost always worth it for them.
It's usually the bells and whistles that end up bringing that ROI down.
[David Guthrie] (34:02 - 35:01)
That rings true for me. I mean, in almost any kind of project, whether it's technology or not, if you're trying to do a great job at the project, if you're trying to deliver the best work possible, you're probably coming up with a lot of really interesting ideas and sort of cool things that you could do. But yeah, that's super important is just thinking about how you can trim it down, make sure that you're focusing on the biggest priorities first.
And then if your project is saving you money already because you developed those things first, then you've probably got a budget to do those nice-to-have things and think about the cool features. So that's a big hurdle for a lot of people and these types of projects. What are some other hidden costs or maybe not hidden costs, but what are some things that people don't think about when they start something like this that they need to figure out a budget for down the line?
[Kelson Erwin] (35:03 - 36:17)
Yeah, sure. So I mean, if they decide to go with one of the local tools or use an off-the-shelf CRM and just provide that to third parties, then a lot of times we see them wanting to migrate off because they're paying a lot of money or because their security vulnerabilities. You know, we have people come to us with pre-built API sometimes that were obviously rushed.
There's a bunch of what we call technical debt built into that. Maybe it's old ways of doing things or just very, you know, poor code quality. Things are really hard to read.
When things are really hard to read, it takes longer to fix problems or there's already problems that exist in the code that need to be fixed. And so, you know, that definitely can be a risk. Another thing that people need to be aware of is that ongoing maintenance where they need updates over time and they need to be monitored.
The last thing I can think of off the top of my head is that poorly designed API can be insecure. So it's pretty important that you start the project with a security first mindset and every step of the process you're thinking, all right, how can we make sure this is secure for us?
[David Guthrie] (36:17 - 36:53)
You know, really it's a tool for security because like you were saying earlier, you can choose what sort of data you want people to be able to get and what they can do with your system. But yeah, to your point, if you're not doing that well, it could do the opposite for you where suddenly you're giving all of this data to these people and that maybe you don't want to or you don't want them to be able to change the data in certain ways. You mentioned the maintenance that people need to think about paying for over time.
How should people budget for that? What should they do to set themselves up for success?
[Kelson Erwin] (36:54 - 38:37)
Well, first they need to know that they need a budget for it. It's sad when people don't know that and then they go within an agency or they have some staff build in and they find that out later. And then they need to talk to somebody about that early on in the project.
What type of budget is going to be needed because it depends on what tools are being used and there are certain tools that are paid, right? Like if we want to integrate with some software that sends text messages out, you need to pay for those text messages. There's not a way to send those for free.
So you need to expect that there's going to be some hosting costs. There's going to be some costs for making updates. There's a cost to pay the team to do that.
There's a cost for monitoring it. And so, you know, early on in the process, there should be a conversation around that. And usually, at least with our organization, when we're doing the initial requirements gathering, we'll come back to our clients or potential clients and say, hey, this is what we're looking to build.
This is how much the ongoing maintenance is going to be and this is what's included and this is why it's going to be this much. I don't have any clients that pay more than $500 a month in ongoing maintenance. The average is like $125 to $300.
So it's, you know, it's not incredibly expensive, but it is definitely something that they need a budget for. And it could be more expensive than the top number that I gave if they're doing something that's really expensive, you know, or if they have specific needs. But it's something that we'll, you know, we like to disclose early on in the process so that, you know, you and your team can budget for it.
[David Guthrie] (38:37 - 39:05)
It's so worth it. I don't think anybody really bats an eye at spending $500 a month, you know, to maintain a system like that because, you know, if it wasn't worth more than $500 a month, you never would have built it in the first place. It wouldn't have been worth it in the first place, right?
So yeah, these are the systems that allow you to scale your business, that allow you to automate processes. Huge value for the business.
[Kelson Erwin] (39:06 - 39:15)
Yeah, especially when the alternative is hiring staff, right? Like you're going to hire staff or you're going to pay $500 a month. Easy decision.
[David Guthrie] (39:16 - 39:36)
So you mentioned tech debt earlier or technical debt. And I remember hearing this term, you know, several times early on in my career and being kind of confused about it. So can you explain just really quickly what tech debt really is and what are the strategies that people can use to avoid tech debt when they're developing an API?
[Kelson Erwin] (39:38 - 42:21)
Yeah, so, I mean, technical debt is the, I guess that you could say it's like the implied cost of having to do rework by doing an easier, quick solution rather than doing a better approach that would take longer to build. It's kind of doing like a scrappy and quick solution. Basically, what ends up happening is over time, the code base becomes more and more difficult to add new features to.
It increases the amount of bugs that are in the system, increases the time it takes to bring somebody and get them familiarized with the code base. And so, you know, the mitigation strategy is really to weigh the pros and cons of different implementations when we're writing the code. Because there is a time and place for a scrappy and quick strategy, but it's important to make sure that that's a decision that's made and not just, oh, we need to get this done in two weeks, so we're going to do it in the quickest way possible.
You know, it's kind of like when you build a home, you want your contractors that come in and build the walls and put in your foundation or whatever, you want them to do the right thing, not the fastest thing. If you're going to build a shed in your backyard, the quality of that shed and the requirements of how sturdy it needs to be may vary from what you'd expect in your home. So, it's important to think about this and it's important to talk about this, especially if you're an agency like mine where we're trying to build long-term solutions and have long-term relationships with our clients.
It's a conversation that we like to have and a lot of times will involve our stakeholders and, you know, our clients and all the stakeholders in that decision and say, hey, like, is this something that, like, here's our different ways of implementing this. That's kind of the definition, I guess, and then the way to mitigate is by having, like, really strict standards, regular reviews of the code, refactoring that code on a regular basis, having good documentation and good testing. And really, it's like knowing where that tech debt exists in the code base and so you can schedule it and you can make it a part of a regular process.
So, yeah, I mean, tech debt is really important to understand and it's important for the long-term success of the software. So, yeah, it's something to think about and talk about with whoever's going to be building it, building your API for you.
[David Guthrie] (42:22 - 42:40)
Yeah, so, I mean, we're talking about kind of the maintenance, the ongoing work that needs to be done. So, sometimes tech debt could be taken on during the initial development or sometimes your tech debt could grow after that, right? Like, if you just kind of put off certain maintenance things.
[Kelson Erwin] (42:40 - 44:01)
A good way to explain it, I think, a lot of times the way that tech debt comes about is imagine you build yourself, like, you're going to build a home and this is how it works with software. It's not like building homes but this is how, like, if we were to build homes the same way we build software, this is what it would look like. You build your house and then one day you just decide, oh, you know what?
I want another room. You know, I want to add another floor onto this. Things could get sloppy over time.
Like, you're adding another room but you didn't really consider that, you know, adding another floor, the stairs are going to go here and it doesn't really look right or, like, as you add things on, it kind of makes a mess around whatever is there already. And that's what happens in software. You have some code that does this functionality and then something else is added or removed and you have all these moving pieces and so things start to get a little messy.
And so the tech debt part of it is coming back to that code and cleaning it up later or during the actual implementation saying, all right, this needs to be restructured. And, you know, weighing the pros and cons of doing that restructuring an hour later.
[David Guthrie] (44:02 - 44:55)
Yeah, it's like how many times during the course of your work are you going for now, right? How many times do you say for now when saying what your solution is going to be and how often do you actually go back and implement the long-term solution that you were thinking about at the time, right? So, yeah, that makes sense.
And just like any kind of debt, you don't want to build up too much of that because over time that could become more and more of a risk to your business as things break or they become more difficult to use. So how does that connect with security? Is that, I mean, security seems like a higher priority where you don't want to say for now when you're talking about your solutions.
But when it comes to the security of an API, what are the most critical considerations that people should have? What are the things that are often overlooked?
[Kelson Erwin] (44:55 - 48:32)
Yeah, I mean, it does kind of connect. Oftentimes applications that have a lot of technical debt also have security vulnerabilities. It's just the nature where, you know, if you're going to do everything quick and scrappy, then you're probably not as focused on security.
But, yeah, security is definitely a really important thing to think about just like tech debt. You have these systems communicating with each other and you're sending messages back and forth. And so you want to make sure that things can't intercept those messages and you want to make sure that nobody can use your API in a manner that you don't want, right?
That you don't want somebody having your data that shouldn't have it. So for my history and my experience, the truth is there's a lot of apps that are rushed or their budget constraint where security is an afterthought is something that they're going to add on at the end or no security is ever added. The amount of insecure applications that I see on a day-to-day basis would boggle your mind.
So, you know, it's important to adopt a security-first mindset when, you know, at all stages of development. Kind of the way that works is we need to be mindful about who has access to what systems, whether programmatically or manually, who has access to the data. We need to think about what are common vulnerabilities?
How sensitive is this data? What would happen if this data did get into the wrong hands? Is that a problem?
Is it not a problem? And we need to consider the risks of a security breach. You know, we also need to be talking about what are the best practices around how this data needs to be handled and manipulated and stored.
It's important to encrypt the data during transit, for example. That's what that SSL is, you know, the lock in your browser. What that does is that ensures that the data is being encrypted and the messages that are being sent from one place to another are all secure.
Depending on what type of data it is and how secure it needs to be, you know, we might want to hire a third party to do a security test and audit the API, which we've done a number of times. And then it's important to also monitor who's using it and have some sort of logging system to understand how it's being used and prevent unintended usage of the application. So, yeah, I mean, there's a lot.
You could really, we could go down quite the rabbit hole talking about like DDOS and all sorts of ways that people take advantage of insecure systems. But really, if you follow best practices and you consider the common vulnerabilities and you test the API and you really keep security as something you're thinking about, modern systems are really secure. They really are.
And for most of you, people probably are not going to be intentionally going to your API and trying to hack it. A lot of times these people get hacked because of automated automated systems that go out and look for these vulnerabilities. They try common attacks and that's 95% of attacks are just automated attacks.
So those are easy to mitigate just by following best practice.
[David Guthrie] (48:32 - 49:21)
It's interesting how technology is changing over the years and the way that we have to adapt our approach like you were saying with security and make sure you've got the patches as people are adjusting the way they're making attacks, you need to be adjusting how you're protecting against them. How about, let's talk about the progress of how people are building these API integrations. Obviously, AI and machine learning are big topics right now in the tech space.
They're changing everything from how we write the code to how we consider, to your point, bots, the things that bots might be able to do and what we might need to protect against. Have you seen any creative or innovative ways that people have implemented a new API with these new technologies like AI?
[Kelson Erwin] (49:23 - 52:20)
Yeah, 100%. You have the development of the APIs where now APIs are faster to write. We can do the development work for them more quickly because things like ChachiBT and Claude are really good at writing boilerplate code.
They're good at the boilerplate code so we're able to save a little bit of time by not having to write that ourselves. With that though, we're starting to see more code churn, more low-quality code that can find its way into applications and along with that, we're seeing more security vulnerabilities. With the benefit and the speed that the AI can give us in the development, it's important to have really thorough code reviews and have software engineers that really understand what good code looks like and make sure that everyone understands what that code is doing and why it's there.
As far as what we can do, like how we can integrate AI specifically into the API is AI is allowing our APIs to have more intelligent decision-making abilities and also the ability to use natural language as its input or output, meaning the APIs can now make decisions on themselves. They can classify things. They can tell you the sentiment of text and then they're also now able to respond as if it was a human.
Instead of responding, a lot of times they'll respond in a way that only a computer might understand. A lot of times now they're able to respond in a way that a human would understand or in human text, like a natural language text, which is really cool and it really allows us to do a lot more. We could write emails now because we can have the output as natural language and before it was all templated where the emails that would be sent out would be high place holder than the boilerplate text.
Now they can be very customizable and indistinguishable from a human. We have a lot more internet of things where you have bots that can put in data, monitoring real-time systems like in warehouses and stuff like that and we're able to track that all in one place, which is pretty new and really cool. And so yeah, we're seeing a lot more sentiment analysis, a lot more chat bots, a lot more utilization of real-time inventory systems and little bots, like little hardware bots that use APIs to add a lot of data in, which is really cool.
I'm excited.
[David Guthrie] (52:21 - 52:36)
Yeah, that's awesome. How do you think this is going to evolve? How are APIs going to look in the next five years or 10 years or so and what sort of things should businesses be?
Thinking about when they're planning for the coming five to 10 years.
[Kelson Erwin] (52:37 - 54:09)
Yeah, I think that more businesses are going to want to have APIs. It's very similar to how we move to the web where before a lot of businesses were running their business on paper or spreadsheets and now everybody wants to be on an online system of some sort. All their competitors move there and they're like, Oh, I'm going to get left behind if I don't.
That said, I think that customers and vendors and third parties and stakeholders in the organizations are going to expect businesses to have APIs. They're going to expect that level of interconnectability that is going to be required to compete in the future. And the businesses that do have and have invested heavily in APIs will gain a big competitive edge over those that haven't because of their ability to reduce their operational cost and increase efficiencies.
And they'll also be ready to implement the new technologies as they come out, right? Like chat GPT and Claude are really cool. They're new.
They're emerging. People are integrating them. But if you don't have an API, then how are you going to utilize that technology?
And so it's important to stay with the times if you want to continue to save the times, I guess. And that's where I think we'll see APIs in the next 5-10 years. I think they'll become a lot more common and the businesses that have them are going to win.
[David Guthrie] (54:10 - 54:22)
Well, thank you so much for joining me today, Kelsey. And I think that's a really good overview, hopefully valuable for anybody watching this who's thinking about developing an API. Do you have any final thoughts or tips you'd like to share?
[Kelson Erwin] (54:23 - 54:55)
Yeah, yeah. We do free consultation for this and web applications and all things web. That's all we do is web.
So if you want to talk with somebody, if you want to run your idea past somebody or get another set of eyeballs on your idea, just go to our website and schedule a call with us and we'll jump on there and help you the best that we can or put you in the right directions if we can't help you. And so, yeah, we'd love to talk to you. And then if you have any questions, leave them in the comments.
[David Guthrie] (54:55 - 55:03)
Yeah, let us know what you'd like us to talk about. Any questions you'd like us to clarify. We'd love to make an episode about that.
