Subscribe
Share
Share
Embed
Welcome to the Ksense Technology Podcast where we discuss the trends in software development, web applications, and how custom software can help businesses scale. Ksense is a full-stack software development company using state-of-the-art technologies to build cutting-edge applications. With over a decade of software development experience, our team is confident we will deliver results for your organization.
Alright. Welcome. I'm here today with Kelson Erwin. He's the CEO of kSense Technology Group, which is a software company that builds business tools and portals for all kinds of organizations. And today, I'm excited to talk about how to go about vetting a web development firm and how you can pick the right people to hire for your software projects.
David Guthrie:So welcome, Kelson. Thanks for joining me.
Kelson Erwin:Thanks, David.
David Guthrie:You bet. Awesome. So my first question is just around understanding business needs. What are the key factors that businesses should consider when they're determining their needs for custom web applications?
Kelson Erwin:Yeah. So I think 1 of the really big things that a lot of people don't consider is whether or not they actually need a custom web application. There's so many off the shelf solutions that could be chosen. And so 1 of the things that a lot of people do is they jump the gun thinking they need something custom. When in reality they don't.
Kelson Erwin:Which you probably think is funny hearing that come from somebody who spends all day building web applications, but it's the truth. There's no need to reinvent the wheel. See if there's a software that already exists that you can go and find and just pay the monthly fee for that software. The time when you know that you need custom software really has to do with when those off the shelf solutions are no longer meeting your need, when you feel like they're more of an obstacle than a solution for you, that would be the time when you start considering a custom solution. You don't wanna force yourself into a box where it's hurting the efficiency of your business, where you have all of these workflows and you're not using the software the way that it's designed.
Kelson Erwin:But yeah, that's, that's 1 of the biggest factors that I think a lot of people don't consider. Another 1 is the budget consideration of what a custom application costs to build. The funny thing is you can go on like a freelance site, Upwork or freelance dot com, and just look at the different jobs for software applications and what people think they're going to be paying. And in reality, there's a reason that most software projects fail. And the reason 1 of the reasons for that, not the not that this is the exclusive reason, but people, a lot of times, underestimate what it costs to build good software.
Kelson Erwin:If I go on Upwork, I can see people posting a job that's going to take 200 hours with a $2, 000 budget. And you're not going to find the level of expertise in order to deliver a quality product for anywhere near that much money. In fact, the the whole idea that you can pay a flat fee for a software project is is just a misconception in of in and of itself. So, you know, when you're, when you're evaluating and trying to determine your needs, you want to make sure that, first, you do need a custom web application. 2nd, you wanna make sure you you're aligned with the budget requirements in order to to create something good and not have it become a failure.
Kelson Erwin:You also need to understand your timeline. How soon does it need to be built versus how long is it going to take for quality for quality software to be developed for you? And then lastly, I think it's important to understand what features you need. Why is the off the shelf product not working for you? How does it need to work?
Kelson Erwin:What is the user journey going to look like in your custom software once it's built?
David Guthrie:Yeah. Would you say that plays a big part in the decision of who they hire as far as, you know, we we need a clear picture of our timeline, our budget, and, you know, a clear vision of what the project needs are. How important would you say it is for clients to have a clear vision of their project before they even approach somebody?
Kelson Erwin:It's incredibly helpful. Now a good business analyst should be able to dive in with you and essentially partner up with you to help you understand how software can solve the problems, but they're not gonna, they're not gonna know your business. They're not gonna know what the pain points are. They're not gonna know the day to day operations. So a lot of times what I'll have people do is draw out your entire business as if it was a flow sheet, you know, a a flowchart.
Kelson Erwin:You know, you have a clients come in on this side, They onboard. This is what the onboarding process looks like. And then all the way through until they either repurchase or or whatever it is. Right? You draw it all out with arrows and everything on paper.
Kelson Erwin:Then what, what can happen to help you establish that vision of how the software is going to help is the business analyst will look at that and say, Hey, I understand this is why you're not fitting into these off the shelf solutions. This is your workflow. I understand how your business operates. Now let's talk about some options here. What are the trade offs, between these options?
Kelson Erwin:And let's find the best solution for you.
David Guthrie:So let's talk about how to evaluate the expertise and the experience of whoever you want to hire to build a software project. What are some critical indicators of somebody's expertise and their experience?
Kelson Erwin:Yeah. So once you understand that you actually need a web application and you have a well defined vision of what that's going to look like, what your process looks like, and you understand what your pain points are, then the next step would be to evaluate the different options that are out there. You have a couple. You have an in house team versus a firm. Right?
Kelson Erwin:And we're talking about firms here. So but the the process for evaluating just about anybody is gonna be the same. That's gonna be looking at their previous work that they've completed. You're gonna wanna get on a call with them and say, hey, show me a situation. Show me a business that had a similar pain point to mine and how you solved it.
Kelson Erwin:And I wanna stop there either. I would ask them for testimonials or references that you can call up. And the last indicator I think would be the technical expertise. This might be more difficult for people that are not they're not technical, but I think there's some due diligence that needs to be done where you ask them, hey, what technologies are you using? What with the pain points that I've presented and the requirements that I think we have.
Kelson Erwin:For example, we need 5, 000 users and we need this much this many data points. Right? What languages, frameworks, and technologies are you going to use? And then search those and look at how modern are they? Did they come out in the nineties?
Kelson Erwin:Did they are they more modern? Are they the best tool for the job? That might be kind of challenging. Nowadays, with modern LLMs like ChatGPT, you could probably just ask it and have it help you to do some of this research. You could say, hey, I talked to a software development agency to build this project.
Kelson Erwin:Here are the requirements in terms of what the user is going to be able to do. They're suggesting to use MongoDB as the database. What are the pros and cons of this tool? And look at them and and make sure they align with your vision. And also, they should be able to explain to you why they do as well.
Kelson Erwin:Make sure their explanation makes sense.
David Guthrie:So is that kind of how you would verify their technical their technical skills is, like, you know, just ask them clarifying questions about what they're planning to do and then do your own research to verify whether that's the right approach. Do people ever come to you and they say, hey. Like, before we hire you, we wanna see some sort of, you know, demo, or, you know, a test project or anything like that.
Kelson Erwin:Yeah. Yeah. All the time. People want to you know, they wanna test drive the car before they buy it. And they also wanna know how many horsepower the car has and all of the the things that are under the hood even if you're not a mechanic.
Kelson Erwin:Right? You wanna know what type of performance you're gonna get. Are you gonna get an app that shows you a white page and takes 3 seconds to load every time you click on a link? Or are you gonna get something that it's instant, it's snappy, and it's high performance. And you can you can look at some projects and you'll see, you know, if you look at a project and especially the ones that they're demoing to you are gonna be probably their best ones.
Kelson Erwin:And so you can look at that and say, okay, this is most likely the top quality of what I'm getting. Does this meet my needs?
David Guthrie:So what what other things should they look for? We talked about, you know, is the application fast? But when you look at a portfolio of work, what should you be looking for in that work that tells you, okay, this is high quality work?
Kelson Erwin:Yeah. So I think 1 really good indicator is who the clientele is. If you go on an agency and you can look at the previous clients and there's none none of the company names that they have on there or any of the case studies are companies that you've ever heard of, Or maybe they're companies that are not even similar to yours at all. Right? They're all in 1 industry and and you have no dealings in that industry.
Kelson Erwin:That's a pretty good indicator. You're looking for somebody who has solved problems that are similar to the ones that you've solved. And cut solve problems for companies that are similar to your company.
David Guthrie:So once, once we've seen their portfolio, what else should people look for in that in that firm? What are the other qualities that they should have?
Kelson Erwin:There's a lot of qualities that we could go over here. It's not just the technical side. Right? You also have the communication style. You have how they bill you, their development methodology.
Kelson Erwin:There's a lot of things to consider. To break it down, what you probably want to see is a firm that's going to do agile development. And basically what that is, is you're going to receive working software in your hands on a very frequent basis. Here at Ksense, we're delivering working software to our clients every 3 weeks. Doesn't matter if you start the project tomorrow, you're getting something in your hands every 3 weeks.
Kelson Erwin:And we go in this iterative cycle because that's how you build really good software. It's very difficult to document the whole thing and then build it like you would build a house. It's not it doesn't work that way. Businesses are evolving, and web applications need to be flexible to changes in businesses and changes in requirements. So that's the first thing.
Kelson Erwin:And then everything kind of cascades behind that. Right? If we're working in what we call sprints, these iterative cycles, then we want a communication cadence that supports that. And we like to recommend to to our clients that they join our Slack or Microsoft Teams channels so that they can communicate with us in real time. We like to see a at least a weekly meeting on the calendar with all of our clients.
Kelson Erwin:We just want to be able to check-in and really become a partner to our clientele. So those are really good things to to look for as well. And then you want to make sure that you're not required to do a lot of homework. You wanna ask them, oh, what's what's required of me? Well, here's the homework that you should be expected to do.
Kelson Erwin:You should be expected to know what your pain points are and be on a call once a week in order to talk about them with the business analyst. You shouldn't be asked to do more than that. You shouldn't be asked to do any mock ups. You should not be asked to write any user stories or build any diagrams. You know, you you should get on that that call once a week, explain your business, and then the business analyst will converse with you to decide how custom software can solve these problems.
Kelson Erwin:And then you need to decide on which 1 you think is the best given the trade offs at play and sign off on that. I've heard of firms that, you know, try to offload a lot of the work onto you. And I think that that's unprofessional considering that these are careers that people go to school and study for. And so you shouldn't be expected to do that. And then lastly, the the technology.
Kelson Erwin:I can't reiterate enough, and I think that's because I'm in the tech side of things. Make sure that we're using modern technology to build your applications. We'll be able to build them much faster, and there'll be way higher performance.
David Guthrie:So, I liked some of the points you were making about communication and, you know, the cadence of communication. What are some red flags when it comes to communication with a development agency or a firm that would make you take pause and go, maybe this isn't the right tech partner for us?
Kelson Erwin:I think that if you are often needing to talk to developers, that's a pretty big red flag. There should be 1 point of contact, maybe 2, depending on the size of your project. And those should be the only people that you're talking to. You shouldn't be required to speak in any sort of tech lingo, And they shouldn't be speaking to you in tech lingo. They should be speaking to you about business problems and they should be demonstrating to you mock ups or or examples of how the process is gonna work in layman's terms terms.
Kelson Erwin:So those are some pretty big red flags. Additionally, if the only way that you can get a hold of them is email, that's probably a pretty big red flag as well. If they're presenting like a flat rate project where they're going to build the whole thing, and then you're not gonna hear from them for several months, that's also a really a really big red flag.
David Guthrie:Tell me a little bit more about the development process when it's done right. What does a typical development process look like from the from what we already talked about, where there's a little bit of consultation and communication and, you know, a little bit of vetting around around what technologies you'll use. Past that, how does the process go?
Kelson Erwin:It depends on who you hire. And and every agency is gonna have a little bit of their own development process. But let me tell you the things that I think you should look for and I'll also explain to you how we do it. So number 1, you're gonna want somebody who's doing agile development. I don't care what style of agile they do.
Kelson Erwin:It doesn't really matter. I think some are better than others personally, but they'll get you to the same place. And essentially, what agile is is it's the iterative process versus what we call waterfall, which is where you document the whole thing, you build it, and then you deliver it. It's very rare for a waterfall style project to be built very well. And and when it is built well, it ends up being more of an agile process in the end because what happens is it's delivered.
Kelson Erwin:It's not right. A change order needs to be submitted. There's negotiations over pricing, yada, yada, and then goes through the development cycle again. And it ends up just being a very inefficient style of doing agile. As, as inefficient as you can possibly get.
Kelson Erwin:You definitely want a firm that does the agile process and gives you software on a on a very frequent basis. The the more you can get into it, the better. Because that's more feedback you're gonna be able to have, and you'll make sure that the project stayed stays aligned with your vision through the whole thing. How we do it is that same way. We'll have our business analysts talk with you about the pain points, starting with the most impactful to the least impactful in terms of software to ROI.
Kelson Erwin:Meaning, what pieces of software will have the biggest impact, the biggest return on investment for your business. And those options will be presented to you in the form of what we call a user story. And these are little kinda, little cards or or small pieces of work that define what a user is able to do in the application. And they go something like, as a user, I can do this for this benefit. Right?
Kelson Erwin:So as a user, I can log in to the application so I can utilize the application. And you'll have a bunch of those, and those demonstrate what work is going to be done. Then what we do is we send those that entire sprint, the grouping of user stories is a sprint, to our lead architecture engineer. And what they'll do is they will write up the best technical approach and on how to build it. So they'll look at them all and they'll say, hey.
Kelson Erwin:For this, we're gonna need to set up this system or we're gonna wanna utilize this technology. And then from there, it goes to you to approve it. So you'll get to read them all. You'll get to you'll have already discussed the the pros and cons of each 1. And hopefully, it aligns with exactly what you talked about with your business analyst.
Kelson Erwin:And it'll have the timeline to completion for that sprint, along with our estimate on how how much money it's gonna cost, and you'll get the option to approve it. Once you approve it, it goes to our developers. We like to have a couple of developers that are assigned to your project so that they can become familiar with not only your code base, but your business, understand your business processes and really how the business runs and what the software is supposed to, you know, the objective of the software from a high level. And then they do the development work, it goes through QA and then it gets pushed into a staging environment. And that's where you'll get to use it and provide feedback.
Kelson Erwin:And then after that, the business analyst will show you it. They'll demo it for you, and they'll ask you what you think. And then they'll iterate. We'll do it again and again and again until the whole project's done.
David Guthrie:Yeah. So I'm noticing there's there's quite a bit of back and forth throughout that process with the client, you know, kind of checking in, making sure that they're they've got eyes on how their project is developing. But like you said, not putting the homework on them. Right? They're they're staying as involved and aware as possible without taking all of their time to actually be the ones that are managing the project.
Kelson Erwin:Absolutely. And when it comes to software, there's a 1, 000, 000 different ways to achieve that business objective. And so we want to make sure it aligns with the stakeholder that all of the stakeholder's visions of it. Right? Does it align with how the the end users are going to use it?
Kelson Erwin:And does it align with you as the business owner on how you see it improving your business? And I I like to say that the reason 1 of the reasons we do the iterative agile methodology is because writing software is a lot like if we were hired to write music. If if you just wrote up a little piece of text on what you wanted us to write, what what type of song you wanted us to produce for you, what are the odds that, that, that aligns with exactly what you have in your head? Probably very low. The odds get better and better the more times we check-in.
Kelson Erwin:You know, I can say, hey. Look. Listen to this melody or listen to these 10 melodies. Which 1 do you like the most? Which of these snippets of lyrics do you like the best?
Kelson Erwin:And so it's it's really the same with software. And that's why as you browse the web or or anytime you use any software, you'll notice this software is not very good to use and this software is really great to use. And and really, what is the difference between great to use software and bad to use software? It's really a lot of times, it's the iterative process was skipped. Right?
Kelson Erwin:They they stopped looking at the needs of their stakeholders, and they decided to build based on whatever they felt like were the needs without any actual data to back that up.
David Guthrie:So when it comes to those those considerations, you know, as you're you're iterating, how can clients ensure that that their firm that they've hired is using up to date technologies and that they're following the latest design trends or the things that people are learning out there about, oh, you know what? This is the best way to build, you know, for example, a CRM. It's it's most useful to have it organized in these ways. Like, how can they make sure that that their firm is staying up to date on those things?
Kelson Erwin:Yeah. Great question. So it's not really that difficult. And I think there's 2 parts to it. The first part is you're going to ask them what technologies they're using and you're gonna research to make sure that those those technologies are up to date.
Kelson Erwin:Right? They're if they're recommending that you build the project in jQuery or Ruby on Rails, then it's gonna be very obvious that that is not up to date. And then in terms of the the UI, UX component of it, modern web applications are not that difficult to build with great UI UX in mind. You can look at some of the big players that have massive web applications like Facebook, Twitter. And I'm not saying that those are the best UI UX examples, but they've done a lot of, you know, you can tell when you're using an application if it's built well.
Kelson Erwin:And your application that's built for you should be to the same standards as those large those those large organizations. In fact, a lot of times, the really big players in the space are the ones that are setting those trends. The the way that you leave comments in most applications represents the way you do it in Facebook. So you can ask yourself, hey, look at these other pieces of software that I like using and everybody likes using and are really sticky. What does their UI UX look like?
Kelson Erwin:If yours isn't like that, then the per the person that or people that are working for you are doing something wrong.
David Guthrie:And how important is UI UX design when it comes to just business tools, you know, operational software that's never gonna be in front of a customer? Does it really matter how it's designed?
Kelson Erwin:Yeah. So the UI part of UI UX, right, is the user interface and the UX is the experience. So the difference is what does a person see and and what is the experience like for that person to kind of break them apart. Now I would say the UX part of it, what is the experience that somebody has is very important regardless of the application, whether it's public facing or not. The UI, on the other hand, there's a lot of little tricks that can be done to save a lot of money in terms of the UI.
Kelson Erwin:1 of those is using templates or pre built components, right? A lot of things, for example, buttons or drop downs or inputs, these are already prebuilt to look good. Same with the templates. The template will have the sidebar or the top bar or however you have it. So when we're building, like, an internal application that is all gonna be used by just the people that work at the organization, nobody else.
Kelson Erwin:It's not public facing. It doesn't represent their brand. We'll use a template. We'll use some pre built components. It'll look really nice.
Kelson Erwin:It'll be really fast. And then we'll focus on the UX side of things a lot more than the UI. We won't be mocking up every page of the application. It won't follow their brand to a tee. It's not gonna be the most beautiful application that ever existed.
Kelson Erwin:The UX performance that or UX side of things will be something that we put effort into because the UX will determine whether somebody enjoys using Right? It's a good Right? It's a good example of good user experience. When you log in, you should see what you need, and you shouldn't see things you don't need. And so those are things that are highly considered by the business analyst when they're, when they're coming up with it.
Kelson Erwin:And and a lot of times we'll do like a low fidelity mock ups, which are essentially you can think of them like a little bit better than hand drawn sketches. They're just like a digital hand drawn sketches that show how somebody's going to use the application, but not exactly what every button's gonna look like and what it's gonna look like when you hover over that button and and everything to that level of detail.
David Guthrie:Makes sense. So you probably probably don't need to go to the lengths that Facebook or Twitter has gone to, but it's still important. You still want your employees to be able to navigate through the app effectively and not have a terrible time.
Kelson Erwin:Yeah. And there's a lot of money that can be saved by, if you're building an internal application, by not mocking up every page, by using Global Styles, prebuilt components, and templates. And you'll get killer looking apps. You really will.
David Guthrie:So speaking of that, you know, saving money, we've talked a couple of times about budget. Let's let's clarify a couple of points here. How should clients approach the budgeting process? How should they think about the budgeting process? Earlier, you said fixed price projects are a misconception.
David Guthrie:What does that mean?
Kelson Erwin:Yeah. So generally, fixed price projects are a misconception. In a fixed price project, somebody always loses. And let me explain what I mean by that. If I, as an agency, am willing to present a fixed price let's let's go back to my little analogy about making music.
Kelson Erwin:Right? If you ask me for a song and I give you a fixed price, then I'm taking a pretty big risk myself because I'm not sure when you are ever going to be satisfied with the song that I make for you. Especially at the very beginning of the process when I haven't. I don't know what kind of lyrics you like. I don't know what melodies you like.
Kelson Erwin:It's a pretty big risk. So what do I do to offset my risk as the person that's doing this development work? What I do is I take how much risk I think I'm going to need and I add a little bit to it to be really safe, and I give you that price. So I say, okay, we charge x per hour. This project's probably gonna take this many hours.
Kelson Erwin:What's the worst case scenario? That's the price I give you. So who loses in that situation? Well, you do, as the business owner. Right?
Kelson Erwin:Or I completely misjudged of the project or the business owner takes advantage by adding things into the scope that were originally agreed upon. And then I lose as the agency by having to do all this free work and things I didn't even consider. And so somebody always loses. There's never a situation where anybody walks away from a flat rate development project and both people are satisfied. It it's just it's very rare.
Kelson Erwin:I've never heard of a situation where that's true. So a time and material models, that model works a lot better in this industry where you do small pieces of work and you get paid for that small amount of work, and you just iterate and iterate and iterate. Because then, there's no worry about scope creep. Well, no no worries in terms of budget for scope creep at least. Nobody ever feels like they're getting ripped off.
Kelson Erwin:You get paid, you know, the the agency gets paid for what they do regardless of of their risk level. And if you're unsatisfied and you need, you know, tons and tons of revisions, hopefully you don't. But if if you do, then the agency's covered and and you also don't feel like you're getting taken advantage of.
David Guthrie:So it's a it's a time and materials model, sounds like, is the best 1 for the industry. How should your how should clients go about budgeting for that type of project?
Kelson Erwin:You need to find out first what tier of budget you need. Right? You're not gonna know exactly what it's gonna cost at the end of the day because it really depends on how many iterations and how long the project goes for. And we like to say that web applications are never done. And if you look at web applications around on the web, it's pretty obvious that that's the case.
Kelson Erwin:Like when was the last time that Facebook put put something out that's new, right? Or or any web application, they're always putting out new things. There there's always new features. There's always bug fixes. And so if you can think about it like that, this is an asset and it's going to improve over time.
Kelson Erwin:It's gonna get better and better and it's become more and more valuable. Then the budgeting process starts to look a lot more like if you were to hire an employee than if you were to buy, like, some sort of business asset, a 1 time fee. And that's the way that you need to think about it. You need to say, hey. I understand that this web application is an asset.
Kelson Erwin:It's gonna get more valuable over time. And I'm going to budget it just like everything else that gets more valuable over time in my business. And after you know kind of what the ballpark for your minimal viable product is, then you can kind of essentially reverse engineer it. So if you know, hey, this we have all these features that we wanna build. It's gonna probably be between a $10, 150, 000.
Kelson Erwin:You say, okay, what do we need per month to go into development and then set up a monthly budget that you're comfortable with? And then 1 of the nice things is if you know, okay, this app's gonna cost between a $100, 150, 000, you can throw a lot of resources at that and make it move really quickly, or you can go slower if you need to. But having, like, a cadence, a monthly budget and thinking of it that way is really going to help you in having a successful web application.
David Guthrie:So once once it's built and you launch the app, you know, a good agency here, what, what sort of support and maintenance would they offer after that 0,
Kelson Erwin:it depends on what your project is. If it's something that can't go down or somebody dies, then you're probably gonna want some sort of SLA with uptime monitoring and whatever performance metrics on the application that need to be monitored, and there needs to be a really solid contract in place. However, if you are building, like, an internal CRM and no one's gonna die, then there's actually not a lot of stuff that goes into the post launch. It's mostly maintaining the servers that it's on. There's some technical stuff like making sure that the operating systems up to date, making sure libraries are up to date, SSL is good.
Kelson Erwin:And then you're gonna need to pay for the hosting and maintenance of these these platforms. So with our clients, they are essentially, you know, most of them that have, like, a custom CRM are paying less than $500 a month for these web applications, which even some of our bigger ones are, you know, I can't think of many that are paying more than that. So there's not a lot in terms of budgeting, and there's also not a lot in terms of what you as business owner, or stakeholder are going to have to do. 1 thing that should be said, 1 misconception that I think a lot of people have is around bugs. No matter how good you are at q and a, you know, no matter how many times you test it, there's always going to be bugs.
Kelson Erwin:And that should be built into the post launch process, the maintenance process. You should expect that every once in a while, something is going to go wrong, and there needs to be some sort of budget allocated to fixing that. So it's something to keep in mind even if you're not doing active development. A good example just to kind of illustrate the point would be if you connected with another another software product, like, if you had we call it an API integration. Right?
Kelson Erwin:You say, you know, I want to bring all of the Zoom calls into my application. There could be a problem with Zoom 1 day and, you know, they might change how they're doing things. And so that might need to be switched out. And this is something that happens. Every piece of software has a life cycle, and they are also adding features and changing how they do things.
Kelson Erwin:And so that's something that a lot of people don't really expect in terms of post launch. But there should be some sort of budget that says, okay, there's probably gonna need there's probably gonna be this many bugs, so I would assume you're gonna wanna pay this much per month.
David Guthrie:So how can the firm's approach to long term support impact the success of the web application? Is it is it something that they really need to be thinking about? Or are clients usually pretty aware of everything that needs to be going on?
Kelson Erwin:Yeah. It's a great a really good question, actually. Because a lot of agencies are not interested in long term support. They're interested in building it and, and that's it. Like, they don't want to support it Because the money is not often made in the support side of things.
Kelson Erwin:The maintenance, the updating, the operating system. That's not really where the money is made. So it's important to talk to, when you're talking to these firms, to find ones that that are currently doing this type of maintenance and ask them about it. Like, what is your what is your support look like? Do you have client like, how many clients do you have that that are only on maintenance that haven't developed new features for a while?
Kelson Erwin:Ask them that and, and say, Hey, what happens when the application is done? And if they're able to present you with like really well thought out or like documentation of what's all that's included and how they treat the whole process, then it's probably a good indicator that that's a good firm. If they don't sound like they know what they're talking about, they probably don't. And if they don't have any documentation, then that means they're probably either not doing that work or not doing it well.
David Guthrie:So what are what are some common pitfalls throughout the, the development process? What what are common mistakes that businesses make when they're selecting a development firm?
Kelson Erwin:A big mistake that that businesses make when they're selecting a development firm is selecting only based on how much it's going to cost or how much they think it's going to cost. And so I think a pretty big mistake would be going for a low bidder. What ends up happening a lot of times when an agency decides to that they're gonna save money by going to the lowest bid is they actually end up spending more money in the long run because those agencies that are doing the really low bids, they're hiring very low level talent. And that low level talent is generally trying to get the work done as quickly as they can. And so quality is not at the top of their mind.
Kelson Erwin:Then what ends up happening is somebody else has to come through and redo that work, somebody better. You'll end up having a lot of headaches because, you know, the application's riddled with bugs. It's challenging to even use it. And then, you know, then you have to go through all the work it took to select the first agency when it comes to vetting and going through interviews and hire somebody else, then all the time it takes for them to learn your business system, learn the software that was already built. The quality if the quality is really low, it's gonna take somebody a really long time to dig through all of that.
Kelson Erwin:And then you have to pay somebody to do all that work, and then fix it. It's really a pretty big nightmare. It's probably the biggest nightmare you can find yourself in if you if you go with the with a low price agency, you're very likely to find yourself in a situation where you are just hating life.
David Guthrie:Is there anything that people can do to try to protect themselves throughout that process, to try to avoid some of those those pitfalls?
Kelson Erwin:Well, they can, they can understand that a higher price, especially when it's like how we do it, where we're charging by the hour. If if you're paying higher by the hour, usually you're getting faster developers because they're more experienced. You're also getting developers who they write really good code the first time. So you end up having less problems down the road. You end up having a a more healthy code base, which impacts the whole really your whole business if you're running your business off this piece of software.
Kelson Erwin:It affects how your employees, you know, their mood. I'm sure your mood's been ruined by, piece of software that you rely on not working or, or being down. It it just has this huge cascade effect throughout your entire business. Really the way to protect yourself is to select a good agency and understand that, hey, just because it's a higher dollar per hour, doesn't mean that the project is actually gonna cost more money over the long run, if that makes sense.
David Guthrie:Yeah. If it's worth developing something custom, it's it's worth doing it correctly and get something that really is gonna work for you. Yeah.
Kelson Erwin:And I would even go so far to say that the biggest way you can save money is by spending more money on on your agency.
David Guthrie:So, thanks so much for for taking the time to walk through that. Do you have any final tips or advice for anybody out there who's looking for a web development firm?
Kelson Erwin:I think that maybe my final piece of advice would be to really look around and compare more options than you think you should. I just know that there's so many different agencies out there. And they all work in a different way. I want, people to come to us for custom software, but we're not always the best fit for people that come to us. And we'll tell them that, hey, we're not a great fit for you.
Kelson Erwin:And so go out there and evaluate take however many options you are considering evaluating and double it. And you'll probably find somebody, I know I always do, in that process that I would have never even considered betting if I would have just stuck with the initial list that I started going through A really important piece of advice is just to be very thorough when you're doing this vetting.
David Guthrie:Awesome. Thanks, Kelson.
Kelson Erwin:Yeah. Thanks, David.